Názory k článku
Dirty Frag je další chyba podobná Copy Fail, zatím pro ni neexistuje oprava

Vyzkoušeno na Rockym 8 a funguje. Děsivé. ;-)

Zajímalo by mne, jak se tyto chyby mají k Mythosu. Zda je Mythos také odhalil a jenom je někdo jiný odhalil nezávisle dřív, než se stihly nálezy Mythosu opravit. Nebo zda je Mythos neodhalil a pořád zde máme významnou skupinu bezpečnostních chyb, na které je samotná AI krátká. A nebo jestli dokonce odhalení těchto chyb není výsledkem použití Mythosu ve špatných rukou.

Mythos je hlavně velký marketingový mýtus. Podobného úspěchu při odhalování chyb a vytváření úspěšných exploitů na ně lze s vhodným promptováním dosáhnout i s volně dostupnými modely jako Opus 4.6.

Vy znáte výsledky Mythosu?

Ve velké většině případů použití AI nepřináší nic, čeho by nebylo možné dosáhnout i bez AI. Akorát je to s AI podstatně rychlejší.

pri hladani bugov prakticky o nic viac nejde. Takze sa to nijak nevylucuje.

Znám to, co dal Anthropic ven. V počtu odhalených potenciálně zranitelných chyb tam i podle A není oproti veřejným modelům výrazný nárůst. Obrovský nárůst tam je podle A v úspěšnosti na ně napsat funkční exploity. No a různé bezpečnostní firmy dokázaly, že s vhodným promptováním dokážou podobné úspěšnosti ve vytváření funkčních exploitů dosáhnout i s těmi volně dostupnými modely. Myslím, že i nějaká pražská si na tom udělala jméno.

Já myslím, že je brzy soudit. Zatím toho je venku málo. Ale mně upřímně je relativně jedno, jestli výsledky jsou s jedním modelem nebo s druhým.

8. 5. 2026, 10:02 editováno autorem komentáře

Já mám pocit, že exploitovali jen malou sadu chyb, a po odstranění dvou, které se Mythosu dařilo exploitovat, šla úspěšnost dramaticky dolů. Pořad zajímavé, ale ne taková bomba. Ale možná kecám, už si z toho paperu pamatuju prakticky jen to, že místo ohromujících faktů to byla jen hromada řečí o ničem.

> Myslím, že i nějaká pražská si na tom udělala jméno.

Se podívej, co tam ta pražská firma zastrčila. Vybrali přesně tu zranitelnou funkci, ještě ji zkrátili ("/* ... */"), ručně tam napsali spoustu kontextu a velmi sugestivně se zeptali na "SEQ_LT/SEQ_GT macros with sequence number wraparound".

To není testování, zda to objeví chyby, to je testování, zda to rozumí hotovému writeupu o chybě.

Nebo ještě jinak: tak, jak je to tady napromptované, tu chybu dokážu odhalit i já. Dokázal bych před měsícem najít chybu, kdyby na mě někdo hodil celou OpenBSD codebase a řekl mi "snaž se"? Samozřejmě ne.

Škáluje to? Samozřejmě ne, je tam absurdní množství ručně vytvořeného kontextu a hintů se znalostí té chyby.

A pal tu take mame whitepaper z norské university kde dokázali vidomou úspěšnost i s haiku, gpt5-mini, qwen3 https://arxiv.org/pdf/2604.25846

Lepší verze AI se od horších liší i tím, že nepotřebují tak důkladné zadání aby doručily stejný (nebo i lepší) výsledek. AI které musím napovídat správnými prompty je podstatně méně užitečná než AI které stačí jen obecné zadání. Z vlastní zkušenosti jsem mockrát vidět Claude Opus najít komplikovanou chybu v kódu na jediný obecný prompt (Do you see any potential problems in this code?) a následně když jsem se pokoušel dostat k tomu samému závěru pomocí jiných modelů (Sonnet, GPT) tak se mi to podařilo jen když jsem je musel navádět dalšími prompty.

Ano, je pravda, že okolo Mythosu Anthropic udělal obrovskou marketingovou kampaň, ale vzhledem k tomu, jaké zlepšování předvedli s Claude Opus, tak není rozumné předpokládat, že by Mythos nemohl přinést ještě další zlepšení. Naopak - nic nenasvědčuje tomu, že by vývoj AI stagnoval.

Ty modely se do velké míry zlepšují tím, že mezi samotným modelem a tím, co vám z něj vypadne je čím dál tlustější vrstva pomocných nástrojů a promptů. Ještě před rokem jsme se smáli tomu, jaké chyby modely dělaly třeba při generování jsonu. Dnes vám spolehlivě vrací validní json. Myslíte, že se ten samotný model tak zlepšil, že to tak spolehlivě zvládne? Ale houby. Mezi tím modelem a výstupem je smyčka, která výstupy modelu háže proti json validátoru a nepustí je ven, dokud neprojdou. Co vypadá jako trefení validního výstupu na první dobrou, je ve skutečnosti výsledkem mnoha pokusů. A tohle je IMO největším zdrojem zdokonalování modelů v poslední době, ne růst schopností samotných modelů. Tvůrci modelů to samozřejmě prodávají jinak, protože magie v samotném LLM se prodává lépe než sada relativně běžných nástrojů kolem toho.

Tipnul bych si, že Mythos je jen Opus 4.6/4.7 obalený nástroji a prompty vyladěnými na hledání chyb. A jak se ukazuje, tohle umí nad Opusem s podobnou úspěšností udělat i jiné firmy, nejen Anthropic.

Ale to je přeci úplně jedno jakým způsobem se AI zlepšuje. Podstatné je že se zlepšuje, a pokud to má za následek že dokáže i podstatně lépe hledat chyby v kódu (a tedy včetně bezpečnostních chyb), tak je to že Anthropic váhá se zpřístupněním svého nejlepšího AI naprosto v pořádku. Jiné firmy zatím neprokázaly že by uměly něco podobného (a už vůbec ne že by takové AI dávaly veřejně k dispozici) - dokáži nálezy Mythosu reprodukovat maximálně zaměřením se na kód se známými chybami (což znamená velmi významné zmenšení kontextu) pomocí promptů kterými AI napovídají, což je úplně jiná disciplína než hledání neznámých chyb obecnými prompty v obrovských objemech zdrojových kódů.

Neni to pravda, videl jsem vysledky obou a vystup z Mythosu je radove jinde - hlavne dokaze najit bug, zjistit jak se da zneuzit a vyrobit exploit (zretezit vice bezpecnostnich chyb).

Opus 4.6 najde jednotlivy bug (hadam z 50% z toho co najde Mythos) ale uz jej nedokaze rozpracovat do zneuzitelne podoby. Proste jen rekne "tohle je problem".

Ale tady nejde o srovnání Mythos vs standardní Opus 4.6, ale Mythos vs Opus 4.6 se specializovaným promptingem a toolingem pro vyhledávání bezpečnostních chyb od jiných subjektů.

V oss-security je zpráva o tom, že toto zveřejnění bylo způsobeno tím, že si lidé všimli, že do kernelu byla commitnuta oprava, a bezpečnostní chybu, kterou opravuje, tak našli.

(jestli je zrovna toto chyba, kterou poprvé našel Mythos, to nevím)

8. 5. 2026, 22:45 editováno autorem komentáře

Aspoň, že to červený klobouk tentokrát nehodil do kernelu.
Já jenom doufám, že nic z tohohle neprojde na androidu, nebo si ten průšvih nedovedu představit.

Aspoň, že to červený klobouk tentokrát nehodil do kernelu.

Omlouvám se, co myslíte tím hozením do kernelu, když je to zranitelnost kernelových modulů?

Já jenom doufám, že nic z tohohle neprojde na androidu, nebo si ten průšvih nedovedu představit.

Android ty moduly sice evidentně má.. viz CONFIG_INET_ESP, CONFIG_INET6_ESP, CONFIG_XFRM.. v
https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/arch/arm64/configs/gki_defconfig
A musí.. i kdyby nešlo o VPNky, tak IPSec se používá třeba pro VoWifi.

Ale aplikace obecně, mimo vybrané userspace komponenty ze systému, by se k tomu neměly přímo dostat. Jsou tam výchozí SELinux politiky, co tomu brání.
Tohle je sice poznámka o předchozím Copy Fail, ale bude to platit i pro podobné věci..
https://discuss.grapheneos.org/d/35110-grapheneos-is-protected-against-copy-fail-and-similar-vulnerabilities-by-selinux
a link z postu
https://android.googlesource.com/platform/system/sepolicy/+/refs/tags/android-16.0.0_r4/private/app_neverallows.te#130
Kde je vidět, co je ve výchozím stavu zakázané, včetně netlink_xfrm_socket

Zas na druhou stranu, kdyby to fungovalo.. tak lidi si tu občas stěžují, jak je složité získat v novějších telefonech s Androidem roota.. tohle by nevyžadovalo ani speciální povolení a nějakou modlitbu k Xiaomi :D

Tu mozno ani tak nejde o ziskanie root na androide, ale skor o ten debilny pristup vyrobcov kedy proste po dvoch-troch rokoch (vacsina) utnu podporu a clovek ma smolu. Dnes sme sa dostali do stavu kedy su telefony po vykonnostnej stranke good enough tak ako pc, ale podpora a aj tlak zo strany Googlu nuti zakaznika telefon po par rokoch zahodit. Nie kazdy potrebuje hned highend, niekde staci aj stredna trieda a vystacila by aj 4-5 rokov, ale vzhladom na vydavanie novych verzii androidu a postupne odpisovanie podpory pre stare appky je to problem.

Já to chápu a dělal jsem si trochu legraci.. ;)
Ať už proti přirozenému nebo umělému morálnímu zastarávání telefonů, software a případně krátké době podpory to získání roota samozřejmě nic nezmůže.

Jak velký je tohle mezi lidmi reálný problém, nedokážu úplně posoudit. Ale pořád se mi zdá, že třeba zrovna u běhu aktuálních aplikací na starých systémech je na tom obecně Andorid výrazně líp než třeba iOS, kde systém vychází taky každý rok, ale hodně aplikací udrží kompatibilitu tak max. dvě verze zpátky. Kdežto u Androidu spousta aplikací včetně třeba těch bankovních chodí v pořád v pohodě na i Androidu 9 (SDK verze 28), což je třeba systém vydaný před osmi roky.
Jinak samozřejmě podpora telefonů a novějších systémů na nich (tzn. včetně aktualizovaných modulů pro všechen hardware tam) je další věc..
Nic, je to stejně trochu off-topic.. :)

Ten rozdiel iOS vs Android je daný práve tou dlhou podporou zo strany Apple. Ak telefón dostáva 6-7 rokov stále funkčné aktualizácie a ďalších neviem koľko rokov bezpečnostné patche, tak používatelia upgradujú pravideľne na najnovší systém. Ak máte 80% užívateľskej základne na najnovšom iOS a zvyšných dajme tomu 18% na max tri roky starom systéme, tak sa naozaj neoplatí vývojárom aplikácii investovať do barličiek a hackov, kvôli 2% užívateľov.

Na Androide je toto úplne iná situácia. My napr. vyvíjame open source SDK pre banky a bojíme sa zarezať všetko pod Android 9, no ideálne 10, pretože ta základňa je stále relevantná. Žiadny vývojár nechce stratiť 9% užívateľov. Väčšina je žial na nezaplátaných starých a prakticky, už pre užívateľa nebezpečných systémoch.

Jenže Red-Hat v distribučních kernelech neměl algif_aead jako modul, ale přímo v kernelu. Ještěže existuje initcall_blacklist, ale i tak to chce restart.

S tím andoridem. Ano, měl by to chytnout SELinux, ale tohle se stát taky nemělo. Tady nejde o to, že si rootnete telefon, ale většina lidí tam má např. bankovnictví a vedle toho pochybné hry zobrazující pochybné reklamy. A cokoli z toho by získalo root. Tohle už by nebyla jejich smůla, ale obrovský průšvih.

Jenže Red-Hat v distribučních kernelech neměl algif_aead jako modul, ale přímo v kernelu. Ještěže existuje initcall_blacklist, ale i tak to chce restart.

Aha, takhle jste to myslel.. :) Já pořád přemýšlel s těmi jinotaji a klobouky (black hat, white hat, red hat hackers).
A ano, jasně, pokud je to jako modul, tak se to snadněji blacklistuje v modprobe configu než přes parametry jádra a je to bez restartu.

S tím andoridem. Ano, měl by to chytnout SELinux, ale tohle se stát taky nemělo...

Jako jo, ale to, že se něco nemělo stát, si pravděpodobně říká vcelku mnoho lidí u každé bezpečnostní chyby ..nejvíc asi ti vývojáři, co to commitnuli nebo schválili :D

Jinak chápu, bylo by to závažné, pokud by to šlo na Androidu široce zneužívat. Zas už ten obecný hardening tam řeší poměrně dlouho a snaží se minimalizovat případné dopady těch zranitelností (které tu přes veškerou snahu občas budou) přesně těmi dalšími mechanismy jako je SELinux a izolací uživatelských aplikací.

BTW, AlmaLinux už má backportovaný patch (byť se musí tahat z testing repa). https://almalinux.org/blog/2026-05-07-dirty-frag/

Ač zprávička říká, že neexistuje oprava, tak existuje workaround, opět zablokovat loadnutí modulů.

A minule jsme se tu bavili o custom kernelu vs. distribuční all-in-one, a dostal jsem vynadáno, že je to blbost a tak.
No kdo by to po tejdnu řekl, že autoload esp4.ko, esp6.ko a rxrpc.ko povede k rootovi? A jen tak mezi řečí, na kolika procentech serverů nebo WS se IPSEC vlastně používá?

Pro úplnost jsou aktuálně 2 exploity (rxrpc, xfrm). Zablokování modulů pomocí konfiguračního souboru /etc/modprobe­.d/dirtyfrag.con­f:

install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
install xfrm_user /bin/false

Pak vyhodit z jádra moduly:

rmmod esp4 esp6 rxrpc xfrm_user

Nakonec reboot, vylití cache na již proběhlý exploit nestačí (pozor, to vylití se docela zamyslí):

echo 1 > /proc/sys/vm/drop_caches
reboot

RHEL a klony mají xfrm_user v jádře, takže je zřejmě potřeba zablokovat inicializaci přes parametr jádra a udělat reboot:

grubby --update-kernel=ALL --args="initcall_blacklist=xfrm_user_init"
reboot

IPSEC se používá pro VPN.

Ano. Tak znova. Kolik procent WS a serverů používá jakoukoli VPN? A kolik procent z nich používá poměrně těžkopádný IPSec, a ne třeba Wireguard, OpenVPN?

A o kolik by se snížila attack surface, pokud by u zbylých ty moduly nebyly vůbec, nebo by alespoň neměly autoload, ale loadoval si je spouštěcí script od toho pluto/charona?

Vzhledem k tomu, ze wireguard vetsina firewallu nema dodnes implementovano, a treba Fortinet ssl vpn zrusil, tak je ipsec pouzivan na velmi velkem mnozstvi ws/serveru/fi­rewallu atd. Nekde to je jako client-to-site, jinde jako site-to-site.

Dalo by se rict, ze ipsec je je dominantni metoda vpn.

A jsme technici, v relativních číslech, alespoň řádově, by to nebylo? Promile? Procenta? Desítky procent?

ipsec je take nativni soucasti IPV6, dokonce se pri prvotnim navruhu IPV6 uvazovalo, ze bude povinny

MP

to je ale nedostatečné, ještě tam máš zranitelnost user nemaspaces, takže user.max_user_na­mespaces = 0 a papá třeba podman. Poté tam také visí AF_RXRPC, to lze vyřešit blokováním, pak add_key("rxrpc", ...), to už je horší, protože SystemCallFil­ter=~@keyring už má nějaké regrese, ale zase jde o případ, kdy tam uživatel může spouštět kód, to už nebude tak časté.

Tu je ďalší bug:

https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo


test@bobek:~/Co­py_Fail2-Electric_Boogaloo$ bash run.sh
=== Stage 1 — overwrite 'gnats' line (90 bytes) with 'sick::0:0:<pad>­:/:/bin/bash'
=== Stage 2 — verify
mutation didn't land
test@bobek:~/Co­py_Fail2-Electric_Boogaloo$ uname -a
Linux bobek 7.0.4+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 7.0.4-1 (2026-05-07) x86_64 GNU/Linux
test@bobek:~/Co­py_Fail2-Electric_Boogaloo$

... naštěstí. Takže fix snad bude brzy

Tohle má být snad jen variace na původní chybu vzniklá v mezidobí.

Je videt, ze veci jako Gentoo a individualismus maji porad smysl.

Neni nad to, mit v kernelu a modulech jenom to co realne pouzivate.

Obe zranitelnosti jsou vysledkem bastl-kodu v random modulech... ale jasne, exemplarne potrestame ISA sitovky a hodime je pres palubu jako prvni.

Uz me chybi jen hitlerovska bunkr parodie na tohle tema :D

8. 5. 2026, 17:18 editováno autorem komentáře

Na Debianu 13 to funguje. Na Unstable mi to na 7.0.3 taky hodilo roota, ale pak mě napadlo zkusit upgrade a je kernel 7.0.4 a tam už to selže:

test@bobek:~/dir­tyfrag$ ./exp
dirtyfrag: failed (rc=4)
test@bobek:~/dir­tyfrag$

Takže v posledním upstream kernelu to už je asi fixlé.

aha, tak Debian už vydal nový kernel a je to v klidu... 6.12.86+deb13-amd64

V upstreamu je to až v 7.0.5, ale Debian to backportoval do 7.0.4:

linux (7.0.4-1) unstable; urgency=high
[ Salvatore Bonaccorso ]
* xfrm: esp: avoid in-place decrypt on shared skb frags
* rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present

IMO nejdůležitější je si konečně uvědomit, že i když je lino architektonicky o bezpečnější než wokna, samo o sobě to nikoho nespasí. A že síť a systém je potřeba stavět správně, ne to patlat jak pejsek s kočičkou dort.

Pochybuji, ze je linux architektonicky bezpecnejsi nez windows.

Ja nie. Windows kernel ma technicky ACL na kazdom objekte, ale prakticky sa k nim neda dostat a po cely zivot systemu budu nastavene tak, ako to Microsoft nastavil. Ten tiez nema vela slobody ich menit, pretoze by rozbil veci vo vyssich vrstvach.

Linux ma LSM, takze je mozne cely bezpecnostny modul vymenit. Ak sa AppArmor neosvedci a SELinux ano, tak sa bude pouzivat SELinux. Architektonicky je tam otvorena cesta k evolucii, na rozdiel od Windows.

Je, a docela o dost. I MacOS je o dost bezpečnější než Windows. Jenže ve výsledku je to skoro jedno, protože nejslabším článkem je uživatel, který klepne na první odkaz co mu přijde mailem a potvrdí elevaci práv všemu bordelu, co se ta stránka pokusí spustit. A v tom momentě jseš na tom se sebebezpečnějším systémem úplně stejně, jako Baťa s dřevákama v roce 2014 (achtung: nadsázka).

11. 5. 2026, 15:11 editováno autorem komentáře

důležité je to slovo architektonicky, z tohohle pohledu si myslím, že na tom Linux je lépe. Už jen to, že umožňuje svým návrhem výrazně redukovat velikost a funkce samotného jádra, já rozhraní, které ti umožňuje omezit či povolit konkrétní syscally pro jednotlivé aplikace, máš velmi dobrou kontrolu nad tím, co aplikace samotná dělá a jak komunikuje s kernelem.

Architektura Windows ti neumožňuje výrazně omezit samotné kernel volání, neumožňuje ti snížit zpětnou kompaitiblitu a odstranit spousty starých rozhraní a implementací, neumožňuje ti reálně redukovat kernel volání od aplikace atd.

Takže, za mě ano, linux je architektonicky lepší než Windows, viz i variabilita distribucí, kdy tady je vážná zranitelnost samotného kernelu a stejně ve výchozím stavu nebyla aplikovatelná u řady distribucí.

Teoreticky je mikrojádro Windows bezpečnější než Linux. Prakticky je problém v tom, že Microsoft i Apple jsou korporáty a na bugreporty často prdí jak na placatý kámen (v minulosti naprosto hrozně). Navíc spoustu děr prohlašují za vlastnost (viz kdysi články nějakého Russinoviche, kterého pak Microsoft radši koupil i s chlupama).

Takže je spíš reálný problém v tom, že kód Windows a MacOS, iOS je closed-source a chyb tam bude mraky, protože se spoléhá na security-by-obscurity. Jenže AI bude brzy jedno, jestli hledá zranitelnost ve zdrojáku nebo v binárce. Takže Linux je teď sice pod tlakem, ale až to dožene Wokna, tak to teprve bude sranda.