Vlákno názorů k článku Virus badBIOS: vážná hrozba, nebo nesmysl? od Petr M - Zatím mám furt pocit, že z tím bude...
-
Petr M (neregistrovaný)
Zatím mám furt pocit, že z tím bude nějaká nemoc z povolání.
Na jednu stranu, BIOS má potenciál ovlivnit chování všech systémů, pokud používají jeho služby (kdysi sloužil jako HAL), ale teď má možnost ovlivnit asi jenom spuštění zavaděče a zneviditelnit HW moduly, protože systémy mají svoje ovladače...
Ohledně komunikace po zvukovce, není problém použít nějakou formu PSK modulace a úroveň signálu může být nižší než u šumu. Měl jsem něco podobnýho pokusně udělanýho na jednočipu. Okolní hluk tomu vůbec nevadil. Jenomže průšvih byl, že to bylo potřeba hodně přesně naladit a vyfiknout z toho jednu frekvenci. Nevěřím ale, že se to povedlo univerzálně pro jakýkoliv HW. Přenosovka by byla mizerná, max. desítky kB/s, pokud se spokojí s velkou chybovostí...
Navíc je potřeba stejný soft na obou stranách. A na potvoru je to v pásmu, který neslyší člověk, ale třeba pes se začne chovat neklidně... A odhalit to osciloskopem by neměl být větší problém. Otázka je, proč to ten expert ještě nezkusil.
-
a (neregistrovaný)
napadá mě k tomu také pár podobných otazníků jako vás:
Repráček v PC nemá moc výkon a s druhou mocninou vzdálenosti klesá hlasitost zvuku. Takže dosah nic moc.
Pro komunikaci musí na druhém PC běžet stejný komunikační SW. Spoléhat na situaci, kdy se oba stroje infikovaly přes USB nebo LAN a že potom budou komunikovat pomocí zvuku je méně pravděpodobné než přenos jejich vzdálené komunikace skrze Aštana Šerana. Přes původní infikační kanál by to bylo jednodušší. Situace, kdy se dva počítače "přeřvávají" svými repráčky, to je skoro jako z italské komedie :-DNerozumím tomu, jak to myslíte s tím, že je to v pásmu, které neslyší člověk. Repráčky počítače nejsou audiofilskou sestavou, která je schopna přehrát ultrazvukové frekvence.
-
Rob (neregistrovaný)
Taky je potřeba zdůraznit, že intenzita zvuku ve vzduchu klesá nejen se čtvercem vzdálenosti, ale také je útlum silně závislý na kmitočtu, čím vyšší kmitočet tím vyšší absorbce (na jednotku vzdálenosti). Proto na větší vzdálenosti je slyšet jen nízkofrekvenšní složky a vyšší kmitočty jsou potlačeny.
-
Lael Ophir (neregistrovaný)
To máte zřejmě na mysli atmosférický útlum. Ten záleží na frekvenci. Při 20 stupních, tlaku 101.3kPa a relativní vlhkosti 50% se u 20kHz dostanete na 0.524176 dB/m. U 1kHz je to sice jen 0.004664dB/m. Je to sice značný rozdíl, ale na druhé straně jde o minimální útlum v porovnání s tím, že inverse square law vám ubere 6dB s každým zdvojnásobením vzdálenosti.
http://resource.npl.co.uk/acoustics/techguides/absorption/
http://www.sengpielaudio.com/calculator-distance.htm -
Mirek_ (neregistrovaný)
Jak kvalitní mají integrované zvukové karty vzorkování, je úplně jedno. Kvůli šumu mikrofonu a předzesilovače na zvukovce se z toho reálných dat nedostane rozhodně ani 16 bitů. Nehledě na to, že si místnost někteří asi představují jako útlumový článek, ale nic není dál od pravdy. Ozvěny, dozvuky atd., i kdyby se to podařilo přenést, ještě by byl potřeba náročný DSP.
Až mi to někdo použitelně předvede, tak mu začnu věřit, jinak ne. -
Petr M (neregistrovaný)
Na vzorkovací frekvenci 44,1kHz se dá v BPSK na jedné nosné vysílat na 22,05kHz nosné. Bit může být řekněme 10 period (přenosovka 2kBity). Generování signálu je triviální, stačí střídat dvě úrovně a pokud vysílá nulu, jednou za bit nechat stejnou polaritu, aby se otočila fáze. Filtr na výstupu z toho udělá celkem hezkou sinusovku.
Na přijímací straně by to ale s PC nešlo spolehlivě chytat, protože se nedá pověsit fázový závěs na konkrétní frekvenci, protože by neprošla filtrem. Takže musí jít níž... Ale může to být maskovaný pískáním zdroje...
-
MarSik (neregistrovaný)
Cože běží "vedle"?
BIOS není z hw hlediska nic jiného než pár bajtů, na které na začátku ukazuje instruction pointer. Jakmile se pustí OS, tak už rozhodně nic neběží (a rozumný OS si přenastaví interrupty). Tedy pokud se OS nerozhodne nějakou funkci z té paměti pustit sám.
Citace ohledně System management node (abyste viděl, že fakt "vedle" neběží):
SMM is entered via the SMI (system management interrupt), which is caused by:
- Motherboard hardware or chipset signaling via a designated pin SMI# of the processor chip. This signal can be an independent event.
- Software SMI triggered by the system software - čti operační systém - via an I/O access to a location considered special by the motherboard logic (port 0B2h is common).
- An IO write - opět operační systém - to a location which the firmware has requested that the processor chip act on.Aby tohle šlo použít pro virus, tak by někdo do té flash musel dostat kód, který inicializuje harware stejně jako originální BIOS, umí na usb mass storage zapsat data, která nabootují a přepíšou BIOS na napadeném stroji (tak že ten taky opět nabootuje) a ve vhodnou chvíli způsobí zavolání svého kódu z napadnutelného OS. Jinak v normálním OS opravdu nemůže ovlivnit, který soubor se zkopíruje a který ne..
Pokud se bavíme ještě o komunikaci přes zvukovou kartu, tak to už je úplně utopie, jelikož by 1) musel umět komunikovat s konkrétní zvukovou kartou (Ac97?) a 2) hlavně by musel umět tu komunikaci začít ve chvíli, kdy druhá strana opravdu něco vysílá, a to bez toho aby poškodil stav zařízení, který předpokládá driver v OS (jinak se prozradí).
Jak jsem tedy už napsal na začátku, žádný BIOS kód po inicializaci stroje implicitně neběží. Jediný způsob jak z něj něco pustit je interrupt (pokud ho OS nepřenastavil) nebo přímé volání z OS.
-
To je sice hezký, ale můžu potvrdit, že SMI se na systému objevují dosti nahodile. Někdy ani výrobce mainboardu není schopen přesně říci, jaké akce mohou SMI vyprovokovat… Z hlediska univerzálního viru je to spíš nevýhoda, ale kdyby cílil na nějaký konkrétní hw, tak to zneužitelné je.
Z jiného soudku, co takové Service Processory, které mají v podstatě všechny serverové systémy i leckterý notebook (třeba můj Thinkpad). Ten běží opravdu paralelně s OS a má také přístup k hw (např. USB, síťovka i speaker zcela určitě).
-
Nojo, to oni samozřejmě vědí, že ten pin SMI# z procesoru vede třeba k řadiči SCH3114, jenomže taková informace je dost k ničemu. Cituji z datasheetu:
The nSMI group interrupt output consists of the enabled interrupts from each of the functional blocks in the chip and many of the GPIOs and the Fan tachometer pins. The GP27/nIO_SMI/P17 pin, when selected for the nIO_SMI function, can be programmed to be active high or active low via the polarity bit in the GP27 register.
Takže záleží na tom, jak je ten chip naprogramovaný, co všechno je k němu připojené (samozřejmě přes sběrnici!), a na které všechny I/O operace ty připojené periferie reagují požadavkem na vygenerování SMI. To už ani výrobce obvykle neví rovnou a dohledat to v projektové dokumentaci je pro něj dost složité, aby to kvůli obyčejnému zákazníkovi či partnerovi neudělal. Ano, pokud máte možnost výrobci podržet nůž na krku a vyhrožovat, že s ním nepodepíšete smlouvu za X milionů USD, dokud takovou podrobnou dokumentaci nedodá, tak to samozřejmě z dokumentace vyčte a přehledně dodá…
-
petr_p (neregistrovaný)
Slovo „vedle“ bylo obrazné. Ve stejném smyslu jako uživatelský proces běží „vedle“ jádra operačního systému. Zrovna tak jako proces nemůže vědět, kdy jej operační systém přeruší a co bude dělat, tak úplně stejně operační systém nemůže vědět, kdy jej SMI přeruší a co bude BIOS v SMM dělat.
SMM například vadí realtimovým aplikacím, a proto u lepších mašin je možné některé události obsluhované SMM vypnout. Najděte si IBM PRTM.
A jak už bylo napsáno níže, SMM se například používá na řízení chlazení, to je činnost veskrze periodická. Takže je to pěkné místo, kam umístit kód. A není to otázka jen teoretická. Existují demonstrace. Dokonce před několika lety se ukázalo, že řada BIOSů zapomíná vypnout jistý bit v MMU, který umožňuje nabourat se do fyzické paměti vyhrazené pro SMM.
Okecávat to můžete jakkoliv, ale je fakt, že kusy kódu BIOSu běží i po nabootování.
-
MarSik (neregistrovaný)
Jaké obkecávání? Já nikde nepsal, že SMI ten kód nespustí.
Jenže když to spojíte s těmi ostatními informacemi o tom "viru" a s tím, že BIOS musí umět inicializovat a obloužit dost složitý hardware, který je na "každé" desce teoreticky připojen na jiný procesorový pin nebo jinou adresu, tak zjistíte, že teoreticky to asi využít jde, ale zajistit šíření bude velmi náročné.
Na druhou stranu "BIOSů" je relativně málo a budou dost copy&paste, takže pokud by někdo uměl vytáhnout specifickou konfiguraci, upravit sám sebe a zapsat se, tak by teoreticky mohl doufat v korektní provoz alespoň na příbuzných deskách.
Vaše demostrace se týká napadení jednoho stroje a logování kláves, ale to je dosti jiná úloha. Využití SMM pro skutečný vir by vyžadovalo netriviální spolupráci (i nedobrovolnou :) OS, který na daném stroji běží.
-
petr_p (neregistrovaný)
Já jsem zase pro změnu nic nepsal o dalších vlastnostech recenzovaného viru. Jen jsem rozporoval větu, že po nabootování BIOS skončil.
Pokud bych se měl pouštět do spekulací ohledně „skutečný vir by vyžadoval netriviální spolupráci OS“, tak si dovolím poznamenat, že dnešní BIOS obsahuje řadu ovladačů. Takový UEFI nemá problém přimountovat USB mass storage a provádět na něm souborové operace. Hypotetický virus tedy může využít rutiny ve firmwaru již obsažené. A kdo si dnes všimne hlášky jádra Resetting USB device? Problémy s nekonzistencí řadičů lze vyřešit odložením I/O na dobu vypnutí nebo zapnutí stroje.
