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