Bezpečnostní chyba CVE-2020-7071 v PHP

PHP bylo vydáno ve verzích 8.0.1, 7.4.14 a 7.3.26. Řešena je bezpečnostní chyba CVE-2020-7071 (#77423) ve funkci parse_url().

8.1.2021 07:00 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[trekker.dk]

Dobrá reklama na Debian - řešena je bezpečnostní chyba, odkaz na jejich tracker, všechno vulnerable

[Pavel]

Nebyl vždy security team Debianu známý postojem PHP itself is a vulnerability?

[Ptr]

To sice ano, ale je to jedno z mála míst, kde je u toho CVE napsáno více než ** RESERVED ** nebo NOT FOUND

[Luděk Postrašil (SEO UX Experts s.r.o.)]

ve verzích 8.0.1, 7.4.14 a 7.3.26

Kdo chce kam, pomozme mu tam. Když musí mít někdo všechno co nejnovější, takto pak takhle dopadá.

My naštěstí jedeme na dobře vyzkoušeném a odladěném PHP 5.

[billgates]

Presne. Nastastie este prakticky nikto nepremigroval na tieto hipsterske posrate nefunkncne verzie a vsetci idu na php5.

[Bedňa]

PHP5 (a staršie) idú pretože sú programátori prasata.

[rpajik]

Je hezké že si myslíte, že PHP 5 se chyba netýká. Zkusil jsem různé verze PHP co jsem kde našel ... od PHP 5.2 až po 8.0.0 se mi to chovalo úplně stejně blbě. Důvod proč je chyba opravena v řadě 7.3 a novější je ten, že starší už nejsou podporované, nikoliv protože by ve starších verzích ta chyba nebyla.

Takže přeji příjemný život s touto chybou ve Vašem dobře vyzkoušeném a odladěném PHP 5.

[Peter Golis]

Čo oko nevidí, to srdce nebolí.

Keby neboli tieto falošné pocity bezpečia, tak botnety prestanú existovať.

[MP]

Vyzkousene a odladene php5? To jako vazne :D :D

[Ján Dráb]

Musí to byť super pocit, keď sa zákazník opýta, či je zraniteľnosť XY aj v ich stacku a ty odpovieš, že nie, aj keď dobre vieš, že od januára 2019 je verzia PHP, ktoré používajú nielenže nepodporovaná, no nebude dostávať ani kritické security fixy :D.

[zxc]

No, tak ti halt jednou napařej náhradu škody, no.
No big deal.

[yxcy]

PHP tým je moc nóbl, než aby četl RFCčka.
Nicméně tohle už je jen babrání se v detailech, po té epidemii SQL injection, kterou PHP způsobilo se svým skládáním dotazů.

[Ján Dráb]

hovoriť, že PHP je zodpovedné za neošetrený vstup a neschopnosť programátorov kvoli sql injection, je ako tvrdiť, že C/C++/java sú zlé, lebo sú zodpovedné za buffer overflow, null pointer exceptiony alebo double free v xy programoch. cize podla mna kravina.

[zcx]

Kdyby nerazili dementní přístup slepování jako jedinej přístup, a naopak ho od začátku označovali za prasárnu, tak vzniklo daleko míň děravejch zdrojáků. To je věc, kterou lze tvrdit celkem objektivně.
Že má C/C++ problémy s memory corruption je taky objektivní nevýhoda, kterou se nové verze C++ snaží minimalizovat.

[Josef Kufner]

Vina PHP to je hlavně kvůli magic quotes a pár dalším blbostem.

Stejně tak je vinou frameworků, když vedou programátory ke špatným přístupům.

Stejně tak je vinou jazyků, že null pointer exception vůbec umožňují. Vynálezce null to sám považuje za “billion dollar mistake”.

[trekker.dk]

Stejně tak je vinou jazyků, že null pointer exception vůbec umožňují.

A jaké je tedy správné řešení toho, že ukazatel není nastaven?

[Josef Kufner]

Správné řešení je takovou proměnnou vůbec nemít.

[trekker.dk]

Zajímavé, a co když vytvářím program, který potřebuje reflektovat stav, jestli něco existuje nebo neexistuje...?

[kralyk z abclinuxu]

ADTs

[kralyk z abclinuxu]

Resp. lépe řečeno: Sumární typy. Potom takové ty věci jako existuje/neexistuje nebo vypadl výsledek/vypadla chyba jsou pouze specielné případy jednoho přístupu a nepotřebují nějakou explicitní specializovanou podporu v jazyce nebo nedej bože podporu, která pak platí befelem pro úplně všechno...

[kralyk z abclinuxu]

Potom takové ty věci jako existuje/neexistuje nebo vypadl výsledek/vypadla chyba jsou pouze specielné případy jednoho přístupu

Ještě k tomu dodám, že to má mj. tu výhodu, že se mezi těmahle dvěma snadno mapuje. Tj. optional hodnotu snadno namapuju na 'chybovatelnou' hodnotu tím, že tomu prostě řeknu, jaká tam má být chyba v případě, že hodnota chybí. 'Chybovatelná' hodnota se zkonvertuje ještě snáz (jedna mapovací funkce, která vevnitř prostě nahradí chybu za 'Nothing'), což se hodí v případech, kdy chcem ignorovat chybu a reportovat ji jen jako chybějící hodnotu.

Tj. není potřeba dělat nějaký rozskoky typu jestli chybí hodnota, tak vyhoď výjimku tu a tu, jinak udělej to a to anebo jestli nastala výjimka, tak vrať prázdnou hodnotu, jinak to a to ... apod., člověk to prostě jen zkonvertuje jedno na druhý...

[Josef Kufner]

… Výhoda pak je, že v místech, kde by normálně vznikla null pointer exception, jen překladač prohlásí, že tam nesedí typy a místo "Optional<něco>" má být jen "něco".

[billgates]

Moderne C++17 uz na tento ucel prislo so std::optional, ktore moze, ale nemusi drzat hodnotu. Proste nieco ako akvivalent pointeru na NULL. Ked sa pokusis pristupit k hodnote cez metodu std::optional::value, tak bud vrati referenciu na hodnotu alebo vyhodi vynimku.

[xkucf03]

A není pak už jednodušší pro povinné hodnoty používat reference, zatímco ukazatele si nechat jen pro nepovinné (a u nich vždy počítat i s možností nullptr)?

[linuxak]

Ne není to jednodušší. Nedá se to uhlídat, zcela jistě totiž někdo někdy na kontrolu nullptr zapomene a taky to nepěkně zapleveluje kód. Dereference nullptr je v C undefined behavior, program nemusí spadnout, např. na jednoduchých MCU bez MMU nespadne a pak to může dělat cokoliv. Součtový optional typ všechno tohle řeší. Vůbec nejlepší je ale mít jazyk bez null pointerů, třeba takový Rust je v tom poměrně daleko a null pointery mimo unsafe kód není potřeba prakticky vůbec řešit.

[xkucf03]

Souhlasím, že nedefinované chování je horší než vyhozená výjimka. Nicméně stejně se na chybu přijde až v době běhu a rozdíl oproti -fsanitize=address mi nepřijde až tak výrazný.

#include <iostream>
#include <string>
#include <optional>

int main(int argc, char**argv) {
	// tohle odhalí ASan:
	std::string* r = nullptr;
	std::cout << "r = " << *r << std::endl;

	// tady vyletí výjimka:
	std::optional<std::string> n = nullptr;
	std::cout << "n = " << *n << std::endl;
}

Stále je to polovičaté řešení, protože to nezabrání programátorovi udělat chybu a ani ji to neodhalí v době kompilace. Viz #21 – to rozlišování „bezpečných“ a „nebezpečných“ částí kódu nebo lépe ty anotace mi přijdou užitečnější, protože tam je možnost odhalit chybu už při kompilaci (nebo dokonce při psaní kódu v IDE, které na to může upozorňovat).

[billgates]

Pozor, operator* v std::optional nehadze vynimku, ale ma nedefinovane chovanie. Vynimku hadze metoda value(). Kazdopadne, mat null pointer v jazyku je extremne dolezite, kedze to ma konkretny semanticky vyznam. Len s tym treba spravne narabat. V modernom C++ uz nie je vobec potrebne pouzivat obycajne pointre a teda ani operator* a nic podobne. Komplet vsetko sa da riesit cez smart pointre a dalsie techniky.

[xkucf03]

Pozor, operator* v std::optional nehadze vynimku, ale ma nedefinovane chovanie. Vynimku hadze metoda value().

Mně to hází výjimku v obou případech:

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_M_construct null not valid

Ale je pravda, že v dokumentaci se píše:

The behavior is undefined if *this does not contain a value.

This operator does not check whether the optional contains a value! You can do so manually by using has_value() or simply operator bool(). Alternatively, if checked access is needed, value() or value_or() may be used.

To je asi docela škoda, protože pak stačí, aby programátor na jednom místě napsal hvězdičku a celý přínos std::optional se vytrácí. Takže zase viz #21.

[kralyk z abclinuxu]

Tak vyhození výjimky může klidně být projev nedefinovaného chování Akorát se na to nedá spoléhat...

Souhlasim s tim, že ten Optinal v jazycích jako C++ nebo Java ve výsledku není moc užitečný, ona celá pointa toho ML přístupu je ve vždy nenulových hondotách a Optional je jen doplněk (aby šly nějak udělat volitelné hodnoty)... Tj. zkopírovat jen ten doplněk jaksi k ničemu moc není...

[billgates]

Ono to ale ma zmysel. Myslienka C++ je v tom, ze musi poskytnut kazdemu programatorovi taky nastroj, aky potrebuje. Ako priklad uvediem napriklad std::vector. Pristupovat k jednotlivym polozkam je mozne cez metodu at, alebo operatorom [], ako v klasickom C. Kym at kontroluje, ze sa nepokusate pristupit mimo pola, tak [] tuto kontrolu nerobi. Na druhu stranu, kazda kontrola je draha a ked si je programator uplne isty, ze index na ktory pristupuje aj existuje, moze pouzit [] a usetrit cas. Rovnaka myslienka je aj pri std::optional a prakticky pri vsetkom. Vzdy mate moznost pouzit bezpecny alebo rychly pristup a tak je to spravne.

[linuxák]

Nebo použiješ Rust místo C++ a máš obojí, bezpečnost i rychlost . Jasně, i Rust musí dělat kontrolu mezí při přístupu přes index, ale tohle může překladač úplně vyoptimalizovat při použití iterátorů nebo range based for, takže prakticky to nevadí. Navíc v Rustu má překladač přesné informace o tom, kam který pointer ukazuje, takže může udělat optimalizace, které C/C++ v principu nikdy nedokáže, protože to memory model C/C++ neumožnuje. V C/C++ je strict aliasing, ale ten funguje jen pro proměnné různých typů. Rust takové optimalizace umí udělat i pro proměnné stejných typů, ale je to momentálně zakázané, kód v LLVM je rozbitý (žádný jazyk mímo Rustu to nedokáže využít, takže to není odladěné). Pokud se to podaří dotáhnout, má Rust potenciál generovat lépe optimalizovaný kód než C/C++: https://github.com/rust-lang/rust/issues/54878

[kralyk z abclinuxu]

Na druhu stranu, kazda kontrola je draha a ked si je programator uplne isty, ze index na ktory pristupuje aj existuje, moze pouzit [] a usetrit cas.

Bounds-checking není drahá kontrola. Existujou situace, kdy to je drahé, ale jsou poměrně vzácné. IMO situace, kdy ušetřit bounds-checking je skutečně potřeba, reálně nastane řádově méně často, než situace, kdy programátor má iluzorní pocit, že "tenhle přístup přes operátor [] je zaručeně bezpečný".

Navíc bounds-checking, resp. obecně kontrolu invariantů je typicky možné vytáhnout před výkonově kritickou část kódu, případně je schopen to udělat i sám kompilátor nebo mu můžu pomoct.

Pokud se budem bavit o Rustu, tak ten poskytuje rychlý přístup taky, ale právě pod fíčurou unsafe , aby bylo jasno, že "bacha, tady se děje něco nebezpečnýho" a aby ten bezpečný přístup byl default.

[xkucf03]

Nevím, proč do toho zase taháš Javu, přijde mi to u tebe až jako taková obsese…

A zrovna Java nabízí prostředky pro řešení nejen tohoto problému, ale obecně jakýchkoli kontrol a dodatečných metadat (anotace, anotační procesory…). Tzn. není v tom jazyce zadrátovaná ochrana konkrétně před NullPointerException, ale jsou tam obecné prostředky, framework, pro řešení podobných úloh.

Tohle je dobré téma na článek. Díky za tip :-)

[kralyk z abclinuxu]

WTF, Java byla pouze příklad vedle C++ a pouze proto, že tady byla už zmíněna v diskusi dvouma jinejma uživatelema (z nichž druhý jsi ty v #21).

Pokud máš pocit, že to vyřeší anotace a metadata, tak prosim, bránit ti v tom nebudu

[xkucf03]

Aha, takže obsese. Ve #21 nepadlo ani slovo o Javě.

[kralyk z abclinuxu]

No dobře, když tě to tak irituje, tak si nahraď větu

Souhlasim s tim, že ten Optinal v jazycích jako C++ nebo Java (...)

něčim jako

Souhlasim s tim, že ten Optinal v běžných statick typovaných jazycích, které nevyžadují nenulovatelné pointery/reference (...)

C/C++ a Java jsou ty nejvýznamnější příklady, které mě napadly. Ještě by se dal asi přidat C#, ale ten jde dost mimo mě a má nějakou podporu pro non-nulovatelné reference, u které moc neznám vlastnosti a implikace. Dále asi přichází v úvahu Golang, ale ten zas zřejmě nemá žádné ambice poskytovat Optional typ (nemá ani generika). Dále neuvažuju dynamicky typované jazyky, protože se bavíme o fíčuře statické analýzy. No takže ono těch jiných příkladů vlastně až tak moc nezbývá, alespoň z běžných/mainstream jazyků...

Každopádně, vyjadřoval v zásadě souhlas s tvým názorem, aspoň jsem si to myslel. Jsem zas jednou udělal tu chybu, že jsem napsal něco do xkucf subvlákna

[linuxák]

Poměrně dobře to má vyřešené Rust, Option ve spojení s pattern matchingem je docela mocný nástroj a nutí ošetřit všechny stavy, neošetřená varianta neprojde už při kompilaci: https://www.ameyalokare.com/rust/2017/10/23/rust-options.html

A ano i v Rustu jde prasit a místo pattern matchingu se dá použít třeba unwrap, ale ani to nevede na nedefinované chování, pokud v optionu nic není, zavolá se panic.

[xkucf03]

Tak zrovna u jazyků pracujících se surovou pamětí a ukazateli je tahle diskuse celkem zbytečná – tam se tomuto problému nejde vyhnout a ukazatel je jen číslo, které může být klidně nula nebo ukazovat na nějakou nesmyslnou pozici v paměti. Maximálně se to dá (částečně) řešit rozlišováním nějakých režimů, kdy předem řeknu, zda se daná část kódu chová „bezpečně“ nebo „nebezpečně“.

Zajímavější je tahle diskuse u jazyků, které programátora od surové paměti odstiňují. Tam se nabízí použití Optional, ale pokud ho člověk nebude používat důsledně všude a nezakáže se používání proměnných, které by mohly být null/prázdné, tak to stejně nic neřeší. A balit všechno do Optional a všechny operace provádět, jen když hodnota nechybí, vede na ošklivý a nepřehledný kód. Alespoň co se týče běžných-imperativních jazyků. Hloupé na tom je i to, že s hodnotou, která nikdy nechybí a s hodnotou, která chybět může, se pracuje jinak a ten zápis je odlišný – přitom tahle vlastnost (povinný/nepovinný atribut) se v čase běžně mění, je to součást měnícího se zadání. To už mi přijde užitečnější si proměnné nějak anotovat (třeba jako @NotNull, @Nullable atd.) a mít pro povinné i nepovinné stejnou syntaxi, ale dát kompilátoru nebo dodatečnému analyzátoru kódu informaci, na základě které může ověřit správnost a upozornit nás, když neošetřujeme potenciálně chybějící hodnoty a chováme se, jako kdyby byly vždy přítomné. Tzn. dívat se na tu povinnost jako na metadata, na základě kterých se dají dělat kontroly, ale neměnit kvůli tomu syntaxi.

[Josef Kufner]

Co poslední dobou vidím snahy o používání Rustu pro psaní jádra a modulů, tak se tyto dvě věci zjevně nevylučují. Můžeš mít jazyk, který pracuje na velmi nízké úrovni a přitom ti ten null pohlídá. Asi se nepůjde vyhnout některým případům, ale to ten unsafe režim Rustu řeší a ohlídat ručně pár míst je mnohem snažší, než to hlídat všude.

Ošklivost kódu řeší syntaktický cukřík. Třeba v PHP a Typescriptu máš otazníček, který říká, že tam může být null a pak to prská, když předáváš typ s otazníčkem někam, kde otazníček není. Reálně to je jeden znak navíc v kódu. Při čtení properties objektu pak jde použít otazníček také (null-safe operator: $a?->b() je zkrtka pro $a !== null ? $a->b() : null), což tu kontrolu schová, když víš, že s tím počítáš, nebo to nenastane. A když na začátek metody dáš podmínku, která ošetří null, tak pak z toho máš typ bez otaznčku a je to v pohodě také.

Aby tento přístup fungoval, je potřeba mít dostatečně schopný typový systém. Jazyky na úrovni C++ a Javy na to prostě nestačí.

[Filip Jirsák]

Je rozdíl mezi existencí null a null pointer exception.

null je často legitimní stav – ne nadarmo pro to mají databáze speciální hodnotu. Chyba je, pokud se nerozlišuje, zda proměnná může nebo nemůže být null (tohle mají relační databáze ošetřené už celé generace, takže se nelze vymlouvat, že to někoho nenapadlo) a že v případě, kdy může být null, není povinné ošetření tohoto stavu.

[Josef Kufner]

NULL v SQL je něco jiného. Tam je to jen další hodnota, která je zvlášť ošetřená. V připadě pointerů je rozdíl v tom, že pointer jde dereferencovat a to ovlivňuje cestu kódem. V SQL je cesta kódem stále stejná, jen výrazem probublá NULL (nebo se zahodí v případě agregačních funkcí).

[Filip Jirsák]

V obou případech null nebo NULL vyjadřuje neznámou nebo neexistující hodnotu. Programovací jazyky by s tím samozřejmě také mohly zacházet inteligentněji – a mnohé to dělají.

[alkoholik]

Az na Oracle DB, ktera si mysli, ze NULL string je prazdny retezec.