Názory k článku
KDE je zranitelné, stačí připojit disk do USB

https://xkcd.com/1700/

Chybou?

Stačí spustit třeba blkid /dev/disk/by-name/${label}

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.

Každý systém má hranici, vstupy se testují jen jednou - na ní.

To je taky řešení na hovno. Správným řešením je komunikační protokol mezi systémy nezávislý na jejich vnitřních implementacích.

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

Autorun je naprosta prkotina ... protoze dvoklik na cokoli == exec cokoli. Kdyz je to cokoli.jpg a uvnitr je to exe, tak to widle proste spusti(ly), dneska je to jak tu nekdo zminil obaleny nejakou izolackou.

Hezké a praktické.

super věcička....zlatý Widličky :-(

jeste nedavno rovnou spustilo kod. Dokonce na tom byla postavena jedna ochrana audiocd od SONY :D

Od dob Windows 7 u flashdisků vyskočí okno. Na první pohled je to bezpečné. Na ten druhý si člověk všimne checkboxu "příště provést automaticky a už se neptat". Dobrá věc je, že na seznamu akcí není autorun. Takže spustit se "to" nedá, volby jsou typu "zobrazit v průzkumníkovi", "spustit přehrávač videa" apod.

Ani CD/DVD už nemá autorun. Podle nastavení buď vyběhne podobná nabídka jako u flash disku (s tím, že tady v seznamu možností autorun je, takže spustit se "to" dá), nebo se nestane nic. Defaultní nastavení "home edice" je, že to nedělá nic, takže fóra jsou plná lidí se stížnostmi "strčil jsem DVD s hrou do mechaniky a ono nic".

https://blogs.technet.microsoft.com/srd/2009/04/28/autorun-changes-in-windows-7/

Asi to uz nie je aktualne, ale jeden cas to fungovalo tak, ze ak bol an USBcku zadefinovany autorun, jeho spustenie bola jedna z moznosti, ktore Ti ponuklo to okno. Dalo sa to zmanipulovat tym, ze exe aplikacia mala nazov "Browse files on this device" a nastavenu ikonu totoznu s ikonou foldra vo windows. Mnohi si to tym padom pomylili s "oficialnou" moznostou prechadzania suborov.

Stává se to všem, i výrobcům hardwaru. Například routery Netgear (ale i ostatní) byly postiženy podobnou chybou. Vložením kódu no pole "název zařízení" byl spuštěn libovolný kód. Bohužel byla současně objevena u jejich routerů i chyba, která umožňovala snadno a vzdáleně obejít přihlášení. I windows 10 umožňují obejít heslo správce za pár minut.

Až na to, že Windowsy majú stále bugu v escapovaní prvého znaku vo FAT labeli. Kto nevie o čo sa jedná... vo FAT adresárovej štruktúre ak názov položky začína bajtom 0xE5, tak má špeciálny význam a znamená, že súbor je zmazaný.

Label vo FAT je interpretovaný voči aktuálnej OEM code page a tá je vo Windows implikovaná regionálnym nastavením. Napr. v CP850 je znak Õ na mieste 0xE5. A CP850 sa používa v regionálnom nastavení English UK.

Stačí si teda vo Windowse nastaviť reginálne nastavenie na English UK, reštartovať a zmeniť label nejakého FAT disku napr. na ÕTEST...

Různé kódové stránky a převod, popřípadě interpretace např. unicode je kapitola sama o sobě (viz. "mailsploit" spoofing). Zrovna před půlhodinou se objevila na serveru BC zpráva o chybě v aplikaci Telegram windows client, která zobrazuje název přílohy jinak, než jak příjde ze serveru. Konkrétně jde o znak pro formátování zprava doleva. Pokud je na konci jména souboru "...*U+202E*gnp­.js", zobrazí se to jako "...sj.png", ale spustí se skript pro těžbu.

Řešit takové chyby musí byt peklo. Zvlášť když řetězec projde několika serverovými službami, z nichž každá nakládá se znakovou sadou po svém.

`rm -rf /*`

Tohle projde, jen musím být pod rootem.

Konečně vlastnost linuxu, kterou oceňuji, pokud si pro mě příjde policie, stačí mít na stole podobnou flashku, zasunout a důkazy jsou fuč :)

`rm -rf /*` taky potrebuje --no-preserve-root? Nejak se mi to nechce zkouset ;)

nepotrebuje, nejdrive se provede bash expansion a rm to uz pak nekontroluje

Taky se obavam, protoze se to expandne na nejaky `rm -rf /bin /boot /dev /etc /home /initrd.img /initrd.img.old /lib /lib64 /lost+found /media /mnt /opt /proc /root /run /sbin /srv /sys /tmp /usr /var /vmlinuz /vmlinuz.old` a to asi fakt projde...

`rm -rf ~` ako trest staci, nie? :D

. /tmp/xx

Pravda, předpokládá to, že ten skutečnej průser už na disku je, ale technicky vzato to zadání vyhovuje :) První mě napadla fork bomba, ale ta je naštěstí 14...

Aj ja som si to vyskusal, a mne to nefungujeee... Fnuk-fnuk.
Aha, to je vlastne dobre, ze?

Ze by to bolo tym, ze mam este KDE4 a nie ten patkovy zazrak? Tak som sa v tom povrtal, a fakt!
Uplne najlepsie je to, ze v stvorkovych zdrojakoch je pouzite expandMacrosShe­llQuote() (teda to iste, co vo fixe tohoto bugu pre KDE5). Takze tu chybu tam zaniesli az s KDE5.

Dobre to chlapci hnoja, len co je pravda. Hlavne treba vsetko zakazdym prekopat a namastit tam nove zbytocne chyby (a tato bola teda fakt zbytocna). Uz sa tesime na KDE6!!!

Proc se vubec s labelem v te aplikaci takhle pracuje ? Nejak me nenapadaji duvody proc bych mel brat label zarizeni a cpat jej nekam do execu ?
Dyt label slouzi snad jen k zobrazeni uzivateli, pokud se pouziva i k necemu jinemu tak je asi neco spatne ne ?

Co jsem se tak dival na kod toho .cpp kde tato chyba byla, tak me teda moc nenadchl, napr. reseni case sensitivity v switchi: https://cgit.kde.org/plasma-workspace.git/tree/soliduiserver/deviceserviceaction.cpp?id=f32002ce50edc3891f1fa41173132c820b917d57#n103
nebylo by pouziti QString.toLower() lepsi reseni ? nebo mi neco unika ? (nemam cas si projit cely projekt - jdu ted spat)

Tuším, že label sa používa ako adresár, kde sa disk pripojí. Takže nejaký mkdir /media/<user>/<la­bel> a potom mount. (Teraz ma napadlo, že treba vyskúšať, čo sa stane ak label bude obsahovať lomku...)

Ale ako som písal vyššie, zostaviť si argumenty ručne a dať ich do execve-like funkcie je bezpečnejšie, tam sa shell neaplikuje.

A čo sa týka zdrojákov, to je normálka. Nad nejakým case sensitivity v switchi sa ani netreba pozastavovať.

No to je trochu blbost ne ? Co kdyz budu mit dva flashdisky se stejnym label ? :-D
Ja mel za to ze jako automaticky mountpoint se pouziva nejake UUID ... ano ted jsem to vyzkousel i u FAT se pouziva UUID, /run/media/user/4F67-E98B Takze stale nechapu proc se v tom kodu cpe label nekam do exec, zacina mi to pripadat jako spraseny navrh

Ne nedochazi mi to, ~ a $HOME jsou jen zjednoduseni aby prihlaseny user nemusel psat celou cestu k svemu home/stupidne ji hledat, nejak nevidim spojitost s label u FAT svazku, to ma byt jako dalsi zjednoduseni aby se BFU neztratil ? stale mi prijde pouziti nazvu svazku z nejakeho neznameho USB zarizeni nekde jinde nez jako text buttonu v nejakem GUI klikatku jako prasarna... kdyz tu mame pro potreby systemu UUID (ktery je sice take v FS, ale chranit jeden vstup je jednodusi nez dva)

> Ne není to blbost. Uvažujete příliš jednoduše. Zkuste si to, nechci vám to prozrazovat, nebylo by to překvapení :D

Nemam tu zadne dalsi zarizeni s FAT, a formatovat kvuli tomu nic nehodlam... typuji ze se pri konfliktu LABEL pouzije UUID nebo LABEL+'-1' etc. to ale stale nevysvetluje proc pouzivat LABEL misto UUID...

No jestli tedy oprava znamená, že se tady ten label escapuje a vznikne tedy na disku adresář s takhle veselým jmenem... tak jen čekám, kdo ho vezme a zase použije někde tak jak je, bez escapování.

SQL má bind proměnné, tohle by bash a system() taky potřebovaly... Za SQL injection si programátoři mohou sami, obrana je většinou jednoduchá (OK, ne vše je proměnná co se dá bindnout), ale speciální znaky v bashi jsou prostě peklo.

> Co kdyz budu mit dva flashdisky se stejnym label

Pozerám, že aj systemd-udev rieši tento problém, ale svojsky :-)
$ ls -l -a /dev/disk/by-label/

No, on ten return +-2 také není žádné krása.