Názory k článku Postřehy z bezpečnosti: je tu říjen – měsíc kybernetické bezpečnosti

Jo, dodavatelé (a vlastně kdokoliv) průšvihy bagatelizují, o tom žádná. Na druhou stranu vidím dost i motivaci pro výzkumníky nafukovat. Kdyby to bylo od začátku objektivní tak tam asi nedohodne snížení hodnocení.

Ale i tak, když vezmu ten curl post jako příklad (a myslím že jsem viděl horší), to současné CVSS:3.1/AV:N/AC:H­/PR:N/UI:N/S:U/C:H/­I:H/A:H by pokud dobře vidím bylo stejné i pro chybu ve webové aplikaci umožňující tahat a měnit data kdykoliv (s nějakou komplikací která udělá attack complexity high, ale pořád v zásadě kdykoliv a odkudkoliv) s kolujícím veřejným exploitem.

Tohle pokud dobře vidím vyžaduje aby si oběť spouštěla curl na ne-http protokoly přes útočníkovu proxy).

Mně to riziko stejné nepřipadá, a právě k tomu by to CVSS mělo být - abych byl schopen rizika porovnávat.

Mimochodem CVSS má prostředky jak to odlišit (temporary, nebo i AV adjacent a/nebo UI required; CIA hodnotit nebudu protože jsem nekoukal na detail toho dopadu double free, ale připomínám že H je able to modify any/all files protected by the impacted component. ).

4. 10. 2023, 11:25 editováno autorem komentáře

Jenže autor cUrl má v tomto případě pravdu. Problém CVE je v tom, že ta hodnocení jsou nezávislá na realitě. Spousta CVE je zaregistrovaná jenom proto, aby se tím dotyčný mohl chlubit, že objevil CVE. Někdo objeví nějaké nesmyslné CVE, pak někdo jiný backportuje patch do předchozí verze tak, že to vůbec nic nezmění. První je happy, že si udělal čárku, že objevil CVE. Druhý je happy, že si udělal čárku, že backportoval opravu CVE. A bezpečnost někde pláče v koutě, protože se za ní vydávají nesmysly.

Realita je takova, ze zranitelnosti muzou byt a byvaji zneuzivany i s velkym casovym odstupem. A bagatelizatori Vaseho formatu tomu akorat napomahaji. Prave temi kecy stylem "to je nesmysl, to prakticky zneuzit nejde... nemusime to resit". A ze neco neni aktivne zneuzivane hned fakt neimplikuje, ze to nekdo nevystracha treba za rok ci dva. A ono historie tady pamatuje i opacne pripady, kdy naopak bylo neco bylo puvodne ve vasem boharovnem stylu podceneno a dopady byly o to fatalnejsi. Tady rozhodne plati, ze better safe than sorry...

Bezpecnost place v koute predevsim proto, ze vy - programatori - moc nepremyslite nad bezpecnosti a hlavne chrlite kod na kvantitu a nikoliv kvalitu, a obcas i obhajujete naprosto nesmyslne pseudooptimali­zace. A hlavne, cim vic commitu, tim lip... :P A kdyz je neco odladene a funguje to, tak to s chuti rozvrtate a samozrejme chvili trva, nez ten nove vyprodukovany bordel nekdo poradne zaudituje...

Realita je takova, ze zranitelnosti muzou byt a byvaji zneuzivany i s velkym casovym odstupem.
Tvrdil tu snad někdo opak? A není divné hlavně hlášení bezpečnostní chyby s velkým časovým odstupem?

Prave temi kecy stylem "to je nesmysl, to prakticky zneuzit nejde... nemusime to resit".
On tu někdo něco takového psal? Aha, nepsal, to si jen Danny vymýšlí, jak je jeho zvykem.

A bagatelizatori Vaseho formatu tomu akorat napomahaji.
Ne, nezáplatování chyb napomáhají bagatelizátoři jako vy. Pokud má každý prd závažnost 9,8, tak někdo systémy pracně zazáplatuje třikrát, pětkrát, desetkrát, a když zjistí, že devět z těch deseti případů nebylo v jeho případě vůbec zneužitelné a desátý by znamenal DoS, ale ne žádný únik dat nebo manipulaci s daty, tak se na jedenáctou 9,8 vykašle. A možná to zrovna bude ta opravdová.

Pokud má systém pro hodnocení závažnosti bezpečnostních chyb fungovat, pak musí dávat alespoň trochu relevantní informace. A ne že se tváří, že umí rozlišit 100 stupňů závažnosti, a přitom naprosto stejným stupněm závažnosti aktivně zneužívané RCE, které může provést kdokoli, a na druhé straně chybu, kterou může zneužít jen administrátor systému a nemá dopad mimo ten systém (nebo-li administrátor může toho samého výsledku docílit i bez zneužití té chyby).

A ze neco neni aktivne zneuzivane hned fakt neimplikuje, ze to nekdo nevystracha treba za rok ci dva.
Tím jste narazil na zajímavou věc, která vám bohužel nedošla – že aktuální riziko zneužití nemůže být vyjádřeno jako jedno číslo konstantní v čase. Protože k aktivně zneužívané zranitelnosti se bude přistupovat jinak, než ke zranitelnosti, u které není znám ani PoC. To první budete záplatovat hned i za cenu nějakých škod, u toho druhého můžete naplánovat řádnou odstávku tak, aby se to obešlo beze škod.

Bezpecnost place v koute predevsim proto, ze vy - programatori - moc nepremyslite nad bezpecnosti a hlavne chrlite kod na kvantitu a nikoliv kvalitu, a obcas i obhajujete naprosto nesmyslne pseudooptimalizace. A hlavne, cim vic commitu, tim lip... :P A kdyz je neco odladene a funguje to, tak to s chuti rozvrtate a samozrejme chvili trva, nez ten nove vyprodukovany bordel nekdo poradne zaudituje...
Když jste psal minule, jak jsou sysdmini bezchybní a chyby dělají jen programátoři, bral jsem to, že to byla dočasná ztráta soudnosti v zápalu trolení. Ale vy to evidentně myslíte vážně. Až tak vážně, že při tom vůbec nepoužíváte tu kouli, co máte an krku.

Takže zlatíčko, mám tu pro vás jednu obrovskou novinku. Víte, kdo konfiguruje parametry jádra při startu? A kdo konfiguruje spouštění systému a služeb (bývalé init skripty)? Jsou to administrátoři. To je ale překvapení, že? Takže kdo by musel udělat chybu v konfiguraci, která by znamenala, že se do jádra natáhne nějaký nepodepsaný modul? Ano, tu chybu by musel udělat neomylný admin.

Dal jsem vám několikrát šanci ukázat, že umíte diskutovat rozumně. Ale vy vždycky nakonec skončíte u trolení, kdy už vám je úplně jedno, že plácáte jeden nesmysl za druhým a při snaze okopávat ostatní kopete akorát sám sebe. Takže je čas udělat pá pá.

Aha, tak vy svuj cely konstrukt stavite na tom, zda je ci neni volne ke stazeni PoC a podle toho hodnotite miru rizika. Takze zlaticko, k tomu aby neco zneuzito se PoC fakt publikovat nemusi a ze se nevali PoC na Githubu fakt neimplikuje, ze neexistuje. Panove s cernymi klobouky tyto veci totiz narozdil od panu s klobouky bilymi moc nepublikuji, ze? :-) A blabol s tim vykaslanim se na jedenactou 9,8... zuby si taky prestanete cistit a prestanete navstevovat zubare jen proto, ze u deseti navstev vam v hube zadny kaz nenasli? Ne, zlaticko... i u IT systemu je treba se venovat nejake hygiene - a argument "nakonec se nic nedelo" neni validni ani relevantni. A kdo to delat nechce by si mel najit jinou praci.

Na odkazanem priklade je demonstrovano, kdy programatori vnasi nove riziko a novy mozny vektor utoku, kdy navic neexistuje druha cast. A to jak se to ve vychozim stavu bude chovat opet nebude o administratorovi, ale o vyvojari jine casti systemu/distribuce. Administratori totiz ty distribuce bezne nevyrabi, vime? :-) A na spoustu use-case se vychozi parametry ani menit nemusi. A takovy ten vyvojarsky ping-pong, kdy se kazdy tvari, ze chyba je u druheho taky zname. Zjevne v tomto sam excelujete ;-) Mimoto ty parametry nemusi modifikovat jen asministrator, to obcas zvladne i nejaky ten malware, ze? Tak a ted si predstavte, ze nekdo zneuzije cerstvou diru v libc k tomu, aby ten parametr zmenil tak, aby si natahnul s pristim startem kernelovy modul, o kterem nebudete vybecvedet... pac nez nastoupi ty vase "userspace" kontroly kvuli usetrenym par milisekundam pri bootu, tak se ten modul proste skryje tak, ze ho jednoduse nedetekujete, prostor tam na to bude. A ted mudruj, ty milej zlatej chytrej programatore ;-) To je proste krasna demonstrace toho, kdy programator do zabezpeceni bootovaciho procesu nove vklada hodne slaby clanek retezu... no spis dve oka silneho retezu spojuje zkroucenym dratkem k sobe a tvari se, ze to prece pohromade drzet nejak bude.

"Realita je takova"

Realita je takova, ze kdyz mam klic od dveri, muzu ty dvere odemknout a nejaky tu0pec na to zcela jiste napise CVE, ze klicem se daji odemknout dvere.

K nalezeni je hromada CVE na tema ze root muze XYZ ... pricemz pokud ma nekdo roota je to uplne jedno.

Doslo to dokonce tak daleko, ze jsou z repo (gentoo) vyhazovany zcela funkcni balicky ... aby byly nahrazeny milionkrat vetsim molochem, s milionkrat vetsim poctem chyb jen proto, ze ta zcela funkcni vec ma nejake hypoteticke CVE ktere ani teoreticky nemuze nastat.

Ale toho "roota" muze mit defacto i bezny uzivatel, staci kdyz jim poustena ma binarka vlastnena rootem nastaveny suid bit, ze? :-) Ty CVE mimo to nejsou o tom, ze "root muze", ale casto staci nejake specialni opravneni - co muze mit i bezny uzivatel, kdy sice nemate primo roota, ale mate povolenou prislusnou konkretni capability - zjevne jste si to vy zjednodusil na toho roota, protoze asi tyhle nizkourovnove detaily k zabezpeceni moc neresite.

A ze se z distribuci vyhazuje software, ktery nikdo dlouhodobe neudrzuje? :-) No to je prekvapeni... ale porad to je opensource, nic vam prece nebrani se jeho udrzby chopit, kdyz po nem tak touzite a nemuzete bez nej zit. Software, co v upstreamu udrzovany je vam z distra nikdo nevyhodi.

Četl jste ten odkazovaný článek?

V čem je závažnost té chyby a k čemu je systém, který takové chybě přiřadí stejné skóre jako diskutované chybě v eximu?