2Zdeno Sekerák: Vstupy se osetruji na vstupu = napises si jednu funknci a tu volas nad kazdym vstupem. A vstupem se mini predevsim to, co prichazi zvenku = od knihoven tretich stran, od uzivatele, ... tzn tam, kde nevis co tam muze byt. Pokud ty pises tak, ze nevis co je vystupem jedny fuknce kterej predavas jiny jako vstup, tak je neco spatne predevsim s tebou.
Ošetřování vstupu (escapování) je většinou jen méně špatná varianta. V první řadě bych se ptal, jak se mohlo stát, že došlo k záměně parametru (hodnoty, dat) a kódu. Tyhle věci by měly být striktně oddělené.
Když to přirovnám k SQL, tak správným řešením jsou parametrizované dotazy – je jasná hranice mezi SQL kódem (ten je součástí programu) a parametry (ty pocházejí zvenku) a nikdy se nemíchají, nikdy nedojde k tomu, že by se parametry/data interpretovala jako SQL. A v tom parametru může být klidně tisíc apostrofů nebo libovolných znaků, a nikdo to ošetřovat/escapovat nemusí.
za tohle může unix a bash, z té doby pochází řada magických znaků uvnitř textu, které se nějak interpretují či jejich čtení.
On toho je linux plný, získat roota jen tak, že šikovně pojmenuji soubor, který pak vezme bash script a začne ho zálohovat je přesně ten případ, který má stejné důsledky jaho tohle, ještě v době, kdy jsem to tolik neřešil jsme takhle na hostingu získávali roota, abychom si mohli sami dělat některé úpravy, dnes už bych to hned hlásil a choval se k tomu zodpovědně, před 15, 20 lety z toho člověk mě i zábavu.
Lebo ten názov súboru posúvajú ďalej ako parameter do nejakého externého programu. A namiesto toho aby používali funkciu s API typu execve() (parametre sa dávajú ako pole), radšej používajú funkciu s API typu system() (má to jeden parameter, shell string). Rôzne knižnice (Glib, Qt, ...) poskytujú pseudo-funkcie na "shell escape", tak sa všetci tvária, že varianta so system() je predsa bezpečená a aj správna...
Skúste sa pozrieť ako tento problém v KDE opravili. Na nejakom mieste zavovali funkciu na "shell escape".
Inak podobný problém mal nástroj GParted, interpretoval názov súboru (ak napr. obsahoval bodkočiarku, tak oheň bol na streche). Bug som oznámil a nechceli mi veriť, že by sa to nejak dalo zneužiť... Našťastie po ukážke to bolo opravené.
Ale me by treba nikdy nenapadlo pojmenovat disk/odil shellovym prikazem
Tohle se asi nestane náhodou, to je jen sprostě zneužitelná chyba a něco, s čím nemůže počítat ani dostatečně kvalifikovaný uživatel.
Diskutuje se zde o srovnání s autorunem ve Windows. To není úplně přesné. Ve Windows to byl velmi hrubý neodhad od Microsoftu, něco takového zavádět. Ale poté se s tím už dalo počítat, autorun zakázat nebo třeba kontrolovat antivirem. Žádná sláva, ale aspoň něco.
> Takže nejen že to byl hrubý neodhad vedoucí k jasné (a v praxi
> zneužívané) kritické zranitelnosti, ale místo okamžité opravy bylo až
> do (tuším) Windows 7 nutné používat workaround? To opravdu
>nesnese srovnání :)
Pokud vím, autorun se dal zakázat. POvažoval bych jej za vlastnost, i když poněkud neštastně nastavenou ve výchozí konfiguraci.
Podle mě by daleko lepším přirováním než autorun byl průšvih způsobený speciálně upravenými LNK soubory (protože někdo omylem použil funkci LoadLibrary místo LoadLibraryEx).
Nebyla by to první ani poslední dobře míněná vlastnost, ze které se nakonec stala díra :) Ani mi nijak nevadí že k tomu omylu došlo, ale doba než to bylo vypnuto byla zbytečně dlouhá. Vždyť to ani není vlastnost na které by ten systém stál. Ano, zkušený uživatel si to může vypnout. Kolik to nechalo potenciálně zranitelných zařízení? Proto to podle mě nesnese porovnání s bugem v KDE. Ten je opraven okamžitě
(a za obojím stojí chyba. To první je chybné rozhodnutí, to druhé chybně napsaný kód. V obou případech autory při psaní nenapadlo možné zneužití)