Názory k článku
Chyba v knihovně GNU C Library (glibc) ohrožuje servery s PHP

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

No dnes o 9:55 CEST 23-ho APRILA 2024 sa mi na Debian 12 akurát updatovalo libc.

Je to tak, opravený balíček právě vyšel v bullseye-security.

Díky díky, pro jistotu na serverech zakomentováno...

A nachazi se ta chyba i v standalone libiconv, kterou pouzivali starsi PHP ?

Někde jsem četl, že se jedná o 24 let starou chybu... takže o jak moc starším PHP mluvíme?

23. 4. 2024, 20:15 editováno autorem komentáře

cca PHP5 umoznovalo definovat behem ./configure libku pro iconv - rekneme tak 20 az 10 let zpet, to je standalone libka nezavisla na glibc, ale implementujici tytez funkce.

Jsem asi moc starej, ze me pri "iconv" napada prave ona libiconv a iconv tool - ale zda se ze tuhle funkcionalitu prevzalo pak glibc a exportuje to pod "gconv" sadou funkci:

https://www.gnu.org/software/libc/manual/html_node/glibc-iconv-Implementation.html

ale kdyz se divam do repa, tak vidim:

*  dev-libs/libiconv
      Homepage:    https://www.gnu.org/software/libiconv/
      Description: GNU charset conversion library for libc which doesn't implement it

Takze to spis vypada, ze jde o stejny produkt, jen u glibc je gconv pribalen, zatimco libiconv s iconv je urcen pro jine libc, ktere konverzi neintegruji (napr bsd libc).

Ale tim, ze to je stejny, a CVE-2024-2961 zminuje hlavne glibc a nikoliv libiconv, tak jsem si prave neni jisty zda tedy jo ci ne - je tam bug? je to stejny kod?

(vyzkouset to nemohu, co to stahne za zdrojaky pac libiconv a glibc jsou na mem gentoo to nebo to, nelze mit oboje)

Ta uvedena cesta pro debian plati jen pro debian 12. V 11 a nizsi ta cesta bude zrejme /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.

No mam velkou radost z nasich not-support serverech.

V Rocky Linux 8.9 (Green Obsidian) je konfigurační soubor v:

/usr/lib64/gcon­v/gconv-modules.d/gconv-modules-extra.conf

Nebylo by lepší zakázat v konfiguráku rovnou všechny tyhle exotické znakové sady?

Nebo vypnout všechny a povolit si jenom ty, které se doopravdy používají? :-)

A ty pak budes resit, proc to ci ono nefunguje, protoze nekdo do pole napise slovo treba azbukou?

Na vse vam staci Unicode, ty individualni codepages dnes uz nepotrebujete k zivotu, pokud nezijete v nejake obskurni zemi, ktera chce mit svuj vendor-lockin monopol s legacy kodovanim.

Takze nezijes v CR predpokladam ... a rozhodne nekomunikujes s urady.

Jestli nekdo napise na muj server slovo azbukov tak leti o tom zadna. ;o)