Řešení třetí programátorské hádanky aneb jak napadnout web

3.9.2009 23:21 | Přečteno: 3021× | poslední úprava: 11.12.2010 12:16

Třetí programátorská hádanka byla trochu složitější, tak jsem se rozhodl vše objasnit v extra článku. Vlastní hádanku naleznete zde.

Co udělá nulový znak při ukládání souboru

Když zadává útočník název souboru, může zadat např. toto:

skript.php%00

kde to %00 znamená nulový znak - znak s ASCII hodnotou nula. Co se v takovém případě stane?

PHP, stejně jako prakticky každý skriptovací jazyk, bere řetězec jako objekt. Tedy nějaké pole znaků a číslo udávající délku tohoto pole (řetězce). Nulový znak v takové reprezentaci nemá nějaké zvláštní postavení - pracuje se s ním stejně jako s jiným a většinou to ničemu nevadí. Z pohledu PHP tedy nebude název končit „.php“, ale „php\x00“.

Jiné je to při zápisu do souboru. Zápis do souboru je systémové volání a je nutno zavolat funkce jádra na otevření souboru. Všechna jádra současných rozumně používaných systémů jsou psané v Céčku (popř. C++) a očekávají „céčkovou“ reprezentaci řetězce. Tedy ukazatel někam do paměti, kde je posloupnost bajtů ukončených nulovým znakem. V praxi to probíhá tak, že prostě PHP alokuje někde paměť, tam překopíruje tu svoji reprezentaci řetězce, na konec hodí nulu a tenhle buffer předá jádru.

A tady je kámen úrazu. Pokud je nulový znak už v řetězci, PHP ho zkopíruje jako každý jiný znak, avšak jádro se při hledání konce názvu zastaví už na něm (namísto na tom koncovém). Takže se název zkrátí. Schválně si zkuste spustit kód

#!/usr/bin/php

<?php
 $nazev = "soubor.php\x00.txt";
 if (SubStr($nazev,-4) == '.txt')
     File_Put_Contents($nazev,'hack ');
?>

Co se stane? Ověří se, že soubor končí na „.txt“, ale na disku vznikne soubor „soubor.php“. Pěkné, že? Takto se dají krásně obejít i kontroly, končí-li např. název na .jpg atd.

Jak tomu zabránit?

Předně, není dobré zapisovat soubory tam, odkud by byly spustitelné. Dále není dobré soubory ukládat pod jejich správným názvem, protože kromě bezpečnosti to nemusí být praktické, často je lepší jako jméno volit např. nějaký hash a metainformace, jako je název nebo typ, ukládat např. do databáze. A za další, vždy platí zlaté pravidlo: nezakazujte věci, které se udělat nesmí (blacklist), ale naopak jen povolte věci, o kterých víte, že jsou bezpečné (whitelist). V tomto případě by se asi jednalo o regulární výraz na jasně danou množinu znaků.

Poslední možností je prostě zkontrolovat název souboru na přítomnost nulového znaku. Popravdě, nikdy jsem neviděl, že by toto bylo někdy explicitně ošetřeno. Nicméně při správně nastaveném serveru by nemělo hrozit žádné riziko.

Gratulace a další chyby v kódu

Na tuto chybu jako první v komentářích upozornil AraxoN - gratuluji

Další bezpečnostní chybou, kterou tento kód má, že povoluje zapsání souboru .htaccess. Pokud je jeho použití na serveru povoleno, lze pomocí něj definovat libovolné soubory jako PHP skripty, např. takto:

AddType application/x-httpd-php .txt

Tato chyba mě předtím nenapadla, díky za upozornění darkovi.

Pokud by server běžel na Windows, bylo by potřeba vyřešit ještě dvě chyby:

• (co je jasné) kromě dopředného lomítka kontrolovat i zpětné lomítko, které na Windows také slouží k oddělování adresářů
• (ale co je záludnější) Windows iniciativně odřezává z konce souborů mezery (možné i jiné bílé znaky). PHP soubor by tedy šlo podvrhnout třeba názvem „soubor.php%20“. Je to pravděpodobně vlastnost Windows, ne NTFS, protože na NTFS v Linuxu zapsat soubor s mezerou na konci můžu. Zajímavé je, že mezery na začátku souboru mu nevadí. Je tedy nutno před kontrolou zavolat Trim() (resp. RTrim()).

Anketa

Mimochodem, spousta z vás hlasovala v anketě, že příklad je lehký, i když se ještě v diskusi neobjevila žádná správná odpověď. Zvláštní Zeptám se proto ještě jednou (a odpovídejte po pravdě ):

Zranitelnost odstraněna (aktualizace 11. 12. 2010)

PHP od verze 5.3.4 by už nemělo připustit jakoukoli operaci se souborem majícím v názvu nulový znak. Tato zranitelnost je tedy již odstraněna.        

Anketa

Komentáře

[trekker.dk]

Další bezpečnostní chybou, kterou tento kód má, že povoluje zapsání souboru .htaccess. Pokud je jeho použití na serveru povoleno, lze pomocí něj definovat libovolné soubory jako PHP skripty, např. takto

AddType application/x-httpd-php .txt

I když je povoleno, nemusí být AddType v .htaccess účinné. Záleží na způsobu zpracování PHP serverem.

[Josef Kufner]

Mimochodem, spousta z vás hlasovala v anketě, že příklad je lehký, i když se ještě v diskusi neobjevila žádná správná odpověď. Zvláštní Zeptám se proto ještě jednou (a odpovídejte po pravdě

To protože nechtěli kazit zábavu těm později čtoucím

[Eregon]

Já v tom prakticky hned viděl ten zápis .htaccessu, to kouzlo s nulovým znakem je novinka.

Stejně si ale nedovedu představit, že by jenom trošku rozumně navržená webová aplikace tímhle vůbec mohla trpět.

[xvasek]

Přesně to mě napadlo taky - kontrolovat příponu v linuxu? (Jinak - abych nemachroval - bych na ten exploit samozřejmě nepřišel.)

[Josef Kufner]

Příloha:

• info.php (17 bytů)

Tak schválně...

[Josef Kufner]

Ach jo

[Filip Jirsák]

Čekal jste, že Javovský server ten PHP skript zpracuje, nebo že se urazí a přestane odpovídat?

[AraxoN]

hehe

[Josef Kufner]

Tak za pokus to stálo, ne ?

[Marek Bernát]

Abíčko nebeží na apachi, ale na nejakom javovskom servere? Btw, netuším, ako súvisí jazyk serveru s kódom súboru. Server len obslúži HTTP požiadavok, to kto ho spracuje, je úplne šumák (hoci by som sa veľmi čudoval, keby mal ábičkovský server nastavené obsluhovania PHP skriptov )

[AraxoN]

Response Headers:

...
Server: Jetty(6.1.11)

200 OK

Takže nie, abíčko nebeží na Apachi.

[Marek Bernát]

Hm dík, to nebola otázka na to, či je to pravda -- to už dosť zjavne plynie z kolegovho príspevku --, ale _prečo_ nie Apache. Celkom by ma zaujímalo, či je to len tak, alebo z nejakého dôvodu (výkon, integrácia s javou, niečo iné...).

[Filip Jirsák]

Abíčko používá Java Servlet technologii, takže je potřeba nějaký java servlet container. No a protože servlet container Jetty je zároveň webovým serverem a má HTTP část dostatečně kvalitní, je zbytečné mu předřazovat ještě nějaký jiný HTTP server, který by sloužil jenom jako proxy. No a rozchodit na Jetty PHP není úplně snadné, a protože by to bylo v případě Abíčka (i jiného serveru napsaného v Javě) zbytečné, proč by to někdo dělal?

[Luboš Doležel (Doli)]

Rozchodit nad Jetty PHP v CGI režimu je naopak velmi snadné. FastCGI taky jde, ale je to o něco složitější.

[Luboš Doležel (Doli)]

Pro případ, že by to někdo hledal. Nakonec to fastCGI ani není o nic složitější.

[Ladicek]

Kdybych já chtěl provozovat PHP na Javě, asi bych šel do něčeho trochu jiného

[Luboš Doležel (Doli)]

Wow, to musím vyzkoušet.

[Luboš Doležel (Doli)]

Tak je to fajn, ale characterEncoding=ISO_8859_1, co to dává do JDBC connection stringu, když se v PHP volá mysql_connect, to je konec.

[Ladicek]

Já to nikdy nezkoušel, jenom vím, že to existuje, ale když teď koukám na zdrojáky, vypadá to docela hackovatelně. A mělo by to umět použít konexi z JNDI, takže při použití v aplikáči (nebo i v tom Tomcatu, který konexe přes JNDI vystavit umí) by neměl být problém.

[Ladicek]

Ale při pohledu na com.caucho.quercus.lib.db.Mysqli to vypadá, že tam s kódováním znaků skutečně něco šaší:

// Explicitly indicate that we want iso-8859-1 encoding so
// we would know what encoding to use to convert StringValues
// to Strings
// php/140b 

Tak nevím. Hádám, že je asi trápí jiné věci, než internacionalizace, ale hádám, že hacknout by to šlo (kdyby se upravila i ta část, která converts StringValues to Strings).

[Luboš Doležel (Doli)]

Tváří se, jak jsou totálně unicode, a pak tam vhodí tohle. To teda fakt nechápu.

protected static final String ENCODING = "ISO8859_1";

[Marek Bernát]

O ten Apache mi šlo preto, že je obecne považovaný za veľmi výkonný server a dobre škáluje. Určite aj preňho existuje nejaký Java modul, veľmi by som sa čudoval, keby nie. Veď máme aj mod_lisp Takže tipujem, že to Jetty je tam preto, že je to default voľba, nie preto, že by niekto testoval rozdiel vo výkone oproti Apachu?

To PHP som spomínal len z toho dôvodu, že jazyk servera a jazyk, ktorým sa spracúvajú skripty nijak nesúvisia. Pokojne môžete cez Jetty servovať len PHP. Praktickú otázku nasadenia PHP pre abíčko (čo je úplná blbosť) som samozrejme nemyslel

[Limoto]

 

O ten Apache mi šlo preto, že je obecne považovaný za veľmi výkonný server a dobre škáluje.

To je vtip?

 

[Marek Bernát]

Nie.

[default]

Ale je! Sám jsem v dobách pokusů s Java EE napsal servlet pro servírování statického obsahu. A na správně nastaveném Glassfishi jsem dosahoval desetinásobně lepších výkonů. A to je celý HTTPD napsaný v C. Pravda, Apachí web server byl trošku v nevýhodě, ale koho to dnes zajímá.

[Filip Jirsák]

Pro Apache žádný Java modul neexistuje, pouze může předávat požadavky dál servlet kontejneru. Buď přes binární protokol AJP13, který má problémy se zpětnou kompatibilitou a autoři Jetty jej nedoporučují, nebo jako klasický HTTP požadavek. Apache sám by mohl obsloužit těch pár statických souborů, které na Abíčku jsou, tj. styly a nějaké obrázky. Vše ostatní by stejně musel předávat Jetty. Z toho je snad jasné, že přidání jedné zbytečné mezivrstvy výkonu určitě neprospěje, spíš naopak.

Java na serveru se používá vždy, když je serverová aplikace napsaná v Javě (jinak to ani nejde), naopak se asi málokdy používá varianta, kdy by byl Javovský server, který by ale fungoval jenom jako obyčejný HTTP server. Já jsem to tak sice dlouho používal (a po zjištění, že Apache dnes neumí prakticky nic nového proti počátkům verze 2.0, kdy jsem jej používat přestal, se k tomu zase brzy vrátím), ale to jsem asi dost výjimka. Takže webserver napsaný v Javě v drtivé většině případů znamená také serverovou aplikaci napsanou v Javě, takže se to běžně zaměňuje.

[Marek Bernát]

Aha, ďakujem za objasnenie. Netušim som, že Apache nemá žiadny modul pre Javu. To všetci používajú Jetty? Alebo sú aj iné možnosti?

Asi máte pravdu, že pre jazyky, ktoré len nespracúvajú skripty, ale skutočne bežia ako celistvá aplikácia je výhodnejšie mať špecializovaný server priamo v jazyku (napríklad aj Seaside to tak má, ak sa nemýlim).

[Luboš Doležel (Doli)]

Jinou možností je třeba Apache Tomcat. Používat nejavovský HTTP server pro Java aplikaci je prostě hloupost.

[Filip Jirsák]

Jetty, Tomcat, Resin a spousta dalších. Takový „modul pro Javu“ by stejně musel řešit meziprocesovou komunikaci (spouštět JVM pro každý požadavek by nebylo dobré, a JVM si jako knihovnu uvnitř Apache taky spustíte těžko) a samotný servlet kontejner je docela komplexní věc, která se stejně musí starat o protokol HTTP, spojení atd. Takže udělat z toho plnohodnotný server je v podstatě prkotina, a mít k tomu nějaký předřazený server je pak vlastně zbytečné.

[Eregon]

Kvík?

[dementni.lojzik]

Nicméně při správně nastaveném serveru by nemělo hrozit žádné riziko. ... i když se ještě v diskusi neobjevila žádná správná odpověď

ne ze bych tady tem vecem rozumel, ale vybavuju si, ze kdysi jsem cetl v knizce Zranitelny kod (ci tak nejak se to jmenovalo) prave o teto chybe. Autor upozornuje na nebezpeci nuloveho znaku, ale jestli se dobre pamatuju, tak to bere spis jako chybu ve webovem serveru nez v programu (ve smyslu, ze je tohle je taky dobre osetrit, protoze ve web serveru to osetreno byt nemusi). Treba proto nikdo neodpovedel spravne, protoze tohle vetsina lidi nepovazovala primarne za chybu v programu (tohle byl treba muj pripad, ale ja ani nehlasoval v ankete)

[l4m4]

Chybu bych ošetřil, i kdyby mě nenapadla, protože používám konzervativní whitelisty. Nemá smysl hledat všechny možné chyby v kódu, který je na první pohled nedostatečně defensivní...

[Kvakor]

Já osobně to řeším tak, že nikdy neukládám soubory pod názvem, který dodá uživatel, ale vygeneruju si vlastní (např. přes funkci tempnam()). Název dodaný užibvatelem uložím někde bokem a to jen v tom případě, že se bude později potřebovat (třeba při downloadu) a to až po "odprasení" - odstranění všech znaků, které by mohly být problematické, povolená jsou jen malá písmeba, podtržítko, mínus a tečka. A pokud je to možné, ukládám soubory mimo adresáře přístupné webserveru, takže cokoliv, co je v nich, nemůže být ani spuštěno, ani staženo bez dovolení.

[azurIt]

Podla mna ide o chybu v PHP - je jasne, ze sa toto stane VZDY, tak to ma mat osetrene a neakceptovat NULLove znaky v nazvoch suborov. Napriklad toto urobi Python:

>>> nazov = "test.txt\x00"
>>> file_obj = open(nazov, "w")

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: file() argument 1 must be encoded string without NULL bytes, not str

[razor]

Též bych řekl, že by to high level jazyky měly nějak ošetřovat. On vůbec ten null znak je dost podivna věc, která má IMHO smysl jen v C.

[Marek Bernát]

Keď už sme pritom, tak znaky nie sú čísla a high level jazyk by ich vôbec nemal takto implementovať. Okrem toho, že to prináša takéto chyby, tak je to zviazané s ASCII kódovaním, čo je ďalšia nepríjemná vec.

[vlastikroot]

Budiz bohuslavena utf8 Ale souhlasim s tim, ze string by mel byt neco abstraktniho, bez jakehokoli vlivu toho jake znaky v nem jsou. Ta fopen by mela nebezpecne znaky ignorovat. Nejhorsi na tom je to, jak jsou ty obycejne nulou koncene stringy zazrane v systemu. Tyhle koule na noze se unix asi nezbavi ...

[Eregon]

Souhlas. Kdo to reportuje?

[azurIt]

Nema vyznam, pretoze PHP developeri toto povazuju za 'feature' :)

[qiRzT]

Tak to je pro mě novinka, u php bych tohle chování nečekal, u C by mě to možná napadlo. Ale pořád mi nejdou z hlavy dvě tečky - co když by tam někdo procpal něco jako ../neco.xyz?

[Aleš Janda]

Tam by neprošlo to lomítko

[qiRzT]

Kdybych já si ten kód přečet pořádně... Z jakéhosi důvodu jsem myslel, že to testuje lomítko na začátk. A myslet znamená...

[Aleš Janda]

PHP od verze 5.3.4 by už nemělo připustit jakoukoli operaci se souborem majícím v názvu nulový znak. Tato zranitelnost je tedy již odstraněna.

Upozornění jsem do článku již doplnil.