Vlákno názorů k článku
Optimalizace v GCC vytvořila bezpečnostní díru v jádře
od Icek -
Mohl by mi nekdo objasnit duvod proc ten...
-
Jirka P (neregistrovaný)
Samozřejmě že by to padlo – nebo aspon mohlo padnout, protože je to nedefinované chování (například pokud by se ta hodnota nikdy nepoužila, může na ni kompilátor úplně zapomenout)
Něco jinýho by bylo
struct sock **sk = &tun->sk;
což je OK i pro tun == NULL (ačkoli výsledná hodnota sk je v tom případě neplatná) -
Nemyslim ze je korektni ta optimalizace. Myslim ze hrabat optimalizatorem do if ( pointer == NULL ) neni nikdy moc chytre, pokud neni kompilator opravdu genialni. Co treba
d1 = struct_data1, d2 = struct_data2, *s = random_z_( &d1, &d2 ) - &d1; x = (&d1 + s)->mujX; if ( !s ) { ... neco s d2 ... } else { ... neco s d1 ... }Pochopi GCC ze se nejedna o klasicky NULL test ale vetveni kodu?
To inicializovani promenne s NULL pointrem v linuxu padne tak jako tak (i pri cteni), kdyz ten proces nema tu pamet, ne? Nebo cteni projde? Ale je to teda pekne pitoma frajerina, proc to nenechaji nenainicializovane a nepriradi tu hodnotu az za ifem, to nechapu.
-
To gcc do něj nehrabe, ten původní kód je napsaný tak, že nejdřív ze struktury čte data a potom teprv testuje, zda ta struktura není NULL. Na základě toho (úspěšného, viz * níže) čtení gcc usoudí, že struktura NULL být nemůže (když se z ní dříve úspěšně četlo) a test na str == NULL úplně vyhodí.
Takže i výše zmíněný kód gcc zpracuje korektně, bo nemůže tušit, co v tom „s“ vlastně bude. Kdyby předtím bylo ještě a = *s, tak rovněž část kódu za if (!s) vyhodí (pominu-li to, že s by měl být ptrdiff_t, takže by kód bylo třeba výrazně upravit).
- – za normálních okolností by spadnul, v tomto případě si exploit předtím na adresu 0×0 namapuje validní stránku.
Není to frajeřina, je to prostě jen chyba při vývoji.
