Názory k článku Útoky na software zevnitř a elektřina v autě i doma, OpenAlt 2025
-
Taky mě to zajímalo. Našel jsem po doporučení Dmitriho: https://2025.openssl-conference.org/speaker-sessions/detail-108_1292833#sectionLink
Bohužel záznam jsem nenašel.
-
SinuhetStříbrný podporovatel
A co je pravda?
A ma to vliv na smysl toho tvrzeni?11. 11. 2025, 22:48 editováno autorem komentáře
-
DannyStříbrný podporovatelAle ono to stejne funguje i v OSS. Minimalne v castecne forme... kdy v ramci "embarga" se ta informace o zranitelnosti dostane jek nekomu. To embargo samo o sobe je z pohledu velikosti casoveho okna dosti flexibilni. A samozrejme jako koncovy uzivaetel nikdy nemam jistotu v tom smeru, ze nekdo s dostupem informace v ramci embarga ji... ehm... nezneuzije. Porad se bavime o dvousecnych zbranich - aneb ano, responsible vulnerability reporting dava smysl... ale ma to i sve mouchy. A i kdyz tohle vsechno prekousnu, porad ten fix muze vic problemu zpusobit nez vyresit....
V tomhle smeru kazdopadne nedava smysl hejteni "specialnich verzi" specificky k Windows smysl uplne nedava. Je to vec k hodne velke diskuzi - aneb ano, na jedne strane dava smysl diry tutlat do chvile, nez si je upstream fixne - ale to taky muze trvat dlouho, a samozrejme v momente kdy to neni uplne public neni az takovy tlak na rychlou opravu... a nebo rovnou publikovat, ze tam ta dira je.. a pak i ten tlak na vendora bude jiny - ale samozrejme s rizikem, ze ta informace o dire bude jinde zneuzita driv, nez se to staci opravit.
-
> Je to vec k hodne velke diskuzi - aneb ano, na jedne strane dava smysl diry tutlat do chvile, nez si je upstream fixne
ved presne toto spominal aj ten chlapik na prednaske o vvyoji opern source, ze oni realne nemozu byt az tak open, prave kvoli dieram, bugom alebo pripravu na novinky od roznych zakaznikov.
-
Přišel na to při testování výkonu. Díky tomu, že to bylo open source, mohl on a další hned studovat, proč je to pomalejší, a na ten útok přijít. Jak myslíte, že by to dopadlo, kdyby to byla uzavřená knihovna? Nahlásil by to jako malou výkonnostní regresi, vývojáři by si vyhodnotili jako nezásadní pro produkt a trčelo by to někde na dně backlogu.
-
Ano, zranitelnost nebyla v kódu samotné knihovny, ale zdrojový kód se hodí i v tomto případě alespoň k vyloučení toho, že problém není tam. A byla to transparentnost toho projektu celkově (zdrojáky, historie commitů...), díky které se ten člověk sám dobral k tomu, že to není obyčejná výkonnostní regrese, ale bezpečnostní problém. Kdyby k tomu přístup neměl, tak to nahlásí maximálně jako drobnou výkonnostní regresi a kdoví, kdy by se vůbec přišlo na to, že je to bezpečnostní problém.
-
Ano amatersky utok pre to, ze napadli len jednu kniznnicu.
Ja si sofisitikovany utok predstavujem skor inac - nenapadne zanasanie zranitelnosti primo do kodu. Alebo spravim to, ze v dvoch roznych knizniciach spravim zmeny tak, ze spolu vytvoria bezpenostny problem. Ma to aj tu vyhodu, ze to utocnik moze popriet, prejde to cez review na prvy pohlad je vsetko OK, aj na druhy. A stale to bude lacnejsie ako hladat zero-day zranitelnosti.
-
Nějaká plausible deniality, jako třeba v tomhle případě https://www.root.cz/zpravicky/amd-zen5-ma-problem-s-rdseed/ nebo třeba i známý https://owasp.org/www-community/vulnerabilities/Heartbleed_Bug
-
Ondřej KolínZlatý podporovatel
QT je takovej hybrid, na nektery veci pouziva nativni veci.
https://forum.qt.io/topic/141103/why-not-use-native-widgets/2
