Dinamiese laaier
Die kern van die probleem: tydens operasie onttrek ld.so eers die waarde van die LD_LIBRARY_PATH-veranderlike uit die omgewing en, met behulp van die _dl_split_path()-funksie, verander dit in 'n verskeidenheid stringe - paaie na gidse. As dit later blyk dat die huidige proses deur 'n SUID/SGID-toepassing begin word, dan word die geskepde skikking en in werklikheid die LD_LIBRARY_PATH-veranderlike uitgevee. Terselfdertyd, as _dl_split_path() se geheue opraak (wat moeilik is as gevolg van die eksplisiete 256 kB limiet op die grootte van omgewingsveranderlikes, maar teoreties moontlik), dan sal die _dl_libpath veranderlike die waarde NULL ontvang, en daaropvolgende kontrole van die waarde van hierdie veranderlike sal dwing om die oproep na _dl_unsetenv("LD_LIBRARY_PATH") oor te slaan.
Kwesbaarheid gevind deur kundiges
Byvoeging: Die probleem is 'n nommer toegeken
amd64 en i386 (die ontginning kan aangepas word vir ander argitekture).
Die probleem is ontginbaar in die verstekinstallasie en laat 'n onbevoorregte plaaslike gebruiker toe om kode as wortel uit te voer via biblioteekvervanging wanneer die chpass- of passwd suid-nutsprogramme uitgevoer word. Om die lae geheue toestande te skep wat nodig is vir werking, stel die RLIMIT_DATA limiet via setrlimit.
Bron: opennet.ru