Názory k článku
V balíčku xz-utils se objevil backdoor

Postižen je Debian Testing a Unstable a Fedora Rawhide a 40.

Zajímavé je, že backdoor kontroluje, že probíhá sestavení DEB/RPM balíčku, a pokud ne (lokální build, případně jiné distribuce), tak infekci neprovede.

Při startu sshd se nahraje libsystemd, tranzitivně backdoornuté liblzma, a to při nahrávání přepíše funkci RSA_public_decrypt.

Kód backdooru není dostatečně zanalyzován (je obfuskován) abychom mohli říct, jestli se neprovádí i v jiném kontextu než v sshd.

Zajímavé je jak se na to přišlo. Backdoor se aktivoval při každém forknutí sshd (jestli to chápu správně), a byl špatně naprogramovaný, takže při tom vytížil procesor. Takže při standardním nájezdu slovníkových automatů sshd hodně vytěžovalo procesor, oznamovatel začal profilovat a zjistil, že to vytížení je v knihovně liblzma v místě které vypadá podezřele.

Další problém byl, že ten způsob přepisování funkce sshd způsoboval chyby automatických testů pomocí Valgrindu a ASanu.

I rolling release distra, ale tam stačí jen nadále rollovat dopředu.

https://archlinux.org/news/the-xz-package-has-been-backdoored/

Jako ano a ne. V Archu jednak ten skript, co knihovnu infikuje, skončil, protože nedetekoval, že se buildí deb/rpm balíček, jednak nemají openssh s podporou systemd, takže se liblzma nenahrává za běhu.

Tady je porovnání těch dvou balíčků - jsou stejné. https://www.openwall.com/lists/oss-security/2024/03/29/20

29. 3. 2024, 23:55 editováno autorem komentáře

U Fedory sa to jedná o beta verziu. 40-tka má byť vydaná až o pár týždňov, konkrétne early target je 16.04.2024, a target #1 23.04.2024. I tak ale súhlasím že by sa to nemalo dostať ani do Beta, a už keď, tak určite by mali stiahnuť ISO. U Fedory sa ale beta stále distribuuje. Si pamätám ako u Ubuntu čo bol len Ukrajinský preklad, tak to hneď ISO stiahli. Čakal by som že Fedora urobí to isté.

Také tie edge distrá, tam je to jasné (a s tým sa aj počíta, pretože sú edge, práve na testovanie takýchto vecí), trebárs na Arch by som nahnevaný nebol. Ale u Fedori to vnímam dosť ako poprask, že to neriešia. Predsa len je jedna z dvoch najhlavnejších distier, a beta verzia by už takto kritické problémy nemala obsahovať.

Sice chapu ze zadne distro nema tolik lidi aby mohlo pokazde nove verzi sjet cely obsah, muzou leda tak zkontrolovat hashe ale to vyzaduje mit duveryhodneho tvurce/autora toho programu, ktery to udela tak aby to bylo overitelne. Pokud to overit nejde, distro by to melo jistit ale to se zda nestalo. Dalsi dukaz ze to ze je neco opensource neznamena ze to nekdo pred publikovanim verejnosti, nejaka duveryhodna entita hlida a ostatni ji muzou tupe verit.

[tele ceka na schvaleni roky]
Rekl bych, ze to nikdo ani netvrdi.

Pokud vim, tak zrovna skuseni stari Linuxari casto vybizeji k tomu, aby si lide programi overovali a nicemu neverili. Pamatuji si, ze kdyz vysel "snake" v Bashi, vsichni jsme to nadsene stahovali a zkouseli. Hned jsme dostali zdrbano, jestli se nekdo z nas aspon podival na na ten skript.

U opensource mate moznost si zdrojak prohlednout a osobne se v tomto pripade spis dost divim, ze si nikdo nevsiml, ze se do ofiko vyvoje dostal obfluskovany kod - ktery je vzdycky podezrely. Skoro to vypada, ze tvurci dister bud trochu usinaji na vavrinech, a nebo jim rapidne ubiva sil...

30. 3. 2024, 18:21 editováno autorem komentáře

Ono tady bylo zákeřné že ten kód byl v testovací sadě – prostě jeden z těch tarballů které to v rámci testů má rozbalit obsahoval payload, a "stačilo" už jen do testu propašovat jeho spuštění ( | bash). Hádám že tyhle balíčky dat nikdo pořádně neaudituje, jestli např. v testech ffmpeg není v jednom videu steganograficky ukrytý malware.

Ani neusínají ani neubývá. Ale komplexnost všeho obecně roste.

30. 3. 2024, 19:38 editováno autorem komentáře

Kdo pravidelné aktualizuje svůj Debian testing/unstable, tak už od 28 .3. má revertováno na verzi 5.4.5. Verze 5.6.0 přišla do Debianu 26. 2. Takže kdo ten měsíc neaktualizoval, tak má taky pořešeno ;)

to by me zajimalo jak dlouho mysleli, ze to zustane utajeno. jestli to nebyl pokusny balonek, jak je to ohlidane.

Co jsem pochopil, tak to tam již bylo déle akorát teď to aktivovali. Takže pokusný balónek prošel.

Ve zdrojácích balíčku to bylo měsíc, postupně to začaly přebírat rolling distra, kde se to naštěstí chytilo - každopádně se to chytilo náhodou / s trochou dávky štěstí

Možná by stálo za to neměnit kritické programy distribučními patchy?

Souhlas, takto by se to mělo řešit.

K čemu je upstream, když si distra aplikujou vlastní patche a výsledek je něco, co v upstreamu vůbec není.

Vetsinou pro to je nejaky objektivni duvod, proc to delat. A jak jinak byste to delal v pripade, ze chovani aplikace (nebo i kernelu) mate duvod upravit, ale v upstreamu vase patche odmitnou, protoze je "vase problemy" nezajimaji?

Možná to může znamenat, že dělám v distribuci něco špatně...

Proč vlastně Debian mění systemd?

Viz text zpravicky, to neni o modifikaci systemd - ale o modifikaci sshd, tak aby interagovalo se systemd-notify. Upstream to mergnout moc nechce. Aneb az systemd si natahne tu liblzma, ale uz nekde taky probehlo, ze ze systemd se liblzma vykosti...

To by mě zajímalo, které tajné službě se to povedlo.

jestli dnes clovek muze verit cemukoliv?! nasli chybu nebo zadni vratka v apple cpu. jde delat bezpecny sw, kdyz je hw deravy?

Ovšemže jde. Jenže ani vývojář ani uživatel není šťastný, když jejich software běží pod interpreterem Brainfucku.

Spíš nepovedlo v tomhle případě. A celkem bezpochyby se povedlo jinde. To zase ne, že ne.

Repository disabled, už se na nic nepodíváme

Moznost je tu porad :-)

Ví někdo, co ten backdoor přesně dělá? Četl jsem původní mail i další příspěvky a nikde jsem na to nenarazil. Ty věci obsahují hlavně popis, jak se přibaluje (nebo nepřibaluje), co všechno kontroluje při aktivaci, jak se věší na nějaké volání, ale jakou výhodu poskytuje útočníkovi ne.

Podle jednoho z vývojářů debianu.

,,Updating is safe but we don't know what the obfuscated backdoor code did. It might persist even after you upgrade the package itself."

https://forums.debian.net/viewtopic.php?p=795970&hilit=xz#p795970

To je jediné, co jsem zatím našel.

Ten obfuskovany kod je skoro takova "ucebnice" obfuskace, zajimave. Jsou tam veci typu:


.text.lzma_sim­ple_props_siz­d:00000000000013A0 dd 0FA1E0FF3h
.text.lzma_sim­ple_props_siz­d:00000000000013A4 ; ---------------------------------------------------------------------------
.text.lzma_sim­ple_props_siz­d:00000000000013A4 mov dword ptr [rsp-4], 474E553h
.text.lzma_sim­ple_props_siz­d:00000000000013AC mov eax, [rsp-4]
.text.lzma_sim­ple_props_siz­d:00000000000013B0 lea edx, [rdi+rsi+1]
.text.lzma_sim­ple_props_siz­d:00000000000013B4 cmp edx, eax
.text.lzma_sim­ple_props_siz­d:00000000000013B6 setz al
.text.lzma_sim­ple_props_siz­d:00000000000013B9 movzx eax, al
.text.lzma_sim­ple_props_siz­d:00000000000013BC retn

Mě právě přišlo zvláštní, že nikdo neví, co ten kód dělá, ale všichni ho označují jako "backdoor". Pro mě je backdoor něco, co poskytne útočníkovi přístup k systému - obejde obvyklé autorizace. Je možné a možná i logické, že to ten obfuskovaný kód dělá, ale pro to AFAIK nejsou přímé indicie.

Pro mě je backdoor něco, co poskytne útočníkovi přístup k systému - obejde obvyklé autorizace.
A ty muzou byt vedome ale taky nevedome vytvoreny.

AFAIK
cesky preklad je "ikdyz o tom vim spise kulovy"

Libi se mi ze se zajimas o veci vice do hloubky ikdyz to jde vzdycky vice;)

Osobně bych říkal backdoor jen těm úmyslně vytvořeným, zbytek bych klasifovalo jako (remotely exploitable) bug, ale nemyslím, že by tu byla nějaká závazná terminologie v tomto směru.

Právě proto se snažím zjistit, jestli někdo ví nějakou zásadní věc, která mi unikla, nebo jestli to tak prostě nazvali, protože je to pravděpodobné a hodí se mít nějaký jednoslovný název.

Plus-minus to vime - pri overovani klice se koukne na prijaty verejny klic. Kdyz ten klic obsahuje urcity checksum, tak jej pusti prez system().

To ma sve vyhody - neobchazi to autorizaci, takze to nikdy nevyskoci jak uspesny login.

Jj, taky jsem to už četl, mezitím to alespoň částečně rozklíčovali.

Už se začíná diskutovat o vrácení se k verzi předtím, než do xz začala přispívat Jia Tan.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024

30. 3. 2024, 09:17 editováno autorem komentáře

V Gentoo už downgradováno.

enigma ~ # eix xz-utils
[I] app-arch/xz-utils
Available versions: 5.4.2 [M]5.4.6-r1 [M]5.6.1 [M]**9999*l {doc +extra-filters nls pgo static-libs verify-sig ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32" CPU_FLAGS_ARM="crc32"}
Installed versions: 5.4.2(13:04:31 30.3.2024)(extra-filters nls -doc -pgo -static-libs -verify-sig ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="32 64 -x32")
Homepage: https://tukaani.org/xz/
Description: Utils for managing LZMA compressed files

/var/db/repos/gen­too/profiles/pac­kage.mask

# Sam James <sam@gentoo.org> (2024-03-28)
# Newer releases were signed by a potentially compromised upstream maintainer.
# There is no evidence that these releases contain malicious code, but masked
# out of an abundance of caution. See bug #928134.
>=app-arch/xz-utils-5.4.3


# Sam James <sam@gentoo.org> (2024-03-28)
# Backdoor discovered in release tarballs. DOWNGRADE NOW.
# https://www.openwall.com/lists/oss-security/2024/03/29/4
# https://bugs.gentoo.org/928134
~app-arch/xz-utils-5.5.1_alpha
~app-arch/xz-utils-5.5.2_beta
~app-arch/xz-utils-5.6.0
~app-arch/xz-utils-5.6.1


Je to jen opatrnost, v Gentoo se jednak ta útočníkova větev ./configure nespouští a jednak nemáme ten systemd patch pro SSH, na který ten útok cílí.

30. 3. 2024, 16:40 editováno autorem komentáře

Jojo, to vím, ale díky za dovysvětlení. :)

to funguje jen za předpokladu, že tohle je první pokus toho autora tam propašovat chybný kód.

Ale v Debianu už je revertováno od 28. 3. Trosku jsi zaspal:

xz-utils (5.6.1+really5.4.5-1) unstable; urgency=critical

  * Non-maintainer upload by the Security Team.
  * Revert back to the 5.4.5-0.2 version

 -- Salvatore Bonaccorso <carnil@debian.org>  Thu, 28 Mar 2024 15:59:38 +0100

xz-utils (5.6.1-1) unstable; urgency=medium

  * Non-maintainer upload.
  * Import 5.6.1 (Closes: #1067708).
  * Takeover maintenance of the package.

 -- Sebastian Andrzej Siewior <sebastian@breakpoint.cc>  Wed, 27 Mar 2024 22:53:21 +0100

# pacman --query xz
xz 5.6.1-1

a co tim rikas?

ze to tam bolo. uz to je na verzii -2 a tympadom fixnute. artix. na stroji mi nebezi sshd a neni tam ani systemd. hadam to je oka. pockam na dalsi rozbor a pripadne cely host budem musiet preinstalovat.

proč jako root?

aby som v tesnom zavese mohol pustit pacman -Syu

Tomu říkám easter egg.

Aspoň, že všude používám zstd

Což vůbec nic neřeší, když si tu infikovanou knihovnu natáhne SSH při startu.

Ďakujem za správu. Gentoo je na tom podobne, app-arch/xz-utils-5.6.1 je už masked, vrátili sa k verzii app-arch/xz-utils-5.4.2. Používam síce openRC, ale jeden nikdy nevie čo sa v balíku ešte nájde..

Ak tomu dobre rozumiem tak je to problem len ked OS pouziva systemd ?

Pořád jsem neviděl dokončenou kompletní analýzu toho obfuskovaného kódu - je možné, že má i další „funkce“ než jen infekci sshd při použití se systemd.

Navíc ty můžeš používat jiný init, ale sshd stejně mít zkompilované s podporou systemd, která se jenom nepoužije.

tak hlavní problém je, že autor, který přímo přispívá do projekt celý rok udělal (či jeho jménem někdo jiný) kód, který zanáší záměrnou zranitelnost.

Někteří upozorňují na to, že i jiné jeho commity jsou podezřelé, hodně se motal kolem bezpečnosti a ve dvou jeho commitech byl buffer overflow s možností exekuce.

2 roky plánování, zneužití toho, že původní autor xz měl psychycké problémy, a postupné přebrání projektu vyústilo v kompromitovaný release, který použil binární data v testech! Toto nebyl někdo, kdo by chtěl rychle prachy, toto byl někdo s obrovskou trpělivostí a měl dlouhodobý plán.

Nejvíc absurdní na tom je, že se na to přišlo jen kvůli tomu, že ten backdoor hodně vytěžoval CPU. Kdyby byl dobře napsaný tak to možná nikdo nezjistil.

tak jak se projevoval je velice pravděpodobné, že by se to zjistilo, ale chvilku by to trvalo.

Tohle není amatérská práce někoho, kdo něco zkouší. Může to být je jeden z mnoha pokusů infiltrovat open source, stačí chvilku sekat dobrotu a příjmou tě všudemožně.

Binární kódy, nečitelné věci, asm jsou největší problém a je čímdál složitější se tomu vyhnout, kdejaký kód takové věci obsahuje.

Z druhe strany se ale vytraci ty low-level znalosti a hlavne... moc se u vseho specha. Chceme to mit jednoduche a taky rychle, spousta veci se automatizuje (nic proti), ale v takovem prostredi neco take snadneji proklouzne. Slabinou tohohle systemu je cela filozofie...

Mimochodem systemova dira jsou i samotne "releases" na githubu - kdy system umozni vyvojari nahrat archiv, co vlastne ani nema obraz v repozitari. Aneb ano, zase si nekdo nekde neco usnadnil.

> Mimochodem systemova dira jsou i samotne "releases" na githubu - kdy system umozni vyvojari nahrat archiv, co vlastne ani nema obraz v repozitari. Aneb ano, zase si nekdo nekde neco usnadnil.

U projektů používající Autotools je bohužel obvyklé, že ten tarball obsahuje spoustu věcí navíc, protože postup je takový, že se nejdříve spustí nějaké ty autoconf, automake atd., a až pak se z toho vyrobí ten archiv.

neověřitelnost sestavení je za mě v posledních 10 letech největší problém z hlediska bezpečnosti, týká se to jakéhokoliv projektu a nejvíce to zasahuje různé repositáře pro různé distribuce či jazyky.

Je to těžké doba a čeká nás ještě spousty a spousty práce.

V tomto blogu jsou zajímavé poznatky: https://boehs.org/node/everything-i-know-about-the-xz-backdoor?ref=blog.qassim.uk

Není kouře bez ohně!
Pokud se tohle našlo náhodou, budou tam další a nejspíš mnohem chytřeji schované...

30. 3. 2024, 20:09 editováno autorem komentáře

Otázkou spíše je kolik takovýchto zatím neobjevených případů ještě je!
Domnívám se, že komunita až příliš spoléhá na morální kodex.
Pro mě je však nepochopitelné, že někdo zařadí do veřejné distribuce hacknutý zkompilovaný soubor, místo toho aby si přeložit zdroják.

Ten "hack" se tam dostával při sestavování balíčku rpm nebo deb (detekoval si tohle) ze zdrojáku. Byl sofistikovaně schovaný v build procesu a testech. Nikdo tam nezařazoval žádnou již hotovou binárku s exploitem.

A jaká bude sankce pro autora backdooru?

To je sice dobrá otázka, ale až někdo zjistí kdo to byl a bude tedy alespoň koho obžalovat. Drobný problém je, že to se dost možná (ne-li pravděpodobně) nestane nikdy.

Pak má open-source dost závažný problém, kdokoliv může komitovat jakýkoliv záškodnický kód...

Kód nesmí být anonymní.

"Kód nesmí být anonymní."

... jinak receno, nikdo nikam nesmi nic prispet ... protoze na anonymnim pristupu je cely OS zalozen.

Tohle bude nejspíš jen špička ledovce, kde se náhodou povedlo na problém přijít. Přitom když jsem ve zdejší diskusi před časem poukazoval poukazoval na rizika anonymních a/nebo neprověřených přispěvatelů do kódu, tak jsem byl téměř ukamenován, s tím že kód přece vidí mnoho očí, takže se něco takového vlastně nemůže stát.

Celkem by mě zajímalo, jak konkrétně plánuje komunita takovým incidentům zabránit. Můj názor je ten, že pokud a dokud může do kódu přispívat někdo koho nikdo nikdy neviděl a není nijak prověřený, tak se tomu prostě zabránit nedá. Code review to totiž neodchytí, nebo ne vždy. Zvlášť když se píše v jazyce C, u kterého se pořádají soutěže o co nejlepší ukrytí zlovolné funkcionality.
https://www.ioccc.org/

Tedy mají "klasické" vývojové týmy výraznou výhodu. Mají zaměstnance nebo kontraktory, ti jsou jasně identifikovaní (doklady, social security number nebo u nás rodné číslo), mají smlouvu a jasně danou občansko-právní i trestní odpovědnost, a u minimálně u větších firem jsou také prověřeni bezpečnostním oddělením (včetně ověření historie jejich zaměstnání a vzdělání).

[Lael Ophir]
No me picne... Vy jeste zijete? (nic ve zlem) :)

Alive and kicking :). A působí to, že i vy jevíte známky života.

Tak mi povězte:
1. Kdo a jak byl ztrestán za propašování DUAL_EC do knihovny bcryptu?
2. Heartbleed, už uběhlo spousta vody, takže dvě zvědavé otázky:
2.1 Jednalo se o chybu, nebo o úmyslný backdoor?
2.2 Kdo a jak byl za to potrestán?
3. Kdo a kdy byl potrestán za jakýkoli jiný remote executable flaw?
4. Chyba ssh-keygen v Debianu, kde private key byl z 64k možných. To samé, omyl či úmysl?
5. Nevšiml jsem si, že digitální podpis pro instalaci ve Windows něco znamená. Prostě se ukradne číkoli identita

BTW všechny příklady výše mají známého autora, a vůbec to nepomohlo.

1. 4. 2024, 02:03 editováno autorem komentáře

K bodu 5: Ve Windows kernel mode i user mode drivery musí podepsat Microsoft, na základě žádosti autora a toho že driver projde procesem WHQL. Samotná žádost o podpis musí být podepsaná pomocí Extended Validation Certificate, a tam jsou poměrně striktní podmínky na jeho vydání. Ukradnout "číkoliv identitu" nepomůže. Svého času například autorům Stuxnetu stačilo "jen" ukrást certifikát výrobce HW. Dnes je je pokud vím i pro podpis "obyčejného" SW potřeba EV certifikát (se všemi s tím spojenými požadavky), a klíč musí být uložený na zařízení certifikovaném podle FIPS 140-2 level 2, Common Criteria EAL 4+ nebo ekvivalentu. Přece jen už není rok 2005 :)

ukrást certifikát výrobce HW stačilo i před půl rokem :) https://msrc.microsoft.com/update-guide/vulnerability/ADV230001, něco se prostě nemění.

Microsoft poměrně nově nedovoluje cross-signing driverů. Developer musí mít EV certifikát, který (pro certifikáty vydané od 1.6.2023) musí být uložen na HW tokenu. S ním driver package podepíše, a s MS partner accountem ho pošle MS, který ho následně podepíše WHQL certifikátem. Je samozřejmě možné, že například někomu leaknul EV certificate a MS partner account, s tím že EV certificate byl vydán před vynucením toho pravidla, že musí být uložen na HW tokenu. Nebo je možné, že MS špatně ověřil driver "dvojího použití", který může používat malware. Nic není stoprocentní, ale cesta k platnému digitálnímu podpisu malwaru je dnes výrazně těžší.
https://techcommunity.microsoft.com/t5/windows-hardware-certification/driver-signing-changes-in-windows-10-version-1607/ba-p/364894

[Lael Ophir]
Jinak, abych nejak smysluplne zareaogaval na Vas post.

Nejsem sice uplny expert na vsechny bezpecnostni otazky, ale osobne se domnivam, ze to neni spicka ledovce, ale spis ... no, zacatek. Zacatek, ktery se podarilo vcas objevit. Kdyby se totiz uz podarili podobne utoky v minulosti, je dost pravdepodobne, ze bychom tusili (ne-li vedeli) ze je neco hodne spatne. Ono zase zaskodnckou cinnost neni uplne snadne zkryt, obvzvlast v necem tak rozsirenenm jako jsou Linuxove systemi - tudiz i docela slusne sledovanem.

A jak na to zareguje komunita? Spravny dotaz. Bohuzel, to by nejaka nejdriv musela existovat (jestli kdy vubec existovala). Linuxova (a opensource obecne) komunita me osobne posledni roky spis pripomina roztrousene drobecky a kolem nich hejno mravenecku, kteri se kolem nich hemzi a tu a tam zabloudi k dalsimu drobecku. A dohromady pak tvori dojem mraveniste. Takze ted tezko rict, uvidime casem.

Jinak osobne - uz jsem to tu psal - bych nevzal taky do projektu kazdeho kdo jde kolem. Zas ale na druhe strane opensource projekty stoji a funguji diky spolupraci lidi, kteri se v zivote nevideli. Mozna - s tim jak jsem psal, ze tohle mi prijde spis jako zacatek - je na case trochu prehodnotit nase az prilisne spolehani se na molochovite systemi, ktere sami a bez dohledu vsechno udelaji za nas. Podle me je ted nejlepsi zachovat chladnou hlavu, a zacit pracovat na zjednodusovani a vetsi transparentnosti nekterych procesu.

Skodlivy kod s trochou nadsazky je podle meho mineni za spravne konstalace hvezd mozno ukryt v jakemkoliv jazyce, to asi nebude ten problem. Tady jde o to, ze ten skodlivy kod byl generovan az v dobe buildu z naprosto necekanych zdroju. A to je jeste o rad jina ci situace.

No a nakonec, to s temi firmami je sice krasne, ale bezpecnost to taky nezarucuje. Bylo uz za tech pruseru za ta leta co jsou pocitace ve firmach malo?

PS. Jste ted na koni, co? "Pracovnik Microsoftu zachranil zadnici Linuxarum...." Fakt je tento svet divne misto.

1. 4. 2024, 00:04 editováno autorem komentáře

"Jste ted na koni, co? "Pracovnik Microsoftu zachranil zadnici Linuxarum....""

Tvl kolik je vám let že tyhle dětský války stále ještě vedete ??

[Nickless account]
Dost na to, abych neco pamatoval. Kolik je vam, ze si dovolujete hodnotit moje valky?

Znepokojující je to, že záškodník zřejmě škodil už od konce roku 2021, a na jeho akce se nepřišlo při code review, ani je neodhalilo žádné z těch bdělých očí, které prý zdrojáky sjíždí, analyzují a vylepšují. Přišlo se na to jen protože ten backdoor způsoboval problémy s výkonem. Kdyby dotyčný ten backdoor napsal lépe, tak by tam mohl zůstat mnohem déle.

Doporučení "zachovat chladnou hlavu, a zacit pracovat na zjednodusovani a vetsi transparentnosti nekterych procesu" mi připadá jako okecávání věci bez reálného řešení. No offense intended.

Komerční kód samozřejmě také má své bezpečnostní problémy. Ale propašovat do něj záměrně backdoor je daleko složitější. Kolik dalších projektů jenom tenhle jeden záškodník mohl napadnout pod dalšími smyšlenými identitami? A co jestli takových lidí má v akci řekněme Čína nebo Severní Korea tisíce?

Možná vám připadá, že mám škodolibou radost. Ne, nemám. Linux se používá na spoustě míst, a jeho bezpečnost je proto důležitá. Nejsme fanoušci fotbalových týmů, kteří v opojení kmenovými instinkty jásají, když jiný tým má problém. Vyjma toho nejsem zaměstnanec Microsoftu, a svým starším komentářem k věci jsem žádnou zadnici (zcela zjevně) nezachránil.

Mám za to, že celý IT průmysl má problém. Anonymní autoři kódu jsou jen třešnička na dortu. Máme tu obrovskou spoustu kódu psaného v obskurním C/C++, plného bugů zanesených autory kódu (protože lidé dělají chyby), často s unsafe funkcemi, a bez možnosti plné formální verifikace kódu. Jenom Linux kernel měl v roce 2023 311 vulnerabilities. Podobně tragické je to u ostatních OS, frameworků, browserů, office produktů, DB atd. Desítky let se to lepí jak to jde, někomu to jde lépe a někomu hůře, ale řešení nemá nikdo. Přitom na IT je dneska závislé všechno včetně energetiky, logistiky, maloobchodu, státní správy, zdravotnictví... Vede to k obrovským rizikům. IT průmysl musí udělat zásadní krok ke spolehlivým a bezpečným systémům. Memory safe programming, formal verification... Ovšem je těžké si představit, že takový značně náročný krok komerční firma zaplatí, když tam není dostatečný komerční přínos. Ještě těžší je představit si podobný proces ve světě open source, který má problémy s koordinací vývoje (model bazaar) a s dostatkem zdrojů. Takže nejsem optimista.

[Lael Ophir]
Za me je spis vic znepokojujici jak a kudy byl ten utok proveden.

"Doporučení "zachovat chladnou hlavu, a zacit pracovat na zjednodusovani a vetsi transparentnosti nekterych procesu" mi připadá jako okecávání věci bez reálného řešení. No offense intended."

Netvrdim, ze je to spasitelne a konkretni reseni, ale myslim (nebo si spis troufam doufat) ze je to muze byt aspon nejaky smer. Ono je to asi to stejne, jak kdyby se srazilili vlaky a jeste se ani neusadil prah a Vy behal po sokovanych zeleznicarich a hned ted z fleku po nich chtel nejaky reseni.

Tesi me, ze z toho aspon nemate radost - ja to myslel jsem to spis jako ironicke povzdechnuti nad tim, jak se nekdy veci divne skouli.

" IT průmysl musí udělat zásadní krok ke spolehlivým a bezpečným systémům."
Souhlasim s Vami, ze - presne jak pisete - cely IT ma velky problem a za sebe dodavam, ze ne jeden a uz dlouho. Nejen ty co jste zminoval, nejen ten ktery se ted stal. Zeneme vykon energetickou a narocnost stroju cim dal vic nahoru, jen proto abychom do nich umistili cim dal slozitejsi a nesrozumitelnejsi systemy jejichz prinos je v dost pripadech ve vysledku diskutabilni. A proc? Kdyz to zjednodusim, tak napriklad protoze nejsme schopni ani ochotni si pohlidat par pitomych pointeru a jeste to kolikrat vydavame za prednost a vlastne dnes uz zbytecnost. Take treba to co jsem psal o komunitach povazuji za docela vazny problem Linuxu a opensource vubec.

Kdyz si vezmete v uvahu co se v tomto konkretnim pripade stalo, tak vubec neslo o problem jazyka, ale o problem v procesu a o selhalni lidi kolem toho projektu.

Ale urcite mi neprijde jako dobry napad se zacit plasit, zatratit cely opensource a jeho tak tezce vybudovane pozice, zavadet jeste slozitejsi mechanizmy a nebo vsechno zacit komercializovat. Proto pisu, ze se to ma delat s chladnou hlavou.

Vlastne to pisu skoro vzdycky, kdyz se lide zacnou moc plasit. ;)

Znepokojující je to, že záškodník zřejmě škodil už od konce roku 2021, a na jeho akce se nepřišlo při code review, ani je neodhalilo žádné z těch bdělých očí, které prý zdrojáky sjíždí, analyzují a vylepšují

On dostal svou "pozici" (committer), protoze 2 roky prispival a jeho kod tehdy nebyl zly. Takze on neskodil, ale naopak, 2 roky pomahal.

Tohle je celkove problem a nejen v SW developmentu. Treba prijmete admina do firmy, po 2 letech prace mu date roota ke vsemu. Pak si on diky svym pravum udela nekde backdoory. Po mesici ho chytite (jeste nez backdoory prejdou do produ). Je to rychle nebo pomalu? Jak dlouho musi admin u vas pracovat, aby dostal taky pristup?

"Jak dlouho musi admin u vas pracovat, aby dostal taky pristup?"

On muze admin fungovat bez roota? ... Veskery OS je odkakziva zalozen na tom, ze nekdo nekde neco zverejni, a ruzni kolemjdouci do toho semotamo neco poslou. A kupodivu kdyz nekdo posila casto, tak proste ten jeho kod uz nikdo potom kontrolovat nebude ...

Kdo kontroluje Linuse? Sem ochoten se vsadit, ze cervika primo do jadra by zvladnul levou zadni. Klidne vsem "na ocich".

Pricemz presne takto to funguje naprosto vsude. Kdyz mas firmu, tak mozna prvnich par tydnu budes novackovi stat za zady, pak mozna par mesicu budes nejak overovat zda jeho kod nezpusobuje problemy ... ale pak ... neni v silach nikoho, to bys na kazdeho jednoho prispevatele musel mit nejmin 3 overovatele.

Pokud jsem si správně všiml, tak ten záškodník už v roce 2001 v libarchive nahradil funkci safe_fprint za její unsafe verzi. Prošlo mu to bez diskuse. Podle všeho tím testoval, co všechno mu projde. Jinak souhlas, že se dva roky tvářil, že pomáhá, a nikdo nemohl tušit, že si připravuje půdu pro útok. Zarazí ale to, že ho například jako maintainera prosazovaly dva anonymní a jinak převážně neaktivní účty, nejspíš skrytě patřící záškodníkovi.

Admin dostane přístupy celkem rychle, pokud splní kritéria, byť ty přístupy typicky nejsou neomezené, protože to ani většina admin rolí nevyřaduje. Rozhodně by ale přístupy nedostal anonym sedící v Číně, Severní Koreji nebo Rusku, bez fyzické přítomnosti, bez identifikace, bez smlouvy, bez referencí, bez ověření těch referencí a dosaženého vzdělání a bez dalšího prověřování oddělením bezpečnosti. A i když všechna kritéria splní, tak na něj dále dohlíží bezpečáci. Například lidé z těch jmenovaných zemí by byli bráni jako rizikoví, a pokud by vůbec dostali místo, tak by byli pod důkladným dohledem. Případná levá pak znamená vyhazov, občanskoprávní i trestní odpovědnost, a to že dotyčný v okruhu mnoha set kilometrů nezavadí o práci. Středoevropské IT je malý rybníček, kde zná v podstatě každý každého, a poškozená strana pochopitelně informace o té levé neformálně rozšíří.

Jistě, s dostatkem úsilí, znalosti a peněz se všechno dá obejít. Ale těžko to srovnávat s tím, když posadíte někde v tramtárii k počítači záškodníka, ten odtamtud může celkem triviálně infiltrovat i desítky projektů najednou, a nadělat u toho pořádnou paseku.

IT průmysl má problém a to dost velký, s tím souhlasím. Dost ale pochybuji, že by ho dokázal vyřešit. Z bezpečnosti totiž udělal byznys. Místo bezpečných systémů dodal antiviry, antispamy. Bezpečnost je za příplatek. Řeší se důsledky, nikoliv příčiny. A to nemluvě o mase systémů neaktualizovaných a přesto běžících z důvodu ukončení podpory, nákladů na licence, personálních nákladů - nemluvě o pochybně napsaných aplikacích. Také nejsem optimista.

S open sourcem mám (pokud daný produkt je stále živý) vždy šanci přejít na nejnovější systém. Nemusím řešit problémy s licencemi, změny firemních, prodejních politik, atd. U komerčního sw to ani zdaleka neplatí. Samozřejmě, že každý model má svoje pro a proti - nicméně přestože je Microsoft velkým uživatelem Linuxu a nepochybně má celou řadu bezpečnostních expertů, tak na problém přišel vývojář Postgresu - shodou okolností poslední 2 roky placený Microsoftem, rozhodně to není běžný zaměstnanec a rozhodně není zaměřený na bezpečnost.

A i kdyby se IT průmysl stavěl na hlavu, tak ten Titanik nezastaví. Musely by se předělat základní koncepty. Musela by se zahodit zpětná kompatibilita. To komerční firmy nikdy neudělají.

Souhlas, že by se musely předělat základní koncepty. Nicméně občas přicházejí generační změny, často umožněné rozvojem HW. Microsoft výrazně vylepšil OS přechodem na WinNT, a další možností byl přechod na Midori OS, který ale skončil na HW náročnosti a nízké návratnosti investice. Apple vylepšil OS přechodem na NeXTSTEP, byť to byl poněkud drsný přechod. Google by mohl mít podobnou možnost u Fuchsia OS. Jednou do té bezpečnosti a spolehlivosti snad někdo pořádně šlápne. Zpětná kompatibilita asi trochu utrpí, ale v době virtualizace ne nutně dramatickým způsobem. Třeba přechod z DOSu a Win9x na řadu NT proběhl relativně dobře. Dobře proběhl i přechod z x86 na x64. Z novějších případů je dobré zmínit Widows Subsystem for Linux, který funguje relativně slušně, přestože to podle všeho nestálo žádné dramatické úsilí.

Jaká je šance, že během 10 let přijde generační změna HW nebo SW? Kdo má finanční i tržní sílu prosadit revize API? Problém není, že by nebyla vůle, ale rozsah a komplexita.

Moc pekny backdoorek....
https://github.com/amlweems/xzbot

Me by zajimalo, kdy zareaguji borci z NUKIBu
2024-04-09 porad nic https://nukib.gov.cz/cs/infoservis/hrozby/