Vlákno názorů k článku Nebezpečné webhostingy III od Jakub Vrána - To, že zkopírování souboru funkcí copy změní vlastníka...

1. To, že zkopírování souboru funkcí copy změní vlastníka souboru, nijak neovlivňuje funkčnost direktivy open_basedir.
2. To, že funkce tempnam přidává k prefixu souboru náhodné znaky, není motivováno změnou koncovky, ale zajištěním unikátnosti názvu souboru.
3. Těžko říct, co autor myslí obratem "PHP považuje za obrázek". Funkce getimagesize, kterou má možná na mysli, každopádně s koncovkou souboru vůbec nepracuje a rozhoduje se výhradně na základě obsahu souboru.

Dne 21.10.2008 pořádám školení Bezpečnost PHP aplikací, kde se takových chyb nedopouštím. Tímto na něj autora srdečně zvu.

P.S. Tu zmínku o nebezpečnosti tečky jsem do PHP manuálu před čtyřmi lety napsal já.

1. Já to tam tedy zřetelně vidím: "některé PHP funkce lze donutit k tomu, aby pracovaly v prostoru jiného uživatele, a to i přesto ... že to direktiva open_basedir výslovně zakazuje".

2. Můžete tedy to bezpečnostní riziko rozvést? Funkce tempnam() dovoluje vytvořit soubor s názvem obsahujícím .php. Ale co z toho, když např. pomocí fopen() lze vytvořit soubor s libovolným názvem?

3. Funkce getimagesize() se rozhoduje podle obsahu souboru a ne podle jeho názvu. Před tím, než něco napíšete, byste si měl ověřit fakta - buď pohledem do zdrojových kódů PHP nebo alespoň pouhým vyzkoušením <?php getimagesize("obrazek"); ?>, které pochopitelně vrátí hodnoty na základě obsahu souboru.

Nesnažte se nedostatek znalostí dohánět arogancí.

1. Popis naznačuje, že celý problém spočívá v tom, že vlastníkem zkopírovaného souboru se stane uživatel, pod kterým běží webový server. Pokud jste měl na mysli nějaký jiný útok, tak to není patrné a popis je zavádějící.
2. Myslíte chybu opravenou před dvěma roky (PHP bug #38963)? Stále mi zůstává záhadou, proč jste si vybral zrovna tuto funkci, když funkcí náchylných k obejití open_basedir byla celá řada.
3. Napsal jste, že "PHP považuje za obrázek i soubor s příponou .jfif" (to je omyl). Když jsem oponoval, že funkce getimagesize() s názvem souboru vůbec nepracuje, opáčil jste, že pracuje s MIME typem (to je druhý omyl). Kde ten MIME typ podle vás vezme? Nechcete se raději podívat do toho zdrojáku?

1. Jak jinak si mám vysvětlit obrat "přesto, že to direktiva open_basedir výslovně zakazuje"? Pokud jste měl na mysli skutečně ten tradiční scénář, kdy soubor vytvořený webovým serverem může v safe_mode pracovat s takto vytvořenými soubory jiných uživatelů, tak před tím open_basedit naopak ochraňuje.

3. Samozřejmě jsem to i zkoušel a výsledek zkoušky prezentoval v této diskusi. Kde PHP podle vás v kódu <?php getimagesize("obrazek"); ?> vezme MIME typ? Funkce getimagesize() se rozhoduje podle obsahu souboru, dokazují to zdrojové kódy i praktické zkoušky a vaše zarputilé přesvědčení na tom nic nezmění.

3b. Ještě mě napadá, že možná celou dobu mluvíte o hodnotě $_FILES['userfile']['type'] a máte možná pocit, že s funkcí getimagesize() nějak souvisí. Tuto hodnotu nicméně nastavuje prohlížeč a PHP ji jen posílá dál, takže obrat "PHP považuje za obrázek i soubor s příponou .jfif" je opět nesmyslný.

Sázku přijímám. Pokud se na školení nic nového nedozvíte, budete ho mít zdarma. Pokud naopak ano, tak mi zdarma provedete audit nějakého PHP kódu. (Možná by se hodilo, abyste před školením alespoň v bodech sepsal své současné znalosti, abychom to po školení mohli porovnat.)

Autor podle svých slov tuto diskusi přestal sledovat, ale odpověděl mi alespoň e-mailem. Pravda je nicméně taková, že potom už neodpověděl ani na mail.

Ještě k té bezpečnosti webových aplikací VS serverů:

• Přinejmenším část "PHP považuje za obrázek i soubor s příponou .jfif" se týká hlavně bezpečnosti webové aplikace.
• Na svém novém webu pentester.cz se pokud vím chcete věnovat i auditu PHP kódu.
• Troufám si tvrdit, že na zmiňovaném školení se bezpečnost serveru probírá víc do hloubky než v tomto třídílném seriálu (v rámci v podstatě okrajového tématu "není bezpečné aplikace na nebezpečném serveru").

Přišlo mi, že v této oblasti máte jisté rezervy, proto jsem si vás dovolil na školení pozvat. Pokud by někdo takhle pozval mě, s radostí bych pozvání přijal. Stejně tak se těším na spuštění vašeho serveru.

A Vam prijde logicke, abych platil za neco, co mi s nejvetsi pravdepodobnosti naprosto nic noveho neprinese? Ten podminovaci zpusob v citovanych komentarich ma svuj smysl.

1. Kde v te vete vidite napsano, ze tato zmena ovlivnuje direktivu open_basedir? Ja tam ctu, ze libovolny obsah direktivy open_basedir utoku nezabrani. O nejakem ovlivnovani tam zminku hledam marne.

2. Funkce fopen() netrpi na open_basedir bypass, coz se o tempnam() bohuzel rici neda.

3. Napsal jsem podle MIME typu, nikoliv podle nazvu a uz vubec ne podle obsahu, jak pisete Vy. Prectete si moji reakci prosim jeste jednou a poradne.

Nesnazte se argumentovat necim, co jsem nerekl.

1. Ano, tento utok je popisovan. Nikde ale neni zminka o tom, ze by ovlivnoval direktivu open_basedir, coz jste zpochybnoval.

2. Sam jste uvedl, ze funkci obchazejicich restrikce direktivy open_basedir je cela rada, proc bych si tedy nemohl vybrat prave tuto? Bylo na ni mozne demonstrovat praci serveru Apache s priponami, tak proto, osobne mi to tedy jako zahada neprijde.

3. Ano, takto definovana veta omyl je, to uznavam. Co se tyce klamani funkce getimagesize(), neurazte se, ale co kdybyste si to namisto mavani zdrojovym kodem vyzkousel? Podle obsahu zminovana fce typ souboru rozhodne nerozlisuje, pokud zfalsuji hlavicku (konkretne MIME typ), pak pres tuto kontrolu prejde i skript s obsahem "Hello World!" a PHP jej bude slepe povazovat za obrazek.

Verte mi (dokonce bych se s Vami i vsadil), ze z oblasti bezpecnosti webovych aplikaci byste mi nemel co nabidnout, natoz na verejne pristupne prednasce, i kdyz Vase kvality nezpochybnuji.
Na spusteni noveho serveru se rovnez tesim.

Nejsem pokrytec, pokud bych se na zminovane prednasce dozvedel neco noveho, co momentalne neznam, nestydel bych se to priznat. Kazdopadne s novymi informacemi na toto tema z verejne prednasky bych moc nepocital.

Nebot tato prednaska stoji tri a pul tisice a dle naplne mi nema co noveho nabidnout, o cemz jsem presvedcen.

ad 1: Tak to asi umim carovat :) Ovlivnuje direktivu safe_mode, nenapsal jsem open_basedir. U direktivy open_basedir jsem uvedl, ze je jedno, co obsahuje, nikoliv, ze ji tato zmena ovlivnuje.

ad 2: Motivace byla tedy jina, bezpecnosti riziko zustalo.

ad 3: Na zaklade obsahu souboru se zminovana funkce nerozhoduje, jedinym ukazatelem pro ni je mime typ. Ten vsak neni pro utocnika problem zfalsovat a podstrcit dynamicky skript s falsenym typem a pokud je konrola zalozena i na whitelistingu, pak jednoduse pripojit suffix .jfif. Nasledek je jasny snad vsem. Tohle ve Vasi prednasce nemate?

Diky za pozvani, ale tento serial se nezabyval bezpecnosti webovych aplikaci, nybrz serveru.

PS: Gratuluji