Feloszlatta magát a glibc vezetőtestülete

FSF/GNU/GPL

2001 óta a GNU C Library Steering Committee felügyelte a glibc fejlesztését. Azonban most, hogy a fejlesztéshez hozzájárulói, közreműködői kedv felerősödött, a fejlesztők közössége képes a projektet saját maga vezetni. Ezért Roland McGrath - a GNU C Library eredeti szerzője, aki közel 25 évvel ezelőtt kezdte meg a glibc fejlesztését - tegnapelőtt bejelentette, hogy a GNU C Library Steering Committee egyhangúlag a feloszlás mellett döntött. A projekt irányvonalait és irányelveit mostantól kezdve azoknak az embereknek a konszenzusa határozza meg, akik a fejlesztésben aktívan részt vesznek.

A részletek elolvashatók a bejelentésben.

Egyáltalán nem értek a programozáshoz, a glibc-hez meg pláne nem, de a blogbejegyzésedet átfutva úgy képzelem, itt két mprotect-nek kell lennie:
1. verem végrehajthatóvá tétele
2. relro szakasz írhatóvá tétele

Gondolom, pax alatt egyik sem sikerülhet, így a végrehajtható vermet igénylő progik a glibc bug kijavítása után sem fognak menni, legfeljebb jobban rá lehet jönni, mi okozza a hibát. Jól sejtem?

Az mprotectek megvannak, csak a visszatérési értékek vizsgálata nem, így utána a read-only memóriaterületre történne írás, ami nem sikerül érthető módon és segfault a jutalma. Ez programozási hiba.

Ahogy Kees Cook is írta ez nem PaX specifikus, az SELinux is megtagadhat ilyen hívásokat (és vanillánál is előfordulhat olyan eset, hogy az mprotect hibával tér vissza), így máskor is problémát jelent a visszatérési érték vizsgálatának elmulasztása.

A RELRO szekció újra írásvédetté állításának sikerességét nem ellenőrízve pedig a read-only adatok írhatóak maradnak utána is, amely viszont már komoly biztonsági hibának minősül.