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
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é.
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.