Názory k článku
Repozitář node-ip archivován kvůli nadhodnocenému CVE

Zas melete blbosti, jake nahodne vygenerovane cislo ??

CVE score ma danou metodologii urcovani (CVSS), a muzete si to klidne vyklikat pres nejaky GUI nastroj, a la: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator (a jak vidite, i ta metodologie se vyviji, kdyz tam je uz verze 3.1)

Zranitelnost tedy bude mit takove skore, jake vyplyne z jeji charakteru - a pokud chcete vyssi, tak holt musite dodat/nalezt i exploit, idealne sitovej. Tezko si muze nekdo jen tak nadhodnotit score pro svuj objev.

A ciselne hodnoceni umoznuje alespon seradit problemy, aby se dalo prioritizovat jejich reseni. Metoda vazeneho prumeru vam nic nerika, ze? A ani thresholding - nekde musi byt hranice co je povazovano za OK a co je pres caru. Jinak by to byla anarchie celkem a nic se nevyresilo. A prave proto, ze automat potrebuje nejakou metriku k rozhodovani - idealne redukovanou na jedno cislo, existuje CVSS.

Odpovednost za CVE nese autor exploitovatelneho reseni. Ma pracovat pecliveji a byt vubec rad, ze mu to nekdo pomaha vylepsovat.

Jo, metodika pro to číslo je. Ale ukažte mi ten síťový exploit pro ten freeglut co jsem linkoval nahoře.

Protože ten má vysoké skóre jen proto, že reporter tvrdí, že to je exploitovatelné po síti bez uživatelské interakce.

Takže číslo se počítá z příznaků, které dostanete v rámci toho hlášení. A teoreticky můžete tyhle příznaky přidat k libovolné knihovně. Vždycky totiž existuje způsob jak ji zakomponovat do síťové služby (ale u grafického menu si to neumím moc představit..).

To jsme ale porad u toho, ze primarni chyba je na strane toho, kdo problem reportuje. Sekundarne je chyba v tom, ze to nejde nejakym procesem snadno opravit, potazmo ze reporter nemusi moc prokazovat pravdivost svych tvrzeni. To jsou porad jen procesni/orga­nizacni veci... co cislo samo o sobe spatne neni.

To jsme ale porad u toho, ze primarni chyba je na strane toho, kdo problem reportuje.
Ano, problém je v tom, že lidé nejsou svatí…

Pokud je systém nastaven tak, že reportující se snaží mít co nejvíce co nejvyšších čísel, přičemž nenese žádnou zodpovědnost za to, pokud něco reportuje špatně, jak to asi může dopadnout?

To mate jako s poctem commitu. Tam se take casto soutezi na pocet, a treba takovy github to podporuje i vizualizaci v profilu vyvojare. Znamena to snad nizsi kvalitu produkovaneho software? :-) Nebo to vypovida o tom, jak kvalitni kod se produkuje? Ano, nas dnesny uspechany svet je hodne postaveny na podobnem "soutezeni".

Samozrejme, ze ruznym zpusobem jde zneuzit ledacos kolem nas. A neplati to zdaleka jen v digitalnim svete. Ale s tou odpovednosti je to sporne - pokud se ukaze, ze nejaky jedinec opakovane reportuje vylozene nesmysly, tak se to o nem drive ci pozdeji dozvite. Mozna jsme jen lini se trosku posnazit a podobnym lidem, co slabiny systemu zneuzivaji ve svuj osobni prospech proste sebrat moznost takove reporty generovat - stejne, jako se problemovym vyvojarum klidne znemozni prispivani do nejakeho projektu...

Ten problem proste ma reseni - zacina to uz u toho mit koule na ty jedince, co reportuji nesmysly verejne ukazovat prstem.

Nevšiml jsem si, že by se počtem commitů někdo chlubil v CV. Ale hlavně – za tím, kdo ty commity posílá, je ještě nějaký správce projektu, který by autora poslal někam, pokud by mu posílal příspěvky rozdělené na commity nesmyslně, jen kvůli počtu.

Jenže za tím, kdo hlásí CVE, už prakticky nikdo není. I když dotyčný nakonec to CVE odvolá, spousta nástrojů to vůbec nezohledňuje. Prostě publikovat CVE je možné bez jakékoli odpovědnosti, ale na druhé straně se CVE používá k rozhodnutím, která mají dost vážné dopady.

pokud se ukaze, ze nejaky jedinec opakovane reportuje vylozene nesmysly, tak se to o nem drive ci pozdeji dozvite
Můžete jmenovat někoho, o kom jste se takhle dozvěděl? A jak se to zohledňuje v CVE, které vydává – mají nižší skóre? Nebo auditovací nástroje CVE od takového člověka ignorují? Nic z toho neplatí, že? Prostě tam není žádná odpovědnost – na jedné straně si může o CVE zažádat kdokoli, kdo jde zrovna kolem, skóre to dostane tak vysoké, jak tam nakliká. Pak to probublá procesem, který tomu dodá zdání důležitosti, a na konci se kvůli tomu musí dělat odstávka nějakého důležitého systému, protože to CVE vypadlo z nějakého automatizovaného auditu – a už nikdo neřeší, že kdyby v daném systému byla ta chyba opravdu zneužitelná, aplikovaná „oprava“ nic nevyřeší.

Ten problem proste ma reseni - zacina to uz u toho mit koule na ty jedince, co reportuji nesmysly verejne ukazovat prstem.
Vždyť jenom tady na Rootu je to několikátá zprávička o tom, jak bylo někde vytvořeno úplně nesmyslně skórované CVE. Takže v praxi se to děje ještě mnohem častěji. Nadávají na to vývojáři a správci projektů, nadávají na to správci distribučních balíčků – ale nezdá se, že by se něco změnilo. Naopak pořád lidé jako RDa výše tvrdí, že podle toho čísla řadí, co má větší prioritu a čemu už ení potřeba se věnovat.

Mimochodem, on to ani nemusí být od někoho záměr reportovat to špatně. Ono to může být jednoduše tak, že poctivě zakliká to, na co se ho kalkulátor SCSS zeptá. Je to exploitovatelné po síti? No můžete zaručit, že tu knihovnu nepoužije někdo v aplikaci komunikující po síti pro data přicházející ze sítě? No nemůžete. Takže je to exploitovatelné po síti – každá knihovna prakticky automaticky. A tak dále. Že jediná síťová komunikace je zjišťování, zda není dostupná nová verze aplikace? Že kdyby vám autor té aplikace chtěl podstrčit škodlivý kód, šoupne ho do další verze té aplikace a nebude to dělat složitě exploitováním přes číslo verze? Nezájem, skóre 9,8, další.

TL;DR... preskocil jste to podstatne - zabyvat se tim dohledanim jedince, co score v konkretnim pripade nadhodnoti. Chapu, je to moc prace. A holt se tu projevuje typicka vlastnost - tedy lenost. Kverulovat, ze CVSS je spatne je vyrazne jednodussi. A pritom ani nepredkladate lepsi reseni - navzdory delce textu.

Přeskočil jste to vy.

Ja CVSS nehejtim, ja s jeho nedostatky umim zit.

A mimoto reseni vyse napsane mate...
Ukazat si prstem na ty, co reportuji nesmysly :-)

A az se s necim takovym setkam a bude me to palit, ja si servitky brat nebudu.

1. 7. 2024, 21:59 editováno autorem komentáře

Když nepatříte mezi lidi, kteří jsou tím postiženi, není tak těžké s těmi nedostatky žít.

Výše máte napsané, proč to vaše „řešení“ není řešením.

Nikoliv, to je jen dalsi ze serie vami oblibnych vymluv, proc to udajne nejde. Samozrejme ze to jde, jenom se nechce. Zadny formular za blbost v interface mezi zidli a klavesnici nemuze. A lepsi schema jste nepredlozil.

preskocil jste to podstatne - zabyvat se tim dohledanim jedince, co score v konkretnim pripade nadhodnoti. Chapu, je to moc prace. A holt se tu projevuje typicka vlastnost - tedy lenost. Kverulovat, ze CVSS je spatne je vyrazne jednodussi.

A jak konkrétně můžeme přesvědčit zákazníka, aby se zabýval tím, jestli to skóre není nadhodnocené? Zákazníkovi jeho automatizovaný nástroj vyhodí, že je tam "závažná bezpečnostní chyba" a zákazník začne ječet, že se to musí opravit. Můžete mu stokrát vysvětlovat, že ta chyba vůbec není závažná (a nezřídka ani bezpečnostní, občas ani chyba), ale pro něj to je posvátné číslo od Autority a trvá na tom, že to tak prostě je a basta.

Základní problém je v tom, že nareportovat CVE může v podstatě kdokoli, vyplnit si tam může co chce a "závažná bezpečnostní chyba" je na světě. Naopak, zpochybnit skóre nebo samotnou podstatu té "bezpečnostní chyby" je náročné, na dlouhé lokte a většinou je nakonec jednodušší backportovat i úplně zbytečné opravy, než to martyrium podstupovat pořád dokola. Vzhledem k nezadržitelně rostoucímu počtu bagatelních CVE se ten problém stále prohlubuje. Čehož pak příslušné instituce zneužívají a poukazují na to, jak systém krásně funguje, protože zpochybněných CVE je vlastně strašně málo.

Kvalitě software to nepomáhá vůbec, naopak, protože čím dál větší část času vývojářů je spotřebovávána na backportování zbytečných "oprav" a administrativu s tím spojenou místo toho, aby mohli dělat něco užitečného.

Tak ono ty automaticke nastroje vraci i spoustu jinych nesmyslu, zvlast ty co pracuji jen s hlavickami/bannery sluzeb a nejsou oprene o agenta, co bezi primo na testovanem systemu. Pokud to zakaznik neni schopen spravne interpretovat, nemel by se takovym materialem ohanet. Ja vim, ze to obcas delaji...

Ten problem se prohlubuje ale i proto, ze se v IT nektere veci proste odjakziva flakaji. Jde souhlasit, ze backportovani oprav je zbytecne - ale nektere problemy vyvojari vytvari defacto sami svym pristupem k tomu vyvoji - kdy se s kadenci palby z kulometu meni veci zpusobem, ze starsi aplikaci s novejsi knihovnou uz nezprovoznite. Nebylo by lepsi delat veci tak, aby jsme se slozitemu backportovani co mozna nejvic mohli vyhnout? Tedy pristupovat k vyvoji zodpovedneji a ne se pri vydani nove verze tvarit, ze nekompabilita je problem na druhe strane?

Chybu proste nejde hledat jen v samotnem CVSS. Vyvoj software sam o sobe casto opomiji jednu zakladni vec - a to je dlouhodoba udrzitelnost.

Má to vlastnosti náhodně vygenerované čísla. Že je na to generování náhodného čísla metodologie na tom nic nemění – na generování UUID je také metodologie.

A ciselne hodnoceni umoznuje alespon seradit problemy, aby se dalo prioritizovat jejich reseni.
Ale to je právě špatně! Protože to číslo má jen velmi volnou souvislost s tím, jak je ta která chyba vážná. Asi se nestane, že RCE s exploitem bude mít skóre 1,2, ale to, že skóre 9,8 získávají věci, které je v drtivé většině případů nemožné zneužít, je skoro na denním pořádku.

Právě proto, že se někdo pokouší podle toho něco řadit, říkám, že je to náhodné číslo. Protože tak by se k tomu mělo přistupovat. Dokud podle toho někdo bude něco řadit a zároveň se výrazně nezmění způsob, jakým se to skóre určuje, je potřeba to opakovat, že je to náhodné číslo.

nekde musi byt hranice co je povazovano za OK a co je pres caru
Tak tu hranici stanovte. Jsem zvědav, jak to uděláte – když jsou případy se skórem 9,8, které není potřeba vůbec řešit, a vedle toho máte třeba skóre 7,5, které řešit musíte. To ta čára bude dost klikatá.

A prave proto, ze automat potrebuje nejakou metriku k rozhodovani - idealne redukovanou na jedno cislo, existuje CVSS.
A právě proto říkám, že to skóre nemá lepší vypovídací hodnotu, než náhodné číslo. Ano, mít jedno číslo, které by vypovídalo o závažnosti chyby, by bylo hezké. Aby se podle něj mohly rozhodovat automaty. Nebo „bezpečáci“. Ale takové číslo dneska nemáme, CVSS je v tomto směru prakticky nepoužitelné.

Mimochodem, až nějaké takové použitelné skóre do budoucna vznikne, rozhodně to nebude jediné číslo, ale minimálně dvě čísla – jedno bude reprezentovat závažnost chyby, druhé pravděpodobnost jejího zneužití. Protože je rozdíl, jestli aplikace vezme vstup od vzdáleného uživatele a spustí ho jako strojový kód, nebo jestli je knihovna, která obvykle nezpracovává vstup ze sítě, která volá jinou knihovnu, která také obvykle nezpracovává vstup ze sítě, ta volá třetí knihovnu, která také nezpracovává vstup ze sítě – a tady v té třetí knihovně je chyba, která umožní spustit vstup jako kód. Dneska takovéhle dvě chyby dostanou úplně stejné skóre, protože přece u těch knihoven nelze zcela vyloučit, že je nějaký program využívá tak, že se mu podaří skrze ty tři knihovny propasírovat vstup od uživatele až k té třetí zranitelné knihovně.

a jak vidite, i ta metodologie se vyviji, kdyz tam je uz verze 3.1
Ve skutečnosti už existuje verze 4.0.

Metoda vazeneho prumeru vam nic nerika, ze?
A vám zase nic neříká garbage in, garbage out, že?

Odpovednost za CVE nese autor exploitovatelneho reseni. Ma pracovat pecliveji a byt vubec rad, ze mu to nekdo pomaha vylepsovat.
Ne, autoři fakt nejsou rádi za falešná hlášení chyb. Ničemu nepomáhají, akorát odvádí autory od skutečného vylepšování.

CVSS je tu s nami temer 20 let, ale pan popirac holokaustu na bude vykladat co to je za nesmysl a nahodny cislo - tak jisteeee :D

Vy schválně nečtete ty argumenty? To číslo je "polonáhodné", protože se počítá z nevalidovaných vstupů.

- Počet CVE za posledních 20 let narostl dvacetinásobně (odhadem od oka z grafu).
- Legislativa taky. Common criteria před dvaceti lety nevyžadovalo nulový aktivní počet CVE (bez ohledu na severity), aby certifikovalo release.
- Zákazníci vázaní zákony o bezpečnosti IT tu certifikaci musí vyžadovat.

Všimněte si, že kombinací těch podmínek dostanete stav, kdy na závažnosti naprosto nezáleží. Prostě nesmí existovat známá chyba.

Tak kdyz nam za poslednich 20 let vyrazne narostl objem software, co nas obklopuje, logicky narostl i pocet chyb v nem. A nektere zpusoby vyvoje tomu taky nepridavaji - viz ruzne agilni metody, co ve finale produkuji software spichnuty horkou jehlou a ve finale nekdy i fakticky deravy (s tim, ze zabezpeceni se casem dodela). Ted aktualne portal stavebnika, kdy v ostre verzi ani poradne neosetrili pristupova prava a urady tam vidi i co nemaji... aka muzou rusit a upravovat podani, do kterych by hrabat vubec nemeli. V minulosti stejnym zpusobem vzniknul i slavny alternativni eshop k dalnicnim znamkam. Za podobne veci CVSS fakt nemuze, priciny jsou i jinde - v metodach, jak se dnes veci delaji. Bezpecnost musi byt integralni soucasti navrhu aplikace a pocitat se s ni musi od prvopocatku... a ne ze se to "pak nekdy" dodela.

V minulosti stejnym zpusobem vzniknul i slavny alternativni eshop k dalnicnim znamkam.

Hele, Danny, tohle se přece vždycky vyřeší jedním odstavcem:

„Moc všechny prosím o fér hodnocení situace. Bavíme se tu o lidech, kteří dvě noci nespali, aby ukázali, že jim záleží na používání našich společných peněz. Ti samí lidé do tří ráno jeden druhého budili, aby kontrolovali, že data jsou již v bezpečí,“

Vidíš ne? Vyřešeno, všechno je v pořádku, nikdo nebyl vyhozen (z těch manažerů) takže o dva roky později se stejnou metodou může dělat třeba systém přihlášek na střední školy...

ne ze se to "pak nekdy" dodela

Jenže tohle je metodika vývoje těch aplikací. Musí se "to" stihnout do nějakého termínu. Teprve potom, co je znám termín, se zjišťuje to "to". Až se to zjistí, tak týden před termínem přijde požadavek, který to celé překopá. A potom v pondělí to spadne, protože se tam přihlásí 5% lidí. A přijde Filip, který nám všem vysvětlí, že je to vlastně naše chyba, že to "to" vlastně určitě vůbec nepotřebujeme v pondělí.

No ono by někdy stačilo mít alespoň zadání. Ale o tom jsme se tady s Filipem hádali před x měsíci.

CVSS je tu s nami temer 20 let, ale pan popirac holokaustu na bude vykladat co to je za nesmysl a nahodny cislo - tak jisteeee :D

Třeba e-mail tu s námi (nebo našimi předchůdci) byl docela dlouho (možná i víc než 20 let), než se začaly masivně zneužívat slabiny jeho návrhu. A nevěřil byste, jak dlouho se spokojeně používat třeba takový telnet, aniž by bylo potřeba řešit skutečnost, že komunikace není ani trochu zabezpečená.

Je to vlastně takový tragikomický paradox, že systém zabývající se bezpečnostními chybami byl navržen bez jakéhokoli snahy o obranu proti triviálními DoS (DDoS) útoku.

Ne, to neni nahodne cislo, pokud se bavime o CVSS.

Ono jinak historie pamatuje i opacne pripady - kdy se riziko bagatelizovalo a realny dopad chyby byl nakonec vetsi.

To je proste o lidech. A doba je holt uz takova, ze pro kdejakou ptakovinu se i vymysli specialni pojmenovani s vlastnim webikem.

Jste-li otrokem té doby, pak dozajista můžete tvrdit, že doba už je taková.

Ale historie pamatuje i opacne pripady - zvlast u uzavrenych reseni se casto setkavame s tim, ze tvurce chyby v lepsim pripade jen bagatelizuje, v horsim zamlcuje zcela. On ten nezavisly bic na vyvojare je proste potreba take. Jak uz pisu vise, nutnost doplnit nejake opravne mechanismy do hodnoceni by od veci urcite nebylo - ale presumce neviny je extrem z druhe strany. To si troufnu tvrdit, ze vam na to vyvojari budou plosne kaslat... protoze opravovat bugy v existujicim kodu je vetsi nuda nez vymyslet nove ptakoviny.

CVSS se samozrejme vyviji, coz je patrne i na jeho verzich - coz je na strankach FIRSTu (ktrery za tim stoji) samozrejme videt. Tvrzeni, ze jim stav vyhovuje a nic s nim delate nemini je take prinejmensim lzive. Navic je to vcelku otevrena organizace, to neni zadny ku-klux-klan, najdete tam i par subjektu z CR. CVSS je proste vysledek nejakeho konsensu vcelku siroke komunity.

Zalezi jak moc "masivni" utok to bude a jak presne je nastavene logovani. Ad fsync() - treba dnes vychozi rsyslog to defaultne nedela s kazdym zapisem a distribucni default v Debianu ho pro auth.log (kam se to loguje) nema zapnuty ani explicitne k souboru (neni pomlcka pred filename). Stejne tak bufferuje zapis i journald. A samozrejme taky bude rozdil mezi tim, jestli se bude ten log sypat na rotacni disk ci na ssd/nvme...