Názory k článku
Notebooky Samsung s UEFI je možné zničit i z Windows
-
Lael Ophir (neregistrovaný)
Ten člověk sice psal 36kB, ale v kódu má 48kB. K těm 48kB je třeba přičíst jména proměnných (zřejmě v UTF-16) a již existující obsah, takže se dost možná na těch 64kB dostal.
A co tam zapisoval kernel Linuxu? To asi ještě nikdo neví :), ale dost pochybuji, že by opravdu šlo jen o 10kB. Dost možná třeba 10kB při každém crash dumpu (tj. při každém bootu), s tím že se položky nemazaly. Nebo to mohl být jen jednou 1MB. Vzhledem ke "kvalitě" kódu, kterou demonstruje třeba samsung-laptop a intel e1000/dtrace, bych se nedivil vůbec ničemu. -
To jo. Vždycky dostáváme přednášku o tom, jak komunita nemůže napsat dobré ovladače bez dokumentace, že to dokážou jen odborníci od výrobce HW nebo z Microsoftu, a teď se ukáže, že ten nejzprasenější kód si výrobce napsal sám. Jen na Windows je to snadnější odpálit, protože je to obecně děravější systém.
Teď jsem zvědavej, jak dlouho bude Microsoftu trvat vydání záplaty. Linuxová tu byla skoro hned. -
Lael Ophir (neregistrovaný)
Výrobci často produkují mimořádně příšerný kód. Nakonec proto také MS má ty certifikační testy.
Vidím že to máte fakt "jednobitové" :D
'na Windows je to snadnější odpálit' - nesmysl; na Windows může takhle bricknout stroj jen admin, na Linuxu admin, instalátor a kdokoliv s přístupem do /sys/firmware/efi/vars
'Linuxová tu byla skoro hned' - další nesmysl. Modul byl zakázán, takže s novým buildem distra možná stroj nebricknete (a nepůjde vám pár řada věcí jako podsvícení klávesnice), ale chyba samozřejmě existuje dálDetaily zde:
http://www.root.cz/zpravicky/notebooky-samsung-s-uefi-je-mozne-znicit-i-z-windows/448027/ -
Lael Ophir (neregistrovaný)
Uživatel SYSTEM pokud vím nemá priviledge Modify firmware environment variables. Nicméně má SE_IMPERSONATE_NAME, takže se může chovat jako jakýkoliv jiný účet.
Prasácké aplikace vyžadující admina lze většinou celkem triviálně pouštět pod běžným účtem, jen je potřeba upravit permissions pro některé objekty (například pro config files umístěné v "Program Files\<aplikace>"). -
Lael Ophir (neregistrovaný)
Kroťte vášně :). Dosud známé technické detaily chyb jsou zde:
http://mjg59.dreamwidth.org/22855.html
http://www.codon.org.uk/~mjg59/scratch/brick_samsung.txt
https://patchwork.kernel.org/patch/2087041/Krátce shrnuto: modul samsung-laptop provádí nějaké divoké a nepodporované modifikace paměti BIOSu, které s řadou modelů nebyly nikdy testované, a mohou a nemusí fungovat. Bohužel je provádí i když se zabootuje v UEFI módu, dost možná kvůli problému s funkcí efi_enabled, který je popsaný v třetím linku. A protože při UEFI bootu ta modifikovaná paměť BIOSu není k dispozici, skončí to crash dumpem. Crash dump se zapíše do UEFI storage space, a tam dojde k dalšímu problému. Samsung tam totiž má nějaký bug, díky kterému při zápisu většího počtu velkých variables dojde k bricknutí. Těžko říct, co tam vlastně díky samsung-linux nakonec skončí.
Ve Windows se pochopitelně dá způsobit podobný problém. Pokud ho lze způsobit kódem běžícím na Linuxu, jistě to jde i kódem běžícím na Windows :). Na Windows i Linuxu lze problém způsobit z user mode. Ve Windows pomocí API SetFirmwareEnvironmentVariableExA, které vyžaduje priviledge Modify firmware environment variables (tedy by default pouze admini stroje). Na Linuxu lze použít /sys/firmware/efi/vars nebo funkci sysfs_create_variable.
http://msdn.microsoft.com/en-us/library/windows/desktop/jj204594(v=vs.85).aspx
http://uefivars.git.sourceforge.net/git/gitweb.cgi?p=uefivars/uefivars;a=blob;f=src/lib/efivars_sysfs.c;h=0928f1059cd56cf573e01d1bd52b3853d0d75bf8;hb=0fedc43067cdb31e22aab3f75bc73f9220a51284Pokud se vám podaří bricknout tímto způsobem notebook, stačí odpojit napájení, vyjmout baterii a knoflíkovou "CMOS-baterku" a chvíli počkat (nezapomeňte obě baterie a napájení zase vrátit :D). Znamená to bohužel rozebrat stroj.
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557/comments/23Jako velmi vtipný mi přijde komentář na bit-tech.net, kde píšou, že za to Linux vlastně nemůže. Jasně. Samsung-laptop používá nepodporovaný interface, a to i na modelech na kterých to nikdy nebylo testováno, a i pokud ty modifikované BIOS variables vůbec neexistují, což vede ke crash dumpu. Ale je to vlastně celé v pohodě, a Linux je nejlepší. Ještě mohli dodat, že když nepodporované rýpání v paměti BIOSu fungovalo s jedním modelem od Samsungu, tak jistě bude stejně fungovat i na všech dalších modelech, a že testování je vlastně změkčilost - nakonec od čeho máme uživatele :D. Pak už by to bylo dokonalé.
http://www.bit-tech.net/news/bits/2013/02/11/linux-samsung-deaths-2/1 -
>...stačí odpojit napájení, vyjmout baterii a knoflíkovou "CMOS-baterku" a chvíli počkat (nezapomeňte obě baterie a napájení zase vrátit :D). Znamená to bohužel rozebrat stroj.
Tesi me, ze reseni je tak trivialni. Az si budete nekdo kupovat notebook, tak doporucuji Samsung. Nejen, ze maji nejlepsi BIOS, ale k odpojeni/vymene zalozni baterky staci pouze rozebrat stroj. Doufam, ze pro vyssi komfort uzivatelu patri Samsung k tem vyrobcum, kteri do svych stroju davaji baterky s pajecimi kontakty zaletovanymi do moba, takze k vymene neni treba niceho komlikovanejsiho, nez demontaz moba.
-
Lael Ophir (neregistrovaný)
K odpojení záložní baterky je potřeba rozebrat každý stroj který znám, včetně desktopů.
Podobné problémy jako tento Samsung má jistě i spousta jiného HW. Problém je v tom, že Linux provádí řadu nepodporovaných operací nad HW, které nikdy nebyly zkoušeny na konkrétním modelu zařízení, takže nikdo neví, co to vlastně udělá. Házet vinu na Samsung je nesmyslné. Ano, Samsung má zřejmě bug v implementaci UEFI. Ale modul samsung-laptop je netestovaný hack ve formě fialového hnusu, který by neměl být na *žádném* stroji.
-
Je rozebrat a rozebrat. Na inteligentne zkonstruovanem nb je baterka treba pod deklem, pod kterym je disk nebo pamet. A neni zaletovana, ale v patici nebo alespon s dratkem a konektorem, coz uz je otrava, ale lepsi nez nic. Na desktopu sundate jeden dekl a baterku vydloubnete. Naproti tomu jsou noteooky, ktere musite rozebrat temer do posledniho sroubku a jeste pouzit pajku. Jejich konstrukterum preji rakovinu mozku.
-
Jack (neregistrovaný)
Jenže on to taky často neni žádnej omyl nebo náhoda...
Netušim jestli se to pořád praktikuje, ale v době popularity BIOS hesel a jejich variant (který byly i propagovaný výrobci jako super zabezpečovací systém) se tohle dělalo schválně, aby případný zloděj nemohl jen tak vyloupnout baterku a heslo nikde.
Primitivní, ale při řádnym "schování" baterky poměrně účinné. Ani bych se nedivil, kdyby to pořád někde měli jako jednu ze zásad návrhu...
A konstruktérovi s jasnym zadánim shora bych rakovinu až tak nepřál ;-)
PS: A všichni si zkusíme odpustit poznámky, jak nesystémový, nespolehlivý a buhvíco ještě řešení to bylo :-D
-
Lael Ophir (neregistrovaný)
Ještě jsem si všiml, že autor toho kódu pro Windows používá funkci SetFirmwareEnvironmentVariableExA, což je ANSI verze té funkce. Jenže UEFI tuším pracuje v UTF-16. Tohle (plus již existující obsah UEFI storage) vysvětluje, proč i 48kB zápis dovede stroj bricknout, přesto že podle MS specifikace musí mít UEFI storage minimálně 64kB.
Jsem zvědavý, co a v jakém množství do toho UEFI storage nakonec modul samsung-laptop nacpe. Ale nepochybně někdo z diskutérů má notebook Samsung a volný večer :)
-
Neviditelný (neregistrovaný)
ANSI a Unicode verze SetFirmwareEnvironmentVariableEx() se liší jen tím, že první jmenovaná vyžaduje první dva parametry typu LPCSTR, druhá LPCWSTR. Na formát nebo velikost zapsaných dat to nemá vliv. Nic to nemění na tom, že jakkoliv může být ovladač samsung-laptop nesprávný, mělo by dojít nanejvýš ke kernel panicu, rozhodně ne k poškození stroje, které si vyžaduje demontáž.
-
Lael Ophir (neregistrovaný)
Většina API pracuje s daty v Unicode UTF-16 (BTW včetně frameworku Qt), a systém s daty interně pracuje v UTF-16. Unixy jsou v tomhle trochu výjimkou, což je dané historicky (v době psaní tradičních Unixů Unicode neexistoval, a v době psaní Linuxu to Linusove asi vůbec nenapadlo řešit).
Pokud UEFI ukládá data v UTF-16, tak se stringy s 8-bitovými chary převedou na UTF-16, a pak až uloží. Tedy zabírají více místa, než kolik by člověk předpokládal z délky parametrů. -
Neviditelný (neregistrovaný)
S tím si dovolím nesouhlasit. UEFI používá pro kódování znaků UCS-2, ne UTF-16 (fajn, to není až takový rozdíl). SetVariable() dle specifikace UEFI 2.3.1 dostává vstupní data jako VOID pointer, žádná implicitní konverze na UCS-2 se tedy neprovádí. I technicky by to byl problém, když není známo, v jaké znakové sadě byla původní data (a zda vůbec šlo o text). To samé platí o SetFirmwareEnvironmentVariableEx(); pokud se tato funkce snaží vstupní buffer převést na UCS-2, jde o nedokumentované chování. V případě, že je UEFI variable storage pamět plná, má funkce vrátit EFI_OUT_OF_RESOURCES, ne umrtvit počítač:)
-
Lael Ophir (neregistrovaný)
Takže vy nevidíte problém v tom, že samsung-laptop modifikuje paměť BIOSu nedokumentovaným způsobem, ani v tom že to dělá i když se bootovalo přes EFI, ani v tom že se ten modul používá na laptopech které vývojář nikdy neviděl, natož aby na nich ty nedokumentované modifikace paměti BIOSu zkoušel, a tedy se neví, jestli to vůbec bude fungovat? Pak to máte fakt jednoduché.
-
Lael Ophir (neregistrovaný)
Buffer se nepřevádí. Nicméně jména proměnných jsou v UFT-16 (OK, možná UCS-2), a ten linkovaný kód je posílá v charech, takže dochází ke konverzi těch jmen. Jinými slovy množství zabrané paměti je v tomto scénáři větší, než kolik byste soudil z velikosti vstupních parametrů.
Samozřejmě přeplnění UEFI storage space by měla vrátit chybu - nakonec chování na Samsungu jsem také popisoval jako bug. -
Neviditelný (neregistrovaný)
EFI_GUID = 16 bytů, UCS-2 string o 10 znacích ("TestVar%d\0") = 20 bytů, náhodný buffer v kódu Matthew Garretta = 1024 bytů, celkem tedy 1060 bytů. To celé * 48 = 50880 bytů. Možná se provádí ještě nějaké zarovnání, ale pokud byla před spuštěním tohoto kódu variable storage prázdná, nemohlo IMHO dojít k jejímu přetečení. Proto mi přišlo divné, že problémové stroje dostaly Microsoftí certifikace.
-
xxx (neregistrovaný)
Ve slovenštině existuje ne úplně přesný, ale poměrně výstižný ekvivalent "dojebat". Dotyčný výraz je navíc možno s úspěchem používat i v češtině. Krátké překladové cvičení: "některé notebooky firmy Samsung, které bootují pomocí UEFI, mohou být dojebány pouhou instalací linuxové distribuce."
-
Karel (neregistrovaný)
To není přesný překlad. Dojebat lze HW mnoha způsoby a do různých stavů. Já už několikrát dojebal PC tak, že pomohl jen boot z live CD a reinstalace OS. Což jsem sice dojebal pěkně, ale ne dost na to, abych to bricknul.
"Bricknout" je podle anglického "brick", což popisuje technické možnosti takto postiženého HW. Prostě je z toho mrtvá cihla a už to na nic nereaguje. Softwarem už se to opravit nedá. Někdy to ani hardwarem nejde zachránit (pokažená data v EEPROM, která je zapájená na desku a nemá vyvedený JTAG nebo něco podobného, díky čemuž by šla přepsat).
-
Ono jde o to, ze ve Widlich to jde jeste mnohem snaze, nez v Linuxu. Teoreticky by stacila chyba v Solitaire a je to. Uz jen s napetim cekam, kdy se objevi prvni malware, ktery bude kosit notebooky Samsung s Widlemi po milionech. A taky jsem ziskuchtivy, jak se k tomu pak postavi soudruzi ze Samsungu, kdyz vyrobili tak uzasny smejd.
-
Lael Ophir (neregistrovaný)
A co třeba aplikace pro update firmwaru zařízení? Když může přemazat firmware ona, může to udělat i jiná aplikace (samozřejmě s oprávněním admina). User mode aplikace sice tyhle věci udělat nemůže, ale zato může použít API, které propadne na driver, případně si ten driver nainstalovat (opět pokud má oprávnění admina).
ČLÁNKY DO MAILU