Vojtěch Pavlík: umřel Hyper-threading?
Pokud náš procesor má několik jednotek, dokáže vykonávat instrukce napřed. Když se procesor dostane na rozcestí, třeba je tam podmíněný skok, musí se rozhodnout, jestli půjde tam nebo jinam.
Proto potřebuje výsledek podmínky, která rozhoduje, kam se má vydat. Ta může být poměrně složitá, může potřebovat nějaký výpočet. Procesor ale tyhle výsledky ještě nemá.
Může se buď zastavit a počkat nebo se některé právě nepoužívané jednotky mohou jedním směrem vydat.
Může si tak udělat práci napřed, spekulativně, do zásoby. Co když to ale nakonec není správně? Procesor se snaží všechny důkazy zlikvidovat. Jenže se mu to nepodaří úplně, něco vždycky zbude.
Není to nic, co by bylo architekturálně vidět, ale jsou ovlivněny třeba keše, do kterých je pak možné se podívat. To je paměť integrovaná v procesoru, která je velmi rychlá.
Procesor si do ní ukládá svá data, aby je měl při příštím požadavku na jejich čtení rychle k dispozici.
Základem spekulace je takzvaný pipelining, tedy postupné zpracování, podobně jako na páse v továrně. Práce s instrukcemi je rozdělena na jednotlivé kroky: načtení, dekódování, spuštění, zápis. Na každém hodinovém tiku se provádí jedna z těchto věcí, ve skutečnosti je těch kroků mnohem více, takže budou trvat dlouho.
Většinu času pak většina součástí procesorů stojí: když se instrukce načítá, všechny ostatní jednotky musí čekat. Bylo by možné takhle ale zpracovávat více instrukcí najednou: jedna instrukce se může dekódovat a jiná se zpracovává. Jako na běžícím pásu.
Všechny jednotky pak běží zároveň a tím se nám znásobí výkon jen tím, že jsme lépe zorganizovali práci. Průšvih je, když nám do toho vstoupí skok.
Když výrobci procesorů nacpali do procesorů spoustu jednotek, zjistili, že jedno vlákno má v sobě příliš mnoho závislostí, aby efektivně využilo celý procesor. Virtuálně tak rozdělili procesor na dva, mezi kterými jsou skoro všechny části sdílené, kromě registrů.
Tím ale založili na další problém, protože oba virtuální procesory sdílejí keš. Původně Hyper-threading zvyšoval výkon o několik procent, ale v moderních procesorech je tolik výkonných jednotek, že se získaný výkon blíží ke dvojnásobku. Skutečně se to tedy chová tak, jako byste měli dva procesory.
Pokud pak na jednom procesorovém jádře běží legitimní i útočný kód, je možné zneužít sdílenou L1 keš k tomu, aby útočník získával data z cizího procesu. Není to moc silný útok, útočník nemůže přečíst data z keše, ale může si měřením doby přístupu odhadnout, jaká data drží druhý proces.
Postupně byly algoritmy upraveny tak, aby tento útok nebyl možný, protože jejich chování není datové závislé. Později se ale objevily nové typy útoku.
Každý proces má v paměti takzvanou page table, která mapuje virtuální adresní prostor na fyzický. To znamená, že při každém přístupu do paměti musí procesor nutně sáhnout do tabulky stránek a pak až do paměti. Z jednoho přístupu máme dva, to je dvojnásobné zpomalení.
Proto byla zavedena TLB, translation lookaside buffer, což je vlastně keš pro tabulku stránek. Pokud už informace v procesoru je, je její příští použití velmi rychlé.
Z toho vznikl útok TLBleed, kdy se dva procesory neperou o L1 keš, ale o informace v TLB. Útočník má možnost invalidovat obsah TLB a zjišťovat, co se do ní dostává z druhého procesu.
Tento útok už je prakticky použitelný.
Součástí paměti stránek je také takzvaný supervisor bit. Když běžný proces potřebuje skákat do jádra, máme dvě možnosti: můžeme buďto přepnout tabulky stránek, vysypat TLB a po návratu vše vrátit zpět. Abychom to nemuseli dělat, můžeme do jednoho paměťového prostoru namapovat jak paměť procesu, tak i jádra. Proces ale do té části paměti nemá přístup, ten má naopak jen jádro. Pak není potřeba nic přepínat a je to velmi rychlé.
Výrobci procesorů ale zavedli optimalizaci, kdy se nastavení bitu při spekulaci ignoruje a kontroluje se až při potvrzení správnosti spekulace. Je tak možné napsat program, který spekulativně přistupuje k paměti jádra a podle stavu keše přečte stav.
Tomuto útoku se říká Meltdown a brání se mu pomocí KPTI.
Ukázalo se, že při spekulaci procesor zároveň ignoruje také present bit, který říká, že v dané paměťové oblasti nějaká data pro daný proces jsou. Nemůžete každému procesu alokovat všechnu jeho paměť při spuštění. Paměť se alokuje až při použití.
Protože procesor při spekulaci opět bit nekontroluje, je možné takto přistupovat k cizí paměti. Tento útok se jmenuje L1TF (nebo Foreshadow), který je nebezpečný především pro virtualizační prostředí, kde si jeden virtuál může nastavovat vlastní L1 keš a tím si zvolit, ke kterým skutečným paměťovým stránkám bude mít přístup. Lze to řešit tím, že při přepínání vysypeme L1 keš, což sice stojí výkon, ale není to tak dramatické.
Horší je to v případě, že virtualizační stroj používá Hyper-threading. Keš je pak sdílená, takže je možné přistoupit k datům sousedního virtuálu.
Proto se dnes pro virtualizaci doporučuje Hyper-threading vypnout, což ale znamená až poloviční ztrátu výkonu. Je to netriviální chyba v procesoru, ale bohužel je v praxi zneužitelná.
Letos byly objeveny další chyby, které se byly pojmenovány Fallout, Zombieload a RIDL – souhrnně MDS (Microarchitectural Data Sampling). Umožňují sledovat buffery mikroinstrukcí, které procházejí procesorem z L1 keše. Výrobci na to zareagovali další instrukcí, která dovoluje vylít L1 keš. Stále tedy vyprazdňujeme keše, což nás stojí výkon, ale vypadá to bezpečně.
Opět do toho ale vstupuje Hyper-threading, kdy pokud některý proces usne, jsou celé buffery realokovány běžícímu vláknu včetně dat. Opět se to neprojevuje na architekturální úrovni, ale stačí nám to k časovacím útokům.
Řeší se to tak, že se na jednom skutečném procesorovém jádře spouštějí jen související vlákna. To vypadá dobře, jenomže to nefunguje, protože procesy volají jádro. Není sice možné krást data ze sousedního vlákna, ale můžeme do paměti jádra.
Totéž platí pro virtualizaci, kdy si mohou takto paměť vyčítat jednotlivé virtuály.
Pokud používáme Hyper-threading, máme vážný problém. Doporučuje se tedy zejména ve virtualizačních prostředích podporu této technologie vypnout. Existuje nápad, jak problém řešit. Jeden proces může při skoku do jádra vyprázdnit keš, pošle přerušení druhému procesorovému jádru, které se zastaví a po návratu se pak vše rozeběhne. Je to ale pravděpodobně pomalejší než Hyper-threading úplně vypnout.
Podle Vojtěcha Pavlíka není všem dnům konec, protože další chyby se budou jistě ještě objevovat. Zatím jsme se proběhli asi po 15 % celého procesorového jádra.
Radomír Orkáč: Hesla? Hesla! Hesla?
Radomír Orkáč je penetrační tester ze sdružení CESNET, který se ve své přednášce podělil o své zkušenosti. Při penetračních testech se setkáváme s tím, že lidé používají slabá hesla doma i v práci.
Jak získat uživatelovo heslo? Prostým hádáním, lámáním, opakovaným používáním, čtením z paměti či phishingem.
Každému penetračnímu testu předchází příprava. Je potřeba zjistit co nejvíce informací z veřejných zdrojů nebo třeba firemní dokumentace. Divili byste se, jak moc nám dokumentace pomáhá. Dozvíme se třeba, jak musí být heslo dlouhé, jaké znaky se v něm musí objevit a podobně.
Výrazně to dovoluje zmenšit prostor pro hádání hesel.
Velkým problémem hesel je jejich předvídatelnost. Ze statistik vyplývá, že ve 40 % případů bývá první písmeno velké, poslední pak bývá číslice. Ve čtvrtině případů má heslo na konci číslo. Velmi často jsou základem běžná slova, nejčastěji: heslo, martin, jana, tereza a eliska. Velkým problémem je také nucená pravidelná změna hesla. Uživatel v takových případech mají základ hesla a mění na začátku nebo na konci nějaká čísla.
To pomáhá penetračním testerům, ale bohužel i útočníkům.
Online hádání hesel je možné používat jen na začátku testů, protože je velmi pomalé. Cílem je získat alespoň prvních několik účtů, které nám pomůžou třeba do VPN.
Je potřeba si dát pozor na zamykání účtů při mnoha neplatných pokusech a podobné ochrany.
Pokud je penetrační test v pokročilé fázi, získají útočníci haše hesel a můžou se pokusit je prolomit. Na grafické kartě jste schopni lámat hesla obrovskou rychlostí. Na jedné kartě vyzkoušíte 42 miliard hesel hašovaných NTLM za sekundu.
Rychlost pak klesá se složitostí haše, ale zase je možné paralelizovat. Během jednoho dne jsme schopni prolomit libovolné NTLM heslo do devíti znaků.
Pokud už se testerům podaří získat nějaké heslo, zkusí ho opakovaně pro různé účty. Správci mají často stejné heslo k běžnému účtu i k rootovskému. Případně se setkáváme s tím, že se liší jen malou úpravou.
Silné heslo je například doplněno o .linux. Hesla bývají také velmi často nevhodně uložená: v souboru hesla.txt, dekódovatelná hesla, hesla v prohlížečích a podobně. Často se dostaneme například k zálohám profilů Firefoxu, kde jsou uložená hesla.
Phishing není snadné rozpoznat, naletět může každý. Neděláme kopii původního webu, ale uděláme reverzní proxy, která ukazuje originál.
Uživatel nemá možnost rozdíl rozpoznat, pokud se nepodívá do URL. Všimnete si třeba zvláštní domény cesnet.bz?
Michal Špaček: Zámečky nikoho nezajímají
Tvůrci prohlížečů postupně skrývají původně výraznou ikonu zeleného zámečku u HTTPS. Zámečky už dnes nejsou zelené, v tmavém režimu jsou třeba bílé. Aktuální statistiky ukazují, že ve Spojených státech je 88 % stránek načteno po HTTPS.
Uživatelé dnes zámeček víc vidí než nevidí. Není to počet webů na HTTPS, těch je podle odhadu 30 až 50 %. Ale když má někdo web bez HTTPS, na který nikdo nechodí, tak ať ho má.
HTTP se postupně vytrácí, mnoho služeb postupně se svým API přechází na HTTPS. Mozilla dokonce v loňském roce přešla jen na HTTPS.
Projevuje se to také v adresním řádku. Zatímco dříve bylo HTTP běžné, postupně je označováno za zastaralé, aby to uživatelé začali vnímat. Nakonec bude HTTP označeno červeně za nezabezpečené.
Abychom se k tomuto stavu mohli dostat, je potřeba dělat některé další úpravy. HTTPS může být také špatné, protože například používá zastaralé šifrovací protokoly.
Prohlížeče některé zastaralé protokoly používají a v případně útoku je možné downgradovat. Proto bude příští rok ukončena podpora TLS 1.0 a 1.1. Aby si toho tvůrci všimli, začnou prohlížeče před touto situací varovat.
Podle Špačka je možné podporu těchto protokolů už vypnout, protože je moderní prohlížeče už nepodporují. Pokud zpracováváte platební karty, nesmíte dokonce podle pravidel už TLS 1.0 používat.
Na druhé straně spektra je označení zabezpečeného webu, které bylo dříve výslovně v adresním řádku uvedeno. Co ta informace ale znamená? Pořád tu máme weby, které mají HTTPS, ale kvůli špatné konfiguraci není spojení bezpečné.
Dnes už je zámeček šedivý, už u něj není informace o zabezpečení. Postupně zámeček úplně zmizí, protože to bude normální stav. Viděli byste ho pořád, takže bude jen zabírat místo.
Úplně také zmizí informace o použitém protokolu a také například předpona www. Pro uživatele bude takový stav přehlednější a běžný uživatel snadněji pozná, že je na správném webu. Je to kontroverzní změna, ale mně se to nakonec líbí.
Prodejci certifikátů se stále snaží tvrdit, že nejlepší je EV certifikát, který zvyšuje důvěryhodnost. Pravidla pro vystavování těchto certifikátů přímo říkají, že EV není určen k tomu, aby prokazoval důvěryhodnost držitele.
Uživatel také nemá možnost ověřit, zda na daném webu má být EV certifikát. Například PayPal rok EV certifikát neměl a nikomu to nevadilo.
HTTPS by podle Michala Špačka mělo být všude, ale je jedno, jaký certifikát používají. Neučte lidi na zámečky, ty časem zmizí. Nevěřte také adresnímu řádku, protože ten lže.
Věroš Kaplan: Jak udělat pomalý web
Věroš Kaplan je nájemný správce serverů, který má spoustu zkušeností a zážitků s mnoha klienty, kteří si pořídili slabý hosting a mají pomalý web. Nebo mají super silný server, ale web je pořád pomalý. Takže to úplně tím serverem být nemusí.
S nejběžnějšími problémy se rozhodl podělit na své přednášce.
Typickým problémem jsou pomalé odpovědi od serveru. Když jsem třeba na e-shopu, tak potřebuji rychlou odezvu. Chytří lidé vypátrali, že když je e-shop příliš pomalý, lidé mají tendenci odejít jinam.
Provozovatel webu pak přijde za správcem, že by chtěli „zapnout tlačítko rychlost“. Zkoušel jsem takové najít, ale nepodařilo se mi to. Obvykle má každá aplikace takových tlačítek víc a dělají různé věci.
Při načítání stránky se prohlížeč připojí k serveru, pošle na něj zprávu a dostane odpověď. Když je je všechno v pořádku, může se odpověď rozebrat a na základě výsledku se pak pošlou další požadavky.
I poměrně jednoduchá stránka totiž k zobrazení potřebuje spoustu dalších objektů, které je třeba stáhnout.
Na webu je spousta chytrých rad, jak si web zrychlit. Je možné například nasadit HTTP/2, ale to vás obvykle nezachrání, protože řeší jen přenos k uživateli. Obvykle je to ale rozbité vzadu, takže sice něco ušetříte, ale není to zlatá lžička.
Podobně rada zapnout kompresi obvykle nic neřeší, protože pomůže jen minimálně a jen při přenosu. Pomoct může zmenšení CSS a obrázků, ale pokud je pomalá aplikace v pozadí, nepomůže to.
Další rada je použít CDN, což odlehčí našemu serveru, ale nezrychlí to naši aplikací.
K problému lze přistoupit také hrubou silou a pořídit silnější server. Pokud zjistíme, že úzkým hrdlem je opravdu výkon serveru, tak se to vyplatí. Ale stojí to peníze a ne každý zákazník je ochotný do toho investovat.
V některých případech to ale může opravdu pomoci. Když jsme nedávno migrovali web mezi poskytovateli hostingu, zrychlili jsme ho jen přesunem asi dvakrát. Ten původní byl opravdu ošklivě udělaný.
V první řadě je potřeba odhalit úzké hrdlo, které může být na různých úrovních: šířka přenosového pásma, výkon pevného disku, množství paměti, výkon procesoru, počet procesů a podobně. Omezení může být celá řada a obvykle na ně narazíte, až dojde k problému.
Pomůže v tom dobrý monitoring, který je schopný hlídat různé komponenty a také sbírat různé metriky. Osvědčilo se nám hlídat, jak rychle je nám schopná aplikace odpovídat.
To pomůže odhalit rychle nějaký skrytý problém, který je pak možné dohledat a vyřešit.
Per Thorsheim: What if I could be… you?
Per Thorsheim se hesly profesionálně zabývá 19 let, dělá výzkumy týkající se hesel a jak sám říká, je jimi posedlý. V roce 2016 byl požádán organizací US National Cyber Security Alliance, aby vytvořil nová doporučení pro dobrá hesla. Jsou to: používejte věty jako hesla, každý účet by měl mít unikátní heslo, zapište si svá hesla, nasaďte dvoufaktorovou autentizaci. Spousta lidí netuší, že v hesle mohou být mezery. Spousta lidí si myslí, že heslo musí být jedno slovo.
Lidé jsou velmi špatní v pamatování hesel, měli by si je proto zapisovat. Klidně si je zapište na kus papíru. Tahle rada většinou lidi vyděsí.
Banky dokonce lidem radí, aby si nikdy hesla nikam nepsali. To je úplná pitomost,
říká Thorsheim. Svojí mámě říkám, že je bývalá učitelka a není cílem zájmu tajných služeb. Neměla by žít ve snu Jamese Bonda.
Uživatelé by měli ideálně používat správce hesel, ale pro mnoho z nich je to příliš složité a papír jim může poskytnout stejnou službu.
Velmi silným řešením je dvoufaktorová autentizace, která se velmi rychle šíří, zejména díky mobilním telefonům. Bohužel se v mnoha případech potvrzovací zprávy stále ještě používá automatizovaný telefonický hovor, SMS nebo dokonce e-mail. E-mail je dlouhodobě nejdůležitějším útočným vektorem při snaze dostat malware do firem,
varuje Thorsheim.
Per Thorsheim v roce 2017 měnil mobilního operátora a překvapilo ho, že k transferu stačilo jeho jméno a číslo. Požadavek pak putoval pomocí e-mailů. Té super bezpečné internetové technologie.
Za tři dny dorazila nová SIM karta a Per se stal zákazníkem nového operátora. Kdyby to někdo udělal za mě, měl bych méně než 48 hodin na reakci. Co kdyby to udělal, kdybych zrovna spal?
Překvapivě snadno tak lze získat cizí SIM kartu a začít přijímat všechny zprávy na jiný telefon. V případě problémů můžete požádat o rychlý transfer, ale ten bude trvat tři až čtyři hodiny. Když budete na poradě a až poté zjistíte, že vám nefunguje telefon, máte problém.
Na začátku roku to v Norsku vyzkoušeli v praxi novináři, kteří navštívili prodejce mobilních služeb a prokázali se jen jednoduchou vizitkou. Stačilo to k tomu, aby zařídili převedení služeb jiného člověka (který v tomto případě o pokusu věděl) na novou SIM. Útok dostal název SIMSWAP a dovoluje jednak převzetí celého účtu nebo je možné získat druhou kartu se stejným číslem. Oběť nic nepozná, oba telefony budou zvonit a na oba přijdou stejné zprávy.
Mobilní operátoři v některých státech nabízejí možnost zvolit si doplňkový PIN či heslo, které jsou pak nutné při transferu služeb. Nevím, jestli v České republice něco takového někdo nabízí, ale v Norsku to neumí ani jeden operátor.
Během přednášky byla předvedena možnost velmi jednoduchého podvržení odesílatele u odeslané SMS. Pokud dostanete nějakou zprávu nebo vám někdo zavolá, nemůžete věřit informaci o zdroji. Je velmi snadné je podvrhnout.
Jednoduché řešení neexistuje.
V Norsku také došlo ke zneužití služby SMS copy, kterou nabízí jeden z operátorů. Dovoluje odesílat kopie zpráv také na jiné telefonní číslo nebo na e-mail. Protože operátor neumí dvoufaktorovou autorizaci a umožňuje používat velmi slabá hesla. Takto se jeden člověk dostal do mnoha služeb 50 žen a zničil jim život. Nenávidím ho za to, že něco takového udělal!
Pokud by někdo něco podobného udělal s politiky, umělci nebo dalšími významnými uživateli, mohl by způsobit velké škody.
Petr Stehlík: Novinky o ESP8266/ESP32
Populárním mikrokontrolerem je už mnoho let ESP8266, což je vlastně 32bitový procesor s různými rozhraními a Wi-Fi. Dřív jsem se mu posmíval, že má málo vstupů a nikdy to nebude Arduino. Dnes je to nové Arduino, navíc za málo peněz.
Přesto má některá omezení, která se výrobce snažil vyřešit v nástupci ESP32, který obsahoval spoustu novinek. Nacpali tam všechno, co se dalo, je tam všechno možné.
Tohle jsou ale staré informace, Petr Stehlík se ovšem věnoval především novinkám. Jednou z nich je podpora rozpoznávání řeči, která je k dispozici dokonce i pro ESP8266. Dnes jsme zvyklí na různé cloudové služby, které nás odposlouchávají. Tady je to nacpáno přímo do procesoru.
Podobně zajímavé je rozpoznávání obličeje, které je k dispozici pro ESP32. Je to úžasné a velmi levné.
Pomocí ESP je možné řídit také 3D tiskárnu díky portaci software Marlin. Můžete si tak postavit vlastní 3D tiskárnu a máte v ní i konektivitu.
Existují také mini herní konzole (WiFiBoy32, ODROID-GO a další). Lze si také postavit vlastní dron ESPcopter nebo si pořídit spoustu výrobků do domácností od chytrých žárovek až po žaluzie. Výhoda je, že si můžete software libovolně upravovat.
V hardware se objevily také zajímavé novinky, společnost Espressif vydala vlastní vývojové kity pro tvorbu zvuku, rozpoznávání obrazu a řízení domácnosti. Na AliExpressu se roztrhl pytel s vývojovými deskami, k dispozici je doslova záplava hotových IoT řešení s ESP8266.
Při vývoji se už dnes ale doporučuje používat ESP32. Je to jednodušší a nemusíte nesmyslně optimalizovat a předělávat kód. Už to není cenový problém.
Jediným důvodem použití starší verze může být zralejší softwarové prostředí.
Vývoj probíhá také v software, Espressif vyvinul nové nástroje pro připojení k Alexa SDK, GoogleCloud SDK a Apple HomeKit SDK. Základním vývojovým prostředím je ESP-IDF, která je v současné době ve verzi 3.3. Je to první verze LTS s dlouhodobou podporou minimálně dva a půl roku. Dříve se to velmi divoce měnilo.
Další variantou je ESP NONOS SDK, který je nově ve třetí verzi, ale zatím přináší především mnoho nových problémů, takže se většina vývojářů drží starší dvojkové řady.
V oblasti programování se objevila nová NodeMCU Lua 3.0, která přinesla Lua Flash Core. Když napíšete program v C, má minimální velikost a běží přímo v procesoru. Interpretovaný kód ale vyžaduje interpreter, který zabírá velkou část paměti.
Zásadní novinkou je proto možnost běhu kompilovaného Lua kódu přímo z flash paměti a není potřeba je mít v RAM. V Lua teď tedy můžete psát výrazně větší kód.
Lua také v NodeMCU neměla také pořádné IDE, nově je k dispozici online rozhraní chilipeppr.com. Kromě Lua je možné programovat také v MicroPythonu, který dovoluje využít pro uložení kódu externí RAM připojenou přes SPI. Díky LLVM pro ESP jsou k dispozici také TinyGO a Rust.
V ESP bylo v nedávné době objeveno několik chyb v implementaci Wi-Fi, které umožňují shodit zařízení injektáží paketů a nabourání šifrované komunikace s EAP. Espressif vydal opravy jako součást nového SDK. To ovšem znamená, že musíte aktualizovat software ve svém ESP, ale ten musí obsahovat nejnovější SDK.
To ovšem není samozřejmostí, protože řada tvůrců se zatím nejnovějším verzím z různých důvodů vyhýbá. Nedávno bylo prolomeno šifrování paměti v ESP, takže je možné přečíst libovolný kód.
Úplnou novinkou je čip ESP32-S2, které obsahuje jedno 32bitové procesorové jádro LX7. Umožňuje adresovat více paměti, má více GPIO, má rozhraní pro displej a USB. Naopak to má mnohem méně RAM, chybí mu Bluetooth a Ethernet.
Zároveň chybí CAN, IR, Hall senzor a na aktuálních vzorcích nefunguje zmíněné USB. Vůbec nevím, co s tím. Někteří říkají, že to je mezi ESP8266 a ESP32. Já si myslím, že je to úplně mimo tuhle řadu.
(Foto: Gabriel Seidl, LinuxDays)
ČLÁNKY DO MAILU