Bash biztonsági hiba, Shellshock bug. Javítás: sürgős frissítéssel

Bash biztonsági hiba, Shellshock bug. Javítás: sürgős frissítéssel

“A Bash (Bourne again shell) számos UNIX és Linux-disztribúció része (de megtalálható az OS X-ben is) és az egyik legtöbbször használt komponense az operációs rendszereknek, amellyel számtalan szoftver kerül kapcsolatba. A Red Hat kutatói egy olyan biztonsági problémát találtak, amelyet kihasználni banálisan egyszerű, a következményei pedig egyelőre fel sem mérhetők. A cég által publikált blogbejegyzés alapján a hiba forrását az jelenti, hogy megadhatók olyan környezeti változók, amelyeket a Bash kódként futtat le, és ezt minden esetben megteszi, amikor a shellt adott környezetből meghívják. A változóknak a neve egyáltalán nem is fontos, bármi lehet, ha a tartalmuk “megfelelő”, akkor ezeket a kódokat a Bash le fogja futtatni.”

A Shellshock bug ellenőrzése a linux rendszerünkön

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
 vulnerable
 this is a test

Amennyiben a tesz szkriptet lefuttatju és az a “vulnerable” választ adja, akkor sajnos a linux operációs rendszerünk támadható.

A bash sérülékenység javítása

A legtöbb linux operációs rendszerhez már kiadták a frissítést, így az frissítési csomagok közül a bash frissítésével a hiba javítható. Ezt követően a szkript már nem fog hibát adni. Saját Debian Wheezy szerverünkön a válasz így néz ki:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
 this is a test

Miért számít veszélyesnek ez a bash hiba?

“Robert Graham, az Errata Security szakértője szerint a legnagyobb kockázatot most is az internetre csatlakozó “okos” eszközök (pl. routerek, otthoni NAS-ok, médialejátszók, kamerák) jelentik, amelyekhez egyáltalán nem érhető el már gyártói támogatás, vagy amelyek gyártói nem adnak ki szoftverfrissítést. Ezeknek az eszközöknek jellemzője, hogy a szoftverük gyakran tartalmaz nyílt forrású komponenseket és sok funkciót a Bash segítségével valósítanak meg (tipikusan ilyen a távoli hozzáférés a konfiguráláshoz). Ha egy ilyen eszköz sebezhető, akkor nagy valószínűséggel az is marad.”

“Nem kell sietni a sebezhetőség befoltozásával” – írja Graham. “Az elsődleges szervereid valószínűleg nem sérülékenyek. Minden más viszont valószínűleg igen. Szkenneld a hálózatodat olyasmik után kutatva mint a Telnet, FTP vagy a régi Apache-verziók (a masscan erre nagyon hasznos). Minden, ami válaszol, valószínűleg egy régi eszköz, aminek a bashét patchelni kéne. De mivel a legtöbbhöz úgysincs patch, valószínűleg ráfaragtál.”

Milyen szolgáltatások érinthet a Shellshock bug ?

A cikkekben, amik a Shellshock buggal foglalkoznak legfőbb fenyegetettségnek az webszervereket, így pl. az apache2 webszervert említik. Másik fontos érintettnek a CGI szkripteket. De említik a php-t érintő sebezhetőséget is.

Most foglalkozzunk ezekkel a bash hibákkal

Apache2

Normál, alap webszerver esetén az apache2 egy bizonyos felhasználó nevében fut, legyen ez apache2, www-data, wwwrun néven a linuxunkon. Akkor támadható az apache2 a bash hibán keresztül, ha a felhasználó shell-je bash. Tudjuk jól, hogy egy rendes operációs rendszeren ezen felhasználónak a shell-je /bin/sh.

A vhost-okat kiszolgáló webszervereknél chroot-olt apache2 szolgálja ki, rendesen konfigurált rendszer esetében suexec-es megoldással egy saját (kellően alacsony jogosultságú) felhasználó nevében futnak a szálak. Az elfogadható biztonsági szabályok szerint ezek a felhasználók nem is kapnak shell-t, az ftp-s eléréshez ugyanis ez nem szükséges. Ha van shell hozzáférésük, akkor ezt kell ellenőrizni, hogy ne bash shell-t használjanak.

CGI szkriptek

A CGI szkripteket általános biztonsági szempontok miatt már egyre kevésbé alkalmazzák, ha mégis használatban van, akkor ezt valóban célszerű ellenőrizni. Bár szinte bármilyen szkriptnyelvet használhatunk CGI szkipt írásakor, de megeshet, hogy bash nyelven került egy ilyen szkript megírásra. Ez a Shellshock bug esetében nyilvánvalóan potenciális támadási felület.

PHP szkriptek

A php kapcsán azt róják fel, hogy lehetőség van a szkriptekkel shell parancsokat futtatni, ezek keresztül természetesen bash szkripteket is, ez okozza a fenyegetést.

Ehhez kapcsolódóan meg kell jegyeznünk, hogy a php fejlesztői igyekeznek a php-t a lehető legbiztonságosabbá tenni, és ennek egyik példája, hogy nagyon egyszerűen tiltható minden olyan parancs és lehetőség, amelyen keresztül lehetőség van egy linux  operációs rendszeren php-ből shell szkripteket futtatni.

Amennyiben ez a tiltás nincs konfigurálva, akkor érdemes átgondolni a bevezetését, mert valóban komoly biztonsági kockázatot hordoz, amennyiben engedjuk a shell_exec(), exec(), pathtrue() … parancsok használatát.

A bejegyzés alapja: www.hwsw.hu

Hasonló bejegyzések:

Linux.Darlloz php sérülékenység, HTTP POST támadás Linux.Darlloz php sérülékenység, HTTP POST támadás A Linuxot futtató különféle eszközökre specializálódott férget fedeztek fel a Symantec szakértői. A kártevő…

Openssh felhasználó hozzáférés korlátozása Openssh felhasználó hozzáférés korlátozása Amennyiben foglalkozunk linux rendszerünk biztonságával és így kellően kevés felhasználó férhet hozzá operációs rendszer szinten a…

A mysqli_real_escape_string() függvény használata A mysqli_real_escape_string() függvény használata A php weboldalunk egyik sebezhetősége általában az SQL Injection, az adatbázis sérülékenységből adódó hozzáférés. Egy példa,…

WordPress biztonság: hogyan tegyük a WP-t biztonságosabbá WordPress biztonság: hogyan tegyük a WP-t biztonságosabbá Folyamatosan növekszik azok száma, akik a WordPresst használják weboldal készítéséhez. Sajnos az ismertséggel…

Debian 7.8 megjelenés, Debian GNU/Linux 7 kiadás Debian 7.8 megjelenés, Debian GNU/Linux 7 kiadás A 2013. május 4-én bemutatott Debian 7 Wheezy linux operációs rendszer 8. javítócsomagjának…

Spamhaus DROP és EDROP listák alapján iptables tiltás Spamhaus DROP és EDROP listák alapján iptables tiltás A Spamhaus project segít, könnyen feldolgozható és elérhető formában tartani az Internet…