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

Michal Moskal malekith w pld-linux.org
Wto, 10 Wrz 2002, 14:00:07 CEST


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.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h



Więcej informacji o liście dyskusyjnej pld-devel-pl