Apple představil nový MacBook Pro s čipy M4, M4 Pro a M4 Max.
Na GOG.com běží Halloween Sale 2024. Při té příležitosti lze získat zdarma počítačovou hru Return of the Phantom.
Společnost OpenAI spustila internetový vyhledávač ChatGPT search.
Konference OpenAlt 2024 proběhne již tento víkend 2. a 3. listopadu v prostorách FIT VUT v Brně. Začíná ale už v pátek na warm-up party ve Studentském klubu u Kachničky v 17:00. Pokud jste ještě areál FITu nenavštívili, k dispozici jsou pokyny k orientaci. Na programu je 54 přednášek a workshopů. Témata jsou od silně technických témat jako je třeba GCC nebo PostgreSQL po méně technické témata jako eGovernment, nebo třeba detailní analýzu … více »
Byla vydána nová verze 6.9 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 14.0.1. Tor client na verzi 0.4.8.13. Thunderbird na verzi 115.16.0.
Vývojáři free a open source synchronizačního nástroje (a p2p náhrady Dropboxu) Syncthing oznámili, že z důvodu odporu ze strany Google Play ukončují podporu OS Android. Bohužel v rámci toho zmizí i vydání Syncthing na F-Droid, který má slabší uživatelskou základnu. Syncthing je na Androidu implementován formou wrapper aplikace, která spustí Syncthing démon, vyžádá potřebná oprávnění a zpřístupní webové rozhraní démona. Ve srovnání se
… více »V červnu 2022 bylo oznámeno, že z K-9 Mailu se stane Thunderbird pro Android. Trvalo to poněkud déle, než vývojáři předpokládali, ale včera byl první stabilní Thunderbird pro Android 8.0 vydán.
Projekt microDMG Racer na Kickstarteru nevyšel, tak se autor rozhodl uvolnit na ESP32 postavené autíčko i ovladač jako open source.
Byl vydán TrueNAS SCALE 24.10 „Electric Eel“. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Byla vydána nová verze 24.10.29 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nově s podporou AI (whisper.cpp) pro generování titulků. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
# curl -L https://meltdown.ovh -o spectre-meltdown-checker.sh # bash spectre-meltdown-checker.sh (...) CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK CVE-2019-11135:OKNa Intel i některých ARM strojích tam mám několik CVEček "červených".
Intel dava vic per MHz/coreJen a pouze diky jejich 14++++++++++. Na 10nm jsou v riti jak Bata s drevakama, topi jim to a neuchladi ani ty frekvence, co dosahuji ted na 14nm. Takovyhle fanboism neni nejlepsi metodou, jak si dobre vybrat, ale samozrejme si klidne utracej, za co chces
Protože v datových centrech, univerzitních i firemních, drtivě převažuje Intel, zaměřuje se výzkum chyb v procesorech (který vyžaduje spoustu výpočetního času, aby se chybu podařilo prozkoumat a spolehlivě reprodukovat) pochopitelně spíš na (snáze dostupný) Intel než na AMD. Proto je možné, že AMD má "v záloze" pár dalších, dosud neobjevených bezpečnostních chyb. Snad se poučili z chyb odhalených u Intelu (resp. u Intelu a AMD zároveň).
Jak se vyvine Power9? Samozřejmě je na Power9 jak Meltdown, tak Spectre. Příslušné opravy jsou ve firmwaru i v kernelu. Mají pochopitelně dopad na výkon.
Sny o "lepší cestě" mi někdy připadají úsměvné. Už jsem o tomhle diskutoval s cca 10 lidmi, kteří snili o bájné bezpečnosti Power9 natolik intenzivně, že se neobtěžovali zadat do vyhledávače jeden jednoduchý dotaz, zda má Power9 Meltdown a Spectre.
To je tak zavádějící "vysvětlení", že to až hraničí se lží. Realita je taková, že většina těch chyb je způsobena tím, že Intel při spekulativním provádění instrukcí ignoroval většinu kontrol s tím, že je stačí provést až při provádění "naostro", čímž procesoru ušetří práci v případě, že se větev nakonec zahodí. To byla zásadní chyba, protože už sama skutečnost, že se instrukce provedla, i když jen spekulativně, má různé vedlejší efekty, které jsou odhalitelné útočníkem (např. u Meltdownu to bylo načtení příslušné cacheline). U AMD nebyli tak neopatrní a do téhle pasti nespadli. Zpětně už se asi nedozvíme, jestli to bylo proto, že si to nebezpečí uvědomili, nebo proto, že prostě jen byli opatrnější.
Navic ve skutecnosti vsechny tyhle chyby vadej tak maximalne provozovatelum cmoudu.
Jistě, a to, že k některým existují veřejně dostupné exploity implementované v javascriptu, které se dají pustit přímo v prohlížeči, je jen iluze.
AMD se naopak cele roky snazili implementovat obdobne technologie a techniky, jen v tom opet cele roky zaostavaji
Raději si o tom konečně něco přečtěte nebo si třeba pusťte nějakou přednášku, na webu je jich plno. Zjistíte, že rozdíl u většiny těch problémů opravdu není v tom, že u AMD neimplementovali nějakou techniku, ale v tom, že je neimplementovali tak bezhlavě a potřebné kontroly provádějí i při spekulativním běhu. To sice stojí trochu výkonu, ale jak se ukázalo, vyhnou se tím leakování informací přes postranní kanály.
Dukazem je prave to, ze drtiva vetsina tech zranitelnosti tam funguje taky.
Tak se podívejte třeba na ty výpisy, které jsem sem dával včera. AMD procesorů se týká jen ta část Spectre vulnerabilities, která je v podstatě nevyhnutelným důsledkem spekulace jako takové (takže se týká i non-x86 architektur), a u novějších modelů SSB. Žádný Meltdown, žádné L1TF, žádné MDS, žádné TAA, žádný iTLB multihit. To má být ta vaše drtivá většina?
Jistě, a to, že k některým existují veřejně dostupné exploity implementované v javascriptu, které se dají pustit přímo v prohlížeči, je jen iluze.
Můžu poprosit o ty zdroje? Protože zjistit, co SKUTEČNĚ lze dneska skrze JavaScript z paměti dostat je, bez pročítání desítek vědeckých článků (a tam stejně většinou ty proof-of-concept kódy nejsou) zhola nemožné... A DTTO se skutečnými dopady těch záplat v jádře. Pokuď je například průměrná ztráta výkonu 25% a reálně se lze dostat pouze k datům daného webu (díky site-isolation v browserech) nedává moc smysl mít ty záplaty na desktopu zapnuté, obzvlášť na běžném 6 let starém desktopu, kde je každé procento výkonu už znát.
To, že v (některých) prohlížečích jsou implementovány workaroundy, které omezí praktickou proveditelnost útoku přes javascript, neznamená, že problém neexistuje. Pokud si opravdu stojíte za tím, že u desktopu není žádný problém, když může normální uživatel celkem pohodlně číst jakoukoli paměť jádra (nebo kohokoli jiného), co je pak vlastně špatného na tom, když se uživatel na začátku přihlásí jako root (nebo Administrator) a pracuje pod ním?
Musím říct, že jakkoli je to strašné, musím obdivovat efektivitu PR mašinerie Intelu. Jeden z největších bezpečnostních průšvihů se jim podařilo odignorovat tak, že většina poloodborné veřejnosti si z něho odnesla, že je to vlastně drobný technický problém, který netřeba brát vážně a hlavně se má primárně řešit úplně někde jinde, než kde je příčina. Autoři téhle scény jsou proti nim žabaři.
Netvrdím, že to není žádný problém, ale ta praktická proveditelnost útoku je zásadní. Teoreticky lze veškerá vaše data z počítače získat pomocí klíče za pár dolarů, ale prakticky se to tak většinou nedělá...
A co se týče toho roota/admina, tak z hlediska bezpečnosti dat - a o ty jde - je (na jednouživatelském stroji) uživatelský přístup samozřejmě zcela ekvivalentní s tím rootovským. To rozdělení na user/root procesy je čistě z technických/praktických důvodů ale z hlediska bezpečnosti dat je zásadní jestli ty procesy jsou důvěryhodné, nebo ne (jestli mi bankovní účet někdo vybere pomocí uživatelského nebo rootovského procesu je úplně irelevantní).
To opravdu není....uživatelský přístup samozřejmě zcela ekvivalentní s tím rootovským..
Bavíme se tady o standardním jednouživatelském linuxovém desktopu, což je explicitně zmíněno v tom příspěvku, protože celá ta diskuze je o praktické proveditelnosti útoků V DANÉM PROSTŘEDÍ. Takže vytahovat tady Windows a "rodiče a děti" je stejně mimo, jako kdyby někdo k původnímu "JavaScriptovému" příspěvku začal psát, že "v cloudu je to ale obrovský problém" (ano je, ale o tom ta diskuze není...).
To je furt dokola. Když z výrazu "jednouživatelský desktop" vynechám "jednouživatelský" a "desktop", dostanu multiuživatelský server a tam to problém je, to už ale víme...
I co se týče služeb, tak z hlediska Meltdown/Spectre útoků (o kterých celá tato diskuze je), je podstatné pouze to, zdali se spouští nějaký neautorizovaný kód. A to se v případě, že neprovozuješ hosting/cloud nespouští.
"Nevoněl" mi především ten tvůj přístup useknout ten výrok před tou klíčovou informací o jednouživatelském systému. To, že čím víc se posunuješ k multiuživatelskému využití, tím víc najdeš případů, kde nějaký rozdíl je, tu nikdo nerozporuje.
Žádný vlákno, který by přinášelo nějaký relevantní informace tady nevidím... (A ne, ten fragment kódu z roku 2018 opravdu relevantní informace není).
Jenom aby bylo jasno, já netvrdím, že v prohlížečích aktuálně žádný reálný problém není. Jenom se snažím dobrat k tomu, jaký je skutečný stav věcí, tzn. čeho dnes v běžných podmínkách opravdu lze pomocí JS a Spectre/Meltdown zranitelností dosáhnout. V obchodu se strachem jsem totiž dělal dost dlouho na to, aby mně nějaký třísekundový video na Youtube přesvědčilo o závažnosti situace...
Však já se taky nebavím pouze o originálních Spectre a Meltdown zranitelnostech ale nazývám tak celou tu rodinu zranitelností založených na problémech se spekulativním vykonáváním kódu. Ještě jsem neviděl, že by někdo vypisoval vždy všechny ty zranitelnosti jednotlivě, protože z popisu: "Spectre/Meltdown/ZombieLand/RIDL/Fallout..." by se každej brzo zbláznil...
Problém tvrzení o tom workaroundu s časovačema je, že to vůbec nevystihuje současný stav věcí. Viz například pěkné shrnutí na blogu V8 nebo podrobněji viz git Chromia. Problém toho linku o RIDLu pak zase je, že v jejich repozitáři s PoC není aktuálně žádný JS kód... Jediný co jsem s JS našel je to video na hlavní stránce. A to je prostě málo.
A konečně k tomu přístupu. Nikdo netvrdí: "Jo, je to chyba, ale nevím, jak se dá zneužít, tak to nemá cenu řešit.", jak se mi snažíš podsunout. Ten původní dotaz zněl a stále zní: "Jaké jsou reálné možnosti zneužití (stojí to za snížení výkonu)?". Protože jestliže "in the wild" aktuálně nejsou (a nikdy nebyly) pozorovány žádné reálné JS útoky na tyto zranitelnosti, je někde zcela jistě nějaký "problém".
Stále nechápu, odkud bereš ten nesmysl, že tu chybu neakceptuju. Já rozhodně nezpochybňuju, že pokud máš přístup k "železu", tak je ta chyba (a tím myslím libovolné z těch desítek CVE) zneužitelná. Mě ale zajímá i to, zdali je (s aktuálními prohlížeči) zneužitelná i pomocí JavaScriptu. Tzn. zdali se týká i běžného desktopu a je nutné kvůli ní obětovat nezanedbatelnou část výkonu.
Já píšu, že jen neakceptuješ možnost její zneužitelnosti, protože nemáš nějaký example kód, který ti někdo naservíruje až pod nos a nedokáže ti to.
Neakceptuju reálnou možnost zneužitelnosti, pokud neexistují důkazy, že taková možnost existuje (nelze prostě paušálně tvrdit, že něco určitě půjde zneužít, s takovým přístupem by se nedal počítač používat vůbec). A z toho co jsem o RIDL dohledal to nevypadá, že by existovala. Jejich POC útok přes JavaScript totiž vypadá tak, že si "pro jednoduchost" upraví JS jádro aby vracelo přesný čas a odkáží se na dříve publikované metody, jak lze takový dostatečně přesný čas v JS získat. Jenomže tyto metody (např. SharedArrayBuffers) už jsou taky v aktuálních JS enginech nefunkční. Navíc s v prvním příspěvku zmíňenou site-isolation nepočítají zdá se vůbec. Samozřejmě je tu riziko, že se objeví nějaká další metoda, ale reálný stav věcí (neexistence reálných útoků) ukazuje, že míra toho rizika nebude příliš vysoká.
Jako sorry, prevence je základ a pokud ty chceš mít nezaplátovaný PC, tak si ho měj, ale nechlub se s tím v diskusích a nesnaž se to navíc obhajovat.
Promiň, ale tvá kvalifikace v oblasti bezpečnosti očividně opravdu není na takové úrovni, aby si mohl někomu určovat co může a co nemůže říkat/dělat.
Nikdo tady lidem neradí, aby ignorovali prevenci. Jediné co tady "radím" je, že je vhodné zvážit rizika a dopady a podle toho se rozhodnout. Přijatelná míra rizika i přijatelné dopady a výsledný "poměr" je pro každého jiný. Pro korporátního ajťáka je samozřejmě nejjednodušší obětovat jakýkoliv výkon i za infinitezimální snížení rizika, protože on na tom nesnesitelně pomalém počítači pracovat nebude, zatímco případný bezpečnostní problém dopadne na jeho hlavu. To ale neznamená, že je tento přístup vhodný pro každého...
To ale neznamená, že je tento přístup vhodný pro každého...Samozřejmě, protože "každý" za rozhodnutí, že riziko je malé, málokdy nese následky. Když někomu vyberou účet kvůli ukradenému heslu, je to odpovědnost banky, když počítač někomu zneužijí k útoku, náklady na řešení nese oběť... Kvůli lidem, jako jste vy, jednou legislativci zavedou takové zákony pro IT, že se nebudeme stačit divit.
Univerzální výmluvu, aby nemuseli nic dělat tady mají především "experti" Max Devaine a Jiří Bourek. A tou výmluvou je - "nerozomíme tomu, tak radši všechno zakážem (i za cenu velkého poklesu výkonu)". Protože zjišťovat přesné informace o bezpečnostních problémech samozřejmě je pracné (ale ne nemožné, jak se nám tu "experti" snaží namluvit).
Osobně bych ani s tímto přístupem "expertů" neměl zas až takový problém, kdyby tito "experti", kteří nejsou schopni provést ani tak základní krok jako analýzu dopadů těch chyb, neměli tu drzost tady ostatní, kteří mají k problematice poněkud serióznější přístup, častovat výroky typu "by neměli mít administrátorský přístup ani k vlastnímu počítači" nebo "nechlub se s tím v diskusích a nesnaž se to navíc obhajovat"...
Analýza reálné zneužitelnosti bezpečnostních chyb není zlehčování dopadů těch chyb.
Jak se člověk citováním výroků druhých pasuje na lháře mi trochu uniká, ale možná to bude tím, že ten tůj příspěvek je velmi slabý nejenom argumentačně, ale i jako útok ad hominem...
Abych předešel další zbytečné diskuzi - neprovedl jsem samozřejmě analýzu všech dosud zveřejněných Spectre/Meltdown chyb na zneužití z JS (stav 11/2019), ale pouze té, kterou "expert" Max Devaine označil jako: "víme, že je ještě jednodušeji zneužitelná, než předchozí Spectre a Meltdown". Což dle mé analýzy rozhodně není.
To, zda-li je někde dostupná aktuální analýza zneužitelnosti z JS (a samozřejmě případně příslušné POC) k celé této rodině bylo právě předmětem dotazu, který celou tuto "expertní diskuzi" rozpoutal. Bohužel místo nějakých argumentů zde padají akorát primitivní urážky od pseudoexpertů Maxe Devainea a Jiřího Bourka...
Veškeré "opravy" Spectre/Meltdown chyb jsou "workaroundy" (viz změny v kernelu). Řešení, které není workaround je pouze správně fungující CPU. A již poněkolikáté v této diskuzi - argumentovat tím, že se může v budoucnu objevit další chyba (možnost jak v JS získat přesný časovač) je nesmysl, toto se dá říct o jakémkoliv SW a pokuď by si tomu chtěl zabránit, můžeš tak akorát zamknout (vypnutej) počítač do trezoru...
Co se týče té možnosti kaskádování chyb tak samozřejmě pro spoustu nasazení to může být dostatečné ospravedlnění snížení výkonu. Pro spoustu nasazení to ale nepředstavuje takové riziko, aby se vyplatilo kvůli tomu o ten výkon přijít. To je ale na rozhodnutí každého jednotlivého uživatele. Ty ze své pozice, bez znalosti toho nasazení, o tom ale těžko můžeš kvalifikovaně rozhodovat. A už vůbec ne stylem: "nesnaž se to ani obhajovat".
Nechávat si v PC lokální root exploit je prostě úlet. Říkej si co chceš, ale je to hovadina jak zvon. A ničím to neospravedlníš. A pokud jde o web prohlížeče, tak chyby ohledně vzdáleného spuštění kódu (připomínám, že se nebavíme o js) se tu a tam jednou za čas objeví
Že rozdíl mezi rootem a uživatelem ve spoustě případů není prakticky podstatný už jsem tady ukazoval, ale pro pořádek to zopakuji. Pokud jsou jediná důležitá data dostupná v tom uživatelském účtu, kde je i výrazně větší exponovanost pro vzdálené útoky například právě skrze prohlížeč, není riziko root exploitu prostě nikterak zásadní záležitost. Já si třeba zase neospravedlním na svém desktopu pro své použití výrazné snížení výkonu za cenu zvýšeného rizika root exploitu. Třeba proto, že běžně mi tady běží jediný proces pod jiným uživatelem než mým uživatelským účtem nebo rootem.
Takže soráč, ale kecy o tom, jak neuznáváš, že se v budoucnu může objevit nějaká chyba, je v tomto kontextu úplně mimo, protože se objevují celkem pravidelně.
Nikdo samozřejmě netvrdí, že se v budoucnu nemůže objevit/neobjeví nějaká bezpečnostní chyba. Ale to je předpokládám jenom součást tvého "expertního trollingu".
"Expertem" tě tady lidé nazývají proto, že nejenom nejsi schopný, ale ani vůbec ochotný provést tak základní věc jako je zhodnocení hrozby a její porovnání s dopady případných preventivních opatření.
Trollíš proto, že tvrzení, které říká, že tu vždy budou nějaké bezpečnostní chyby zcela otočíš a snažíš se oponentům podsunout, že tvrdí: "neuznáváš, že se v budoucnu může objevit nějaká chyba".
Nechávat si v PC lokální root exploit je prostě úlet.A co třeba root přihlášený v grafickém emulátoru terminálu, který běží pod obyčejným uživatelem? Nebo tohle pro práci pod rootem nepoužíváš?
Já vim, že ten keylogger máte jako univerzální výmluvu, abyste nemusel nic dělat,Univerzální? Od začátku je to jen příklad, který má ilustrovat vztah mezi mírou rizika a cenou za jeho eliminaci. Vtip je v tom, že obvykle je tou cenou jen installace patche. Což je prakticky zanedbatelná cena. V tomhle případě je ale ta cena mnohem vyšší. Jen pro jistotu doplňuju, že pořád uvažuju v kontextu jendouživatelského deskotpu. A mimochodem, když se ti nelíbí příklad s keyloggerem, co tohle?
TL;DR: Všude přidat do příkazové řádky kernelu tsx=on
a dál už nad takovou ptákovinou nepřemýšlet. Sorry jako, máme rok 2019 a transakční paměť má prostě fungovat.
Tohle je ale fakt styl "já bych všechny ty počítače a internety zakázala":
Although there are mitigations for all known security vulnerabilities, TSX has been known to be an accelerator for several previous speculation-related CVEs, and so there may be unknown security risks associated with leaving it enabled.
a ne, ani AMD tomu neušlo, jen jich bylo míň a nejspíš má pro všechny softwarové záplaty, pochopitelně snižující výkon
AMD Ryzen 3900X:
itlb_multihit:Not affected l1tf:Not affected mds:Not affected meltdown:Not affected spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization spectre_v2:Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: conditional, RSB filling tsx_async_abort:Not affected
starší AMD Athlon 5050e (tam je ještě jádro bez poslední sady patchů, takže neukazuje TAA a iTLB multihit, ale u obou by bylo "Not affected"):
l1tf:Not affected mds:Not affected meltdown:Not affected spec_store_bypass:Not affected spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization spectre_v2:Mitigation: Full generic retpoline, STIBP: disabled, RSB filling
Intel Core i7-6600U:
itlb_multihit:KVM: Mitigation: Split huge pages l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled mds:Mitigation: Clear CPU buffers; SMT disabled meltdown:Mitigation: PTI spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, RSB filling tsx_async_abort:Mitigation: Clear CPU buffers; SMT disabled
- běžících na bare metal
- dedikovaných na jednu úlohu
Tohle^^^ ale v praxi prostě nejde dohromady. Leda snad u firem s nekonečným rozpočtem na hardware i elektřinu (přepočteno na podíl informačních technologií na činnosti firmy), které sice možná někde existují, ale nikdo o nich zatím neslyšel.
Jinak zcela souhlasím, že většina těch "procesorových" hrozeb je v praxi téměř "neaplikovatelná". Systém vůbec nemusí být jednoúlohový. Stačí, aby byla přiměřená kontrola nad tím, co na systému běží (tedy aby to nebyl "cloudový" stroj, nýbrž interní stroj, který vyžaduje a je ochoten spouštět pouze kontejnery a binárky zkompilované interně a pečlivě auditované). Pak najednou většina těch útoků, které potřebují k přečtení cizích dat velmi specifické podmínky (obskurní kus kódu, velké zatížení procesoru, relativně málo souběžně fungujících procesů atd.), v podstatě přestane existovat, protože je prostě není jak provést, kromě nějakého insider threat spiknutí.
Tiskni Sdílej: