ShellShock, a bash sebezhetőség

Bevezetés

Aligha hiszem, hogy aki legalább power user szinten foglalkozik számítógépekkel, ne hallott volna a nemrég felfedezett, a bash-t érintő hibáról. Ha netán mégis van olyan az olvasók között, akinek most hozom meg a kedvét a tájékozódáshoz, az errefelé nézelődjön. Nem akarom megismételni az itt leírtakat, nem török Pali babérjaira, mindazonáltal valószínűleg gyakran előkerülnek majd a részletek, mert mindenképpen szükséges a leírtak megértéséhez.

(P:C)(/P)

Nincs mit tagadni, ezen írás apropóját két dolog inspirálta: az egyik David A. Wheeler kiváló összefoglalója a problémáról, másrészt a Cafés íráshoz kapcsolódó fórumtopicban néhány bithuszár elkezdte feszegetni, hogy akkor most mi is a helyzet az opensource szoftverek biztonságával: összeomlott a "mítosz"?

Ígérem, lesz a kérdésre válasz. Előrebocsátom: noha én nem tudtam annyira jól megfogalmazni a gondolataimat, mint Wheeler, nagyrészt nekem is hasonlók jártak a fejemben, ezért senki ne csodálkozzon, ha Wheeler véleményét is látja ebben az írásban.

Mindenesetre megpróbálom elkülöníteni azokat a témákat, amik nekem is eszembe jutottak azoktól, amelyek csak Wheeler fejében fogantak meg.

Még egy apróság: noha maga a probléma merőben technikai jellegű, igyekszem olyanná formálni az írást, hogy a technikai részleteket kevésbé értő, azok iránt kevésbé fogékony olvasók is megérthessék.

Hirdetés

A probléma, Wheeler javaslatai

A fenti linken elolvasható az elsőre (félre-)ismert hiba. Tény, hogy a bash nem fejezte be a munkát a függvények feldolgozása után, viszont ezután néhányan elkezdtek tűnődni: ha a parserben hiba van, akkor azonosítás nélkül kontrollálatlan információk feldolgozására lehet rávenni a felületet. Tavis Ormandy is ezen gondolatmenet mentén jutott el oda, hogy az első javítás csak tüneti kezelés, a probléma gyökerét nem szünteti meg.

Ezután gyors egymásutánban még négy parser-hibát találtak a bash-ben. Mivel a hiba kihasználásához nem kell autentikáció, viszont nagyon könnyen kihasználható és súlyos biztonsági incidens okozására alkalmas, a CVSS értékelés azonnal 10-es lett a lehetséges 10-ből. Érintett minden rendszer, ahol a bash telepítve van és meghívható - shell scriptből és CGI-ből például, ezt kihasználva a botnet-építők villámgyorsan felépítették a wopbotot.

Furcsa módon a különböző típusú rendszerek különbözőképpen érintettek a problémában, még egy családfán belül is. A kereskedelmi Unix-rendszerekben ritkán használják alapértelmezett non-interactive shellként a bash-t - pl. AIX-on nem. A Debian és az Ubuntu nemrég áttért a dash használatára (itt lényeges, miért fontos a POSIX-szabványok betartása), míg a Red Hat-alapú rendszerek, a Free- és NetBSD viszont erősen érintett. A Mac OS is az, ha van telepítve bash, míg az Android nem érintett, mivel ott nem áll rendelkezésre bash (alapértelmezett konfigurációkra gondolok). A Windowsra készített Cygwin ugyancsak érintett.

A javítások ugyancsak sokszínűek lettek: a BSD-kben letiltották a bash függvényeket impliciten importáló funkcióját, Linuxon prefixeket és suffixeket vezettek be, Mac OS-en ugyan a Linuxhoz hasonló megoldást találtak ki, de olyan karaktereket is alkalmaznak, amelyek shell metakarakterek, később ez a megoldás még visszaüthet.

Az eddig leírtak tükrözik az általam is kigondoltakat, most inkább a problémakör azon részeire koncentrálok, amelyeket Wheeler is megemlített. Fontos cél lenne már a programok tervezése során, hogy az adatok és a programkódok lehetőség szerint szigorúan szeparálva legyenek - könnyebben kivédhetőek lesznek a hasonló típusú hibák. Sokkal "olcsóbb" és könnyebb előre megtervezetten létrehozni ilyen programokat, mint utólag módosítani őket.

Szintén könnyebben kivédhetők lennének az ilyen jellegű hibák, ha a dokumentáció megfelelő. A bash dokumentációjában igen részletesen szerepel az import/export funkció. Arról azonban egy szó nincs, hogyan is működik. Wheeler javaslatai szerint a saját névterek bevezetése sem lenne elvetendő ötlet a saját programjaink számára - nem csak a változók, hanem a fájlrendszer terén is.

Christos Zoulas készítette a javítást a *BSD-khez; a javítás telepítése után explicite kérni kell a függvények importálását. Wheeler egyetért az ötlettel.

Minimalizáljuk a komponensek számát, távolítsuk el a ritkán használt komponenseket a programokból, valamint ne adjunk olyan komponenseket a programokhoz, amelyek nem feltétlenül szükségesek. Noha mindhárom hajaz a KISS-filozófiára, a józan meggondolás ennél is egyszerűbb: minél kevesebb kódsorból áll egy program, annál könnyebb elkészíteni/karbantartani a dokumentációját. Figyelem! Forráskód != dokumentáció.

Végszó, mítosz

Még ma is sok rendszer található a világon, amely sebezhető ShellShockra. Ez elsősorban annak következménye, hogy nagy részükön semmiféle stratégia nem létezik a frissítésre. Itt most nem csak szerverekről van szó, hanem minden olyan beágyazott rendszerről, amely bash-t futtathat - navigációs rendszerek, routerek, ATM-ek stb.

Összeomlott-e a mítosz a nyílt forrású szoftverek biztonságáról, amire Pali cikkének címe is utal? Nem, sőt most mutatta meg igazán az erejét: a szoftver fejlesztőjétől, karbantartójától független emberek tettek, vagy valósítottak meg javaslatokat a hibák kivédésére.

Miért maradt eddig rejtve a hiba?
Nyilvánvalóan azért, mert a bash egy ritkán használt képességéről szól, amelyet biztonsági auditnak alávetni csak idő- és pénzpocsékolásnak bizonyult volna, amit senki nem fizetett volna meg.

Még két apróság a végére:

Ezzel nem mondom, hogy a Windows sebezhető, csak azt, hogy még nem sebezhető, de a szimptómák nagyon hasonlóak a ShellShockhoz.

További jó programozást és jó vadászatot a hibákra!

Előzmények