Vlákno názorů k článku
Chyba v knihovně GNU C Library (glibc) ohrožuje servery s PHP od Amarok - Možná by chtělo na úvod hned napsat, že...

Možná by chtělo na úvod hned napsat, že se jedná o chybu v japonské znakové sadě. Nepoužívám, takže není co řešit. Vypnutí problémové znakové sady je OK, ale proč vypínat něco, co stejně nikdy nepoužiju?
Upozornění na chybu samozřejmě v pořádku, jen je zprávička zbytečně poplašná :-D

Obávám se, že tak jednoduché to není. Zatím neznáme přesný popis té chyby, ale uvádí se, že ke zneužití stačí zmanipulovaný vstup. Takže to vypadá, že stačí, že tu znakovou sadu použije správně útočník. Já jsem to na serverech pro jistotu automaticky vypnul, protože tu znakovou sadu taky nepotřebuju.

Chyba je pouze v Čínské a ne Japonské znakové sadě.

Znakovou sadu je nutné zvolit na vstupu, útočník jí nemůže vnutit upravenými daty, musí aplikace umožňovat takovou sadu použít (což u nás asi časté není, v Číně to je skoro výchozí).

Tomu odpovídá i ten patch, opraven byl pouze soubor iso-2022-cn-ext.c, kde nově kontroluje explicitně přetečení. https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=iconvdata/iso-2022-cn-ext.c;h=cce29b19692263d6020beea45f7a1d3126e81ca0;hp=b34c8a36f4564c11a7e343fc4e9181ddee5e810b;hb=f9dc609e06b1136bb0408be9605ce7973a767ada;hpb=59974938fe1f4add843f5325f78e2a7ccd8db853

Jedině že by na vstupu byla použita autodetekce znakové sady a výsledek se předával iconv. V PHP docela časté řešení.

Vas server ignoruje hlavicku v takomto formate?

Content-Type: application/x-www-form-urlencoded ; charset=UTF-8

Obsah spravy pre POST potom moze byt v tomto charsete.

já žádný php server nemám.

charset v content-type se podle mě v php ignoruje a obsah v php://input nebo $_POST není změněn a překládán automaticky. Tohle snad platilo v php vždycky, musel se o to starat framework a tedy samotná aplikace.

Nacionální příslušnost útočníka nekoreluje s používáním znakové sady k útoku :-)

Jste si jistý, že to nemůže na vašem serveru někdo použít? Je řeč o PHP, tedy webovém serveru. Co se stane, když klient pošle požadavek s touto znakovou sadou? Jste si jist, že se ta funkce nezavolá?

Napsat bez detailnějšího prozkoumání „nepoužívám“, když vám vstup posílá někdo přes síť, je dost lehkovážné.

Obávám se, že v tomto případě stačí opravdu ji nepoužívat - nevím, že by existovala cesta, jak si to zvenku vynutit voláním stránky (v hlavičce...?)
Nicméně asi bude každopádně lepší to vypnout.

Když klient posílá data na server v těle požadavku, uvádí obvykle jejich typ a kódování. Dále HTTP hlavičky se standardně posílají v kódování ISO-Latin-1, ale někdy je možné použít MIME kódování. Nevím, zda se něco z toho dostane nedekódované až do PHP – ale rozhodně bych na to bez dalšího průzkumu nespoléhal.

Do PHP se dostanou surová data a záleží na kódu, co se s daty bude dít dále

No, i kdyby to řešil už webový server (spíš ne), tak to je stále potenciálně problém.

Já bych to nepodceňoval, doposud nikdo nepřemýšlel nad tím, jak přinutit php engine (nebo wordpress nebo jádro laravelu, nebo...) ten iconv spustit páč to bylo k ničemu. Teď to bude řešit hromada lidí. A pokud to někdo zvládne, bude to severity 10/10.

Z ceho usuzujete japonskou sadu? Kdyz to ma CN v nazvu, a koduje hlavne sedum ze sectnacti stranek oficialniho kodovani pro R.O.C. - Taiwan :D