STBR: mpack.spec, flex.spec (security fixes)

[Krzysiek Taraszka]

On Tue, 10 Sep 2002, Michal Moskal wrote:

> On Sat, Sep 07, 2002 at 12:40:07PM +0200, Krzysiek Taraszka wrote:
> > On Sat, 7 Sep 2002, Tomasz Kłoczko wrote:
> > 
> > > > 
> > > > This could be a potential security issue, since nmdef is an automatic 
> > > > variable defined inside a  function, and hence lands up on the stack.
> > > 
> > > flex juz posedł. mpack zaraz tatże pójdzie.
> > > 
> > > Na lex/flex/yacc/byacc to ja się słabo wyznaję. Czy ktoś może odpowidzieć
> > > czy powyzsze stwarz tylko zagrozenie dla samego programu lex czy tażee dla
> > > dla programół które używają produktów generowanych tym narzędziem ?
> > 
> > Zagrozeniem jest jak widzisz flex, ktory przetwazajac zaduze stringi 
> > wysypuje sie i zostawia jakies smieci na stosie ktore moga byc odczytane 
> > ze stosu (bo ja wiem ? jakies pidy ? etc, etc ..), wiec zagrozenie 
> > niedonosi sie do programow generowanych flexem.
> 
> Czytaj: nie jest to żadne zagrożenie.  Jedyny sensowny scenariusz, gdy
> mogłoby to być wykorzystane do czegokolwiek poza wywaleniem flexa jest
> gdy flex byłby uruchmiany przez jakiegoś demona.  Zauważmy, że potem
> ten demon musiałby uruchomić kompilator.  100:1, że w gcc jest znacznie
> więcej buffer overflow i nikt się tym nie przejmuje, ponieważ nie jest
> to aplikacja security-critical.  Podobnie bardzo łatwo znaleźć jakiś
> algorytm o złożoności wykładniczej i zarżnąć server.  Więc ten segv nie ma
> *nic* wspólnego z security, to po prostu bug w programie.  Osobiście nie
> chciałbym, żeby takie annouce pojwiały się na low-volume liście
> security-advisories.

No tak, ale ... > > > This could be a potential security issue,

Krzysiek Taraszka			(dzimi w pld.org.pl)