Arch má v Extra repo aktuálně verzi 5.6.1-2... downgrade na poslední verzi (5.4.6-1) před tou verzí 5.6.0 se udělá takto:
pacman -U https://archive.archlinux.org/packages/x/xz/xz-5.4.6-1-x86_64.pkg.tar.zst
případně taky 32 bit verze:
pacman -U https://archive.archlinux.org/packages/l/lib32-xz/lib32-xz-5.4.6-1-x86_64.pkg.tar.zst
30. 3. 2024, 18:25 editováno autorem komentáře
teď ale koukam že ta aktuální verze 5.6.1-2 by toho měla bejt zbavená, viz:
https://archlinux.org/news/the-xz-package-has-been-backdoored/
Taky mě to zaujalo. Na druhou stranu Microsoft bude svým způsobem jeden z největších distributorů Linuxu. Roky jsem měl na firemním notebooku nějakou linuxovou distribuci, ale loni jsem se už na to vykašlal, nechal tam W11 a jen doinstaloval ten jejich Windows Subsystem for Linux.
Na některé věci je pro mě Windows výhodnější a ten virtualizovaný Linux ve formě, v jaké to připravil Microsoft, mi vlastně taky dostačuje.
Nepochybujem ze Microsoft ma aj velmi schopnych programatorov. ako destop je urcite W1O, 11 lepsi system ako Linux aj ked u mna vyhrava OS X. Programovat si ale vo windowse neviem ani predstavit a ten ich powershell je pre mna hotove nestastie. Viem asi je to o zvyku, keby som na tom musel pracoval tak si zvyknem, ale ked nemusim a mam lepsie varianty tak preco sa to ucit.
Dobrý desktop, ale Gimp mi na tom išiel ako pos***y a Pinta detto. Asi to bude mať nejaké nevýhody. Plus mi zrušili steam spolu s 32 bit api :( Skôr sa mi nepáči, než páči, jedine, že ma to zblblo a musím si prehadzovať gombíky na oknách naľavo. Kebyže viem, ako behať logic pro na niečom inom, už macbook ani neotváram :)
Mne sa páčia viac linuxové desktopy, aj keď xorg je stará technológia plná rovnákov na ohejbák a veci waylande sa ešte musia odladiť.
Ale až sa wayland odladí, bude veľmi fajn. Myslím si, že to bude čoskoro, lebo redhat to dosť tlačí a momentálne aj raspberry pi.
PowerShell je paradoxně jedna z nejlepších věcí, co se jim povedla. U lidí zvyklých na bash ale nemá moc šancí, je to úplně jiný svět. Fungovat efektivně v obojím je na psychiatra. Už jen fakt, že bash má pipe coby stdout->stdin, zatímco PowerShell vše předává jako objekt. Stejný znak, ale úplně jiný význam.
Get-Process notepad | Stop-Process
Jinak já osobně jsem s programováním na windows spokojen od chvíle, co používám WSL2 :-) To je další skvělá věc, co se jim povedla. PyCharm i vscode s tím fungují na jedničku.
Asi to holt bude jako všude jinde: některé produkty mají dobré týmy a schopné manažery, u jiných produktů jedno z toho chybí a u pár posledních chybí oboje.
Ono mi to skor pride, ze ci nam tu root.cz necaruje nejaku gratuitously dubious windows propagandicku :).
Kolko drobnych plati mrkvosoft za taketo mile veticky v clanockoch? Beriem to ale skor tak, ze autor sa troska nechal uniest svojou laskou k mrkvosoftu. Alebo sa nam snazi ukazat, ze aj windowsaci su dorby ludia? Dovodov moze byt nekonecno. Mohol by ozrejmit svoj nazor :).
Dnes uz totiz mame takuto dobu. Insidious product placement. Zaber na produkt a jeho znacku v jutub videu. Sneaky commity, a tak... Nechame na cvicenie pre citatela. Kto ma modzog ma, kto nema nema.
Andres Freund ma tolko s mikrosoftom ako automotive designer/automechanik co dizajnuje nastavby na mercedes unimogy. Kludne ich moze robit aj pre tatry. A to aj robi.
Je to postgres clovek a momentalne ma zrejme kontrakt s MS.
Podobne ako mnoho inych high profile open source vyvojarov, vztahy na tejto vrstve ludskej existencie vedia byt dost fluidne, vid Poul-Henning Kamp a.k.a phk, ktory pri jednom kontrakte pre jednu webfarmu (ala websupport, ktora uz ani neexistuje) vyvnul jails. Alebo pri kontrakte pre uplne inu firmu, iste noviny, vyrobil varnish cache.
Jails viedli k solaris zonam a ... o 20 rokov neskor ... k tragikomickym linux containerom. Company co zapaltila vyvoj jails uz ani neexistuje, varnish dodnes nema konkurenta mozno len v nginxe, neviem ci tie noviny co ho splodili este existuju (som prilis lenivy checknut). Povieme, ze phk bol vtedy "websuportak", "rootnik"? Jasne ze nie. Cize volba tej vety, so slovom mikrosoft, nuti podaktorych mysliet.
Nikto, doslova nikto z open soruce komunity, ani major periodika, ktore riesia xz hack, sa nepotrebuje zmienovat o sucasnom kontraktorovi Andres-a Freund-a. Cize ako som uz povedal velmi ma zaujima autorov dovod pre vypichnutie daneho detailu. :D
Důvod vypíchnout tenhle drobný zajímavý detail je jen v tom, že je to drobný zajímavý detail. Ten člověk je rozhodně hrdinou dne a zaslouží si být jmenován, stejně jako jeho zaměstnavatel, který ho v současné době za práci platí.
Žádné spiknutí a tajná dohoda v tom není. Přišlo mi jako zajímavý střípek, že pracuje právě pro Microsoft.
Myslim, ze Red Hat ( dobre ... i Microsoft) si muze s hrdosti pripsat solidni zarez. Vzhledem k tomu, ze xz a lzma patri mezi celkem slusne vyuzivane kompresni programy, u nichz by asi malokdo cekal nejaky podraz, se jim podarilo za minutu dvanact (a nebo minutu po? *) zabranit solidnimu pruseru. Dobra prace - osobne me jima hruza, pri predstave jake vsechny skody to mohlo napachat. Ti kteri si dali tu praci tenhle masivni utok pripravit musi byt asi ted radne nastvani a zklamani.
Mimochodem, z toho co psal Petr v tom clanku mi prijde nasledujici pasaz temer neuveritelna:
" Zároveň se objevilo další jméno, Jigar Kumar, který začal tlačit na vývojáře, aby úpravu přijali a požadoval, aby Lasse Collin přidal do repozitáře dalšího správce. To se také stalo a JiaT75 se stal jedním ze správců. Od té doby se Jigar Kumar už nikdy neozval."
To me proste hlava nebere...
* Tady si nejsem uplne jisty. Ja sam tvrdohlave pouzivam uz roky Debian stable, takze me se to snad vyhlo. Ale pred casem byl trochu tlak na uzivatele aby pouzivali spise testing a nekteri dokonce doporucovali unstable. Takze netusim kolik desktopu mohlo byt potencionalne zasazenych. A u Fedory uz vubec nemam paru...
30. 3. 2024, 19:24 editováno autorem komentáře
Hele, nevěř tomu, že by tohle byl první úspěšný pokus.
AD: "Zároveň se objevilo další jméno, Jigar Kumar, který začal tlačit na vývojáře, aby úpravu přijali a požadoval, aby Lasse Collin přidal do repozitáře dalšího správce. To se také stalo a JiaT75 se stal jedním ze správců. Od té doby se Jigar Kumar už nikdy neozval."
Stejný čičmunda to možná zkoušel na XY dalších s podobným schématem. Jako bys řekl, že Paní Nováková, která naletí "lékaři z USA" a pošle mu milion kč, že je jediná....není kouře bez ohně. Prostě došlo k použití podobných scamovacích technik, které fungují na osamělé tetky.
A pokud tohle bude uzavřeno bez úpravy procesů, tak Linux není možné považovat za bezpečný. Tohle se prostě vůbec nemělo stát.
[CPU]
Mne v tuto chvili spis desi to, ze to pravdepodobne neni posledni pokus.... Alespon se to da predpokladat. Uz jen z toho, ze k jeho odhaleni doslo jen cirou nahodou.
Ale rozhodne neni nejlepsim resenim zacit panikarit a vsechno bezhlave prekopavat...
30. 3. 2024, 21:56 editováno autorem komentáře
Tohle byl nejspíš zmrvený pokus nějaké Indické/Pákistánské skupiny. Ale pak tu jsou různí Rusové, Číňané, Serverní Korejci, ale i Američané, kteří mají velký zájem na přístupu k libovolnému systému. Je téměř jisté, že ti by si kód nejspíš pořádně otestovali, resp. vložili by do toho daleko větší úsilí.
Tohle byl v podstatě takový dětský pokus, KTERÝ BY MOHLO ZOPAKOVAT MOŽNÁ I 20% PROGRAMÁTORŮ z rootu. Kolik takových identit takový čičmunda má? Dvacet? Někdo ho platil, takže určitě měl celé dny na sezení nad kódem. V kolika projektech byl zapojený? Jednou jako Kumar pak Pajáb, Aahan, Adhrit a Kundar? Není kouře bez ohně!
EDIT: Tohle už byl NĚKOLIKÁTÝ POKUS čubčit kód Linuxu.
Tady to Pišta a Fišta dělali ještě okatěji a dost dlouho jim to procházelo:
https://www.root.cz/zpravicky/minnesotska-univerzita-nesmi-prispivat-do-linuxoveho-jadra-umyslne-vkladala-chyby/
30. 3. 2024, 22:03 editováno autorem komentáře
Překopávat určitě ne, ale:
- revidovat procesy (ve smyslu procesů vedení/řízení)
- zkontrolovat kontrolní mechanismy
- zabránit zopakování chyby
- provést kontrolu přístupů
- provést audit stávajícího kódu
- ideálně se zaměřit na bezpečnost
Není kouře bez ohně:
https://www.root.cz/clanky/postrehy-z-bezpecnosti-v-pypi-bylo-objeveno-pres-sto-balicku-s-malwarem/
30. 3. 2024, 22:13 editováno autorem komentáře
[CPU]
V prve rade si nemyslim, ze to byl zpackanej utok nejakych script kidies. Tohle vypada na peclive naplanovanou a profesionalni akci. Utok byl miren na ssh a byl veden pres prostrednika (xz) a skodlivy kod se do programu dostal z testu. Myslim, ze tohle by ani toho nejsilenejsiho bezpecnostniho analytika, ani v tom nejhorsi nocni mure, pri vsi paranoii, ktere jsou takovy lide schopni, proste ani nenapadlo a utocnici to evidentne vedeli. Navic priprava jedne jedine zaskodnicke akce, trvala nekolik let, na to nemaji takovy lide trpelivost. A navic, nejvetsi hruza, ktera z toho plyne je ve dvou vecech: principialni jednoduchosti a zaroven v neuveritelnem dopadu.
Tvoje navrhy jsou sice krasne, ale maji - podle meho nazoru - dve zasadni chyby: Zavadeji do stavajiciho -jiz tak dost komplexniho - systemu dalsi urovne slozitosti a jaksi automaticky predpokladaji, ze jej budou vsichni respektovat. Jenze vyssi slozitost znamena dalsi riziko, vice moznosti pro utocnika a mensi pravdepodobnost odhaleni. A s tou nucenou spolupraci to ve sfere opensource neni - jak se uz leta ukazuje - taky tak zdaleka ruzove. Je naivni si myslet, ze to vsichni budou takto delat. To prepoklada vzajemnou dohodu, kooperaci, respektovani pravidel a standardu (a jejich tvorbu a udrozovani) a to jsou - aspon to tak vypada v dnesnim svete Linuxu - temer sprosta slova...
Ac beru v potaz, ze mas urcite kus pravdy, tak jsem presvedceny, ze reseni chce chladnou hlavu a hlavne spis zjednodusovani a vetsi transparentnost celeho systemu ...
30. 3. 2024, 22:39 editováno autorem komentáře
Kdybys to znal ze strany útočníka, tak se nikdy neútočí jen na jedno místo. Útočí se vždy na řadu míst a zjišťuje se, kde je slabé místo. Když vypadá zajímavě víc míst, tak přidáš lidi. Pochop, je za tím spousta práce a času MNOHA LIDÍ, je to moc drahé na to, abys to zkoušel jen jediným způsobem. Hodně lidí o tom má představu asi jako Hurvínek o válce (nemluvím o tobě, ale obecně ...že to dělal pan Kumar...), tohle řeší celé skupiny lidí a dost možná ani žádný Kumar nikdy nebyl, možná ten Kumar byl vždy někdo jiný, některé skupiny mají i svoje kanceláře a velmi dobře rozdělené úkoly. Nikdy ti nezaplatí, když neodvedeš svojí práci. Takže jeden čičmunda se snaží někam vetřít, další čičmunda předstírá užitečnou práci, jiný čičmunda připravuje payload. Ale klidně si věř na panenskou prostitutku nebo Bigfoota :-D
30. 3. 2024, 22:56 editováno autorem komentáře
[CPU]
Ty mi mozna s tim Kumarem nerozumis. To co me na tom tak fascinuje je situace z pohledu maintainera toho projektu: Prida se ti tam manik, ktery behem relativne dlouhe doby posle par, z pohledu projektu cekem nevyznamnych, patchu. Pak se tam najednou objevi nejakej Kumar, o kterem nikdo nic nevi, a zacne do vsech hucet, ze ho musime pribrat mezi "plnohodnotne" cleny tymu a vsechny jeho patchy proste prijmout.
Ja jsem jejich komunikaci necetl, takhle to vypliva z clanku, ale stat se to u meho projektu, tak s tim Kumarem vybehnu tak, ze by nestacil pocitat schody a doslapl bych si i na toho prvniho manika. Oni, mu (Kumarovi) malem podekovali a z mileho manika udelali jednoho ze spravcu, takze si tam ted muze opravdu delat co se mu zachce. A vubec jim neprijde divne, ze od te doby se zahadny Kumar uz neozval. Proste nepochopis.
Tady doslo k naprosto fatalnimu a - aspon pro me - nepochopitelnemu selhani lidskeho faktoru. A proti tomu ti zadne kontroly ani audity asi moc nepomuzou.
30. 3. 2024, 23:39 editováno autorem komentáře
Já se bojím, že mluvíme o stejné věci, ale nějak si nerozumíme.
"Tady doslo k naprosto fatalnimu a - aspon pro me - nepochopitelnemu selhani lidskeho faktoru."
No jistě, ale já k tomu dodávám, že útoky na lidský faktor jsou vždy nejlevnější a nejsnazší. Proč hledat bezpečnostní slabinu v systému, když lze poslat paní Vomáčkové z účtárny e-mail, aby se přihlásila tam a tam a přeinstaloval si certifikát? Útoky na lidi jsou nejjednodušší a nejlevnější, nechat se totálně zblbnout může jak hloupoučká osamělá hospodinka, tak i sociálně neobratný programátor. Vezmi si to, jak to bylo primitivní a přitom účinné, na to nepotřebovali žádný velký skill. Kolik takových přístupů ještě mají?
Proto tvrdím, že tu jsou relevantní otázky:
* no to se přece nemohlo stát, nebo ano?
* co když to zkusili na dalších 50 lidí?
* pokud tady uspěli, kde jinde se jim to ještě povedlo?
* uspěli skutečně jen zde, nebo mají XY dalších přístupů?
Pochop, když najdeš v procesu chybu, měl bys zjistit, kde je kořenová příčina a jestli tohle není jen jedna chyba ze stovky, které ti utekly.
A to nejhloupější, co by se mohlo stát, je to uzavřít se slovy "Tradááá, Kumar byl odindován a všichni si budeme dál žít v říši štastných skřítků.."
Ale ano, chápu, že můžu působit jako ELFo v říši šťastných skřítků, protože kladu nepatřičné a zlé otázky, když je tolik důležitější práce, která se musí udělat.
Říše šťastných skřítků:
https://www.youtube.com/watch?v=w-4hlbAtfvk
Všechno je hrozně fajn...protože všichni předstírají, že to je fajn:
https://www.youtube.com/watch?v=u1pR4T2_A0A
31. 3. 2024, 12:50 editováno autorem komentáře
Já bych řekl, že tady je ještě další aspekt. Na to, jak důležitý to byl projekt - resp. jak důležitým byl udělán - distribuce pomocí xz komprimovaly balíčky a dokonce i jádro, tak se o xz vlastně vůbec nikdo nestaral. Původní autor měl nějaké psychické problémy (ok, to se může stát) a nikomu nepřišlo důležité buď ten projekt škrtnout a dál jej prostě nepoužívat a nebo jej prostě převzít (Debian, RedHat, Fedora, SUSE).
V tomhle já vidím selhání lidského faktoru ale rozhodně ne na straně autora xz.
31. 3. 2024, 13:00 editováno autorem komentáře
V tomto je trosku vyhoda u BSD, kde sa sa core team stara o kernel tak aj o world. A je teda vacsi predpoklad, ze sa to nestane (i ked FreeBSD malo nedavno zaujimavy preslap s wireguardom, ktory sa ale do release nedostal. Ale tiez za 5 min 12).
S xz sa spomina Linux kedze utok bol odhaleny na Linux. Co mna trosku zarazilo bol fakt, ze JiaTanove patche boli akceptovane do libarchive a nikomu neprislo divne, ze safe_printf bol nahradeny fprintf.
Ci tie commity boli len naoko alebo to bol skutocne podklad attack vector do buducnosti je tazko povedat.
[Heron]
+1
Ja bych rekl ze to je spis problem, ktery se tyka komunitniho vyvoje jako takovaho. Nestaram se o nic co nespada pod primi zajem moji komunity (xz prece funguje a ma svoji komunitu ktera jej udrzuje. Tak co?) a ani se nesnazim vyjit vstrict ostatnim (Jestli neco chou ostatni, at si nejak poradi, vzdyt maji k dispozici zdrojaky.)
To je ale myslim vec, ktera je tak napevno svazana s opensource projekty, ze s tim v dohledne budoucnosti tezko nekdo neco udela.
Protoze tomu bezny webovy devel nerozumi( moc low level) a vyvojari smatlatouch mobilnich appek taky ne. Cili je malo vyvojaru. Pouzivat predpripravene api/abi dovede kazde jelito. Delat jeho vyvoj a udrzbu vsak uz se nikomu nechce (a nemusi to byt o schopnostech_.
Kdysi jsem mel par prispevku do glib,bionicu a binutils - vetsinou se jednalo o opravu naprostych prasaren na ktere se prislo pri vyvoji a cteni kodu pro systemy mimo linuxu. Tedy nikoliv hlavni cinnost. Nula zajem na strane potencialnich zamestnavatelu. Upozornuji jen ze nejsem vyvojar. Jen mne stvou ocividne prasarny ktere mi komplikuji praci.
Útoky na lidský faktor nejsou nejlevnější a nejsnazší vždy, ale teprve tehdy, když už nějakou základní míru (ne úplně nízkou) technického zabezpečení máte.
V tomhle případě nebylo to zneužití zas až tak jednoduché, jak to vypadá – štěstí stálo nejprve na straně útočníků, těsně před „koncem“ se přiklonilo na druhou stranu.
Obrana proti tomu u komunitního opensource moc není. Některým se třeba v diskusích o forcích Redisu nelíbil „komerční opensource“, že to není ten správný opensource. Přitom ale nejsnazší obrana proti tomuhle typu útoků je právě to, že software má nějaké placené správce, o kterých někdo ví, kdo to je, má je „na výplatní pásce“, může je kontrolovat. Pokud je správcem softwaru někdo, kdo šel zrovna kolem, to riziko zneužití tam je. Dostat se ke správě projektu, který nemá aktivní přispěvatele nebo jich je málo, je překvapivě snadné – pokud je dostupný někdo z původních správců.
[Filip Jirsák]
Obavam, se ze komercni, ani polokomercni projekty nejsou proti utokum na lidsky faktor chraneny vice, nez ciste opensource. To me prijde jako iluze. Zkusenost z ruznych firem ukazuje, ze pokud se nedodrzuji pravidla bezpecnostni politiky, nebo jsou na houby nastavena (prilis prisna, nebo naopak prilis benevolentni), nebo se alespon nepouziva se "zdravy" rozum (jako v tomto pripade), pak Vam nic nepomuze ze mate lidi, kteri tohle maji na starost na vyplatni pasce. Maximalne snad po nich muzete zadat nejakou nahradu skody, ale i to Vam ve finale muze byt uz prd platny... :(
D.A.Tiger: Už jenom to, že ten vývojář má nějakou právní identitu, protože podepsal nějakou smlouvu, chodí mu peníze, je výrazné plus. Jia Tan je jen účet na GitHubu a e-mailová adresa, nikdo ho neviděl, nikdo s ním nemluvil a taková osoba pravděpodobně vůbec neexistuje.
Když byl průšvih kolem OpenSSL, „adoptovalo“ ho pár firem (pod různými forky) a vznikla iniciativa, aby komerční firmy zajistily lepší péči o ty nejdůležitější knihovny, na kterých „závisí internet“. Jenže těch knihoven, o které se od roku 2003 naštěstí stará náhodný týpek z Nebrasky, je spousta. Funguje to vlastně hrozně hezky, což dokazuje, že je na světě spousta dobrých lidí – ale ochrana proti průšvihům prakticky neexistuje. Mně připadá, že ten útok byl tak trochu kanón na vrabce – že by pravděpodobně uspěli stejně i s daleko horším krytím. Nakonec je dostalo to, že byli o dost horší programátoři než zpravodajci…
že ten vývojář má nějakou právní identitu, protože podepsal nějakou smlouvu, chodí mu peníze, je výrazné plus
To mi připomnělo, jak jsme měli ve firmě pro testovací účely vytvořeného uživatele. Postupně jsme zadávali všechny potřebné údaje, jak to systém potřeboval, a ověřovali, že tohle funguje, tamto funguje...
Když došlo na revisi účtů, na HR (přes výslovné varování!) to překlopili do nového personálního systému - a na jejich chybu se přišlo ve chvíli, kdy se dožadovali čísla účtu, kam posílat výplatu. ;oD
Že někomu chodí peníze a má v pořádku papíry, ještě nemusí znamenat, že takový člověk vůbec existuje.
Tak to bol ten lepsi pripad. U nas (ked firmu prebrala jedna banka) robili reviziu uctov o nas bez nas a proste stopli jedneho uzivatela na domene. Lenze pod tym uzivatelom bezalo na produkcii niekolko iis servisov, par python skriptov a cely workflow. Takze odstavili celu produkciu a namiesto toho, aby ho opat na par dni spustili, kym zistime ktore vsetky servisy pod nim bezia a nahradime novymi uzivatelmi (co servis, to iny username), tak proste firma stala, kym sme postupne nepreklopili na novych uzivatelov. A to boli aj xx- rocne projekty, kde ten user bol v kode a git vtedy sa este nepouzival.
A nechybela vam nahodou dokumentace k tomu co ktery technicky user ma za procesy ci co ktery proces potrebuje? Meli jste taky docku k cele bussiness logic? Docka k architekture? Docka k funkcni skriptu? .Nebyla to typicka implementace v nasich krajich bezna? -> udelam to rychle,skoro zadarmo a dokumentace je na kusu toaletniho papiru napsana v ruce v kapse byvaleho majitele ktery je po smrti?
O tom svedci i ten user v kodu - to je prasarna na druhou. To by neproslo ani prvnim code review.
Mame i 30 let stare projekty a jsou k tomu poznamky z code review. Pravda je to vetsinou externi system nad repository nebo emailova komunikace s patchem.
Ktery jednonohy kun bez mozku ale pouzival na vsechny scripty/joby jednoho technickeho usera? Co to bylo za vocasa co to nastavoval? To je preci 25 let zakladni znalost ze se vse nema hazet na jednoho technickeho uzivatele.
Resim akvizice. Prasarny tohoto typu nejsou u mne ojedinele.
[CPU]
Ja netvrdim, ze se to nemohlo stat vicekrat, ani ze se treba neodhali dalsi pripady. Ani ze JiT75 a Kumar se vyparili, ve chvili, kdy byla jejich proradnost odhalena a uz se nikdy neukazou. Naopak, obavam se ze ted je nekde velkej mitink (a mozna padaj i hlavy) a resi se jakych chyb se dopustili, a jak to priste navliknout lip. Sam priznavam, ze mam obavy z toho, ze k podobnym utokum dojde v budoucnosti s nejvetsi pravdepodobnosti znovu. Vzdyt stacilo fakt jen malo a doslo k tak velkymu prusvihu, jaky minimalne na Linuxu nema obdoby, jestli vubec.
Na rovinu, kdyz to reknu (napisu) na plnou hubu: me proste ohromuje ta nebetycna blbost spravce projektu a vyvojarskeho tymu s jakou se nechali zmanipulovat. A ano, kdyz se to podarilo v jednom tymu, neni nenulova pravdepodobnost, ze s to povede u jineho... Systemovych utilit s podobnym vyznamem jako ma lzma (xz) je porad vic nez dost.
31. 3. 2024, 13:43 editováno autorem komentáře
[D.A.Tiger]
"Na rovinu..."
Tak pod tohle bych se podepsal.
Bohužel se mi vybavila situace s hláškou "TrueCrypt již není bezpečný".
Bezpečnostní problémy jsou jako ledovce, největší část je vždy skrytá a vidíme jen jeho špičku. Proto jsem z toho tak nevrlý. Tím spíš, že se obávám, že nebudou přijata nápravná opatření. Myslím, že by stálo za to provést důkladnou kontrolu.
Tohle je velmi podobná historka:
https://www.aricoma.com/cs/inspirace/utok-na-solarwinds#
31. 3. 2024, 14:34 editováno autorem komentáře
me proste ohromuje ta nebetycna blbost spravce projektu a vyvojarskeho tymu s jakou se nechali zmanipulovat
Vy byste to udělal stejně. Co měl ten správce projektu dělat jiného? Ví, že sám se dál správě věnovat nemůže. Žádný vývojářský tým neexistuje, možná jen občasní přispěvatelé. Jeden z přispěvatelů se nabídne, že správcovství převezme, další ho podpoří. Do teď by mu to každý správce opensource projektu rád předal, protože je to naděje, že projekt bude dál pokračovat.
Tohle se děje dnes a denně. A případ XZ na tom nic nemění. Protože ten původní správce projektu z nějakého důvodu nechce nebo nemůže pokračovat s tím projektem, tím méně bude mít chuť, čas, motivaci a prostředky lustrovat nového správce. Navíc stejně nemůže ničemu zabránit.Pokud by správcovství projektu nepředal, bude jeho projekt akorát dál pomalu umírat – ten nový zájemce oznámí fork a dál to bude úplně stejně, akorát pod jiným jménem.
[Filip Jirsak]
"Vy byste to udělal stejně. Co měl ten správce projektu dělat jiného? "
Ne, a o nekolik prispevku vyse jsem jasne napsal co bych udelal. Ale specialne pro Vas: S obema bych za takove situace vyrazil dvere. A nic by na tom nezmenilo ani to, ze bych ten projekt v danou chvili nezvladal. A myslim to smrtelne vazne.
31. 3. 2024, 18:23 editováno autorem komentáře
D.A.Tiger: Smrtelně vážně to myslet můžete, což nic nemění na tom, že byste se do takové situace (správce projektu) ani nedostal. Protože jako správce projektu byste musel vycházet s daleko divnějšími lidmi. Navíc jste nenapsal v jaké přesně situaci by to bylo. Po prvním e-mailu na podporu? Po druhém? Myslíte si, že jich bylo víc?
31. 3. 2024, 20:00 editováno autorem komentáře
[Filip Jirsak]
Takze po poradku.
"Protože jako správce projektu byste musel vycházet s daleko divnějšími lidmi."
To muze byt klidne pravda, nicmene taky nemusim do sveho repozitare a projektem pribrat kazdeho kdo jde zrovna kolem. Dokonce do toho repositare nemusim pustit vubec nikoho.
"Navíc jste nenapsal v jaké přesně situaci by to bylo"
Ale napsal. Presne jsem popsal tu situaci, dokonce jsem ji citoval z Petrova clanku. Evidentne jste se vykaslal na to si to precist, a ja to fakt nebudu znuvu cele kvuli dohadovani s Vami psat znovu.
Dokonce do toho repositare nemusim pustit vubec nikoho.
Ano, o této situaci jsem psal – udělá se fork, vy máte svůj repozitář, který je považován za opuštěný, a vývoj (nebo alespoň údržba) běží v tom forku.
Presne jsem popsal tu situaci, dokonce jsem ji citoval z Petrova clanku.
To je přesný popis situace jak z Cimrmanů. Předpokládám, že myslíte tohle:
Zároveň se objevilo další jméno, Jigar Kumar, který začal tlačit na vývojáře, aby úpravu přijali a požadoval, aby Lasse Collin přidal do repozitáře dalšího správce.
Právě proto jsem se ptal, zda byste je vrazil už po prvním nebo až po druhém e-mailu. Protože víc těch e-mailů (nebo jiných zpráv) ani být nemuselo. Navíc je otázka, zda byste si toho vůbec všiml, že na to tlačí ten samý člověk. A i kdyby ano – opravdu by to byl důvod, abyste vyhodil oba dva? Vyhodil byste z projektu člověka, který je aktivní, jenom proto, že ho podporuje někdo jiný, možná trochu neomaleně?
Když se zpětně soustředíte na ty dva s vědomím toho, co udělali, vystupuje to krásně na povrch. Ale kdybyste byl v situaci toho původního správce, pravděpodobně byste nepoznal vůbec nic. Protože byste se setkával s mnohem divnějšími lidmi. U těchto dvou byste naopak ocenil, že s vámi komunikují anglicky a ne čínsky, že nezakládají páté issue ke stejnému problému a u jednoho z nich že přispívá kódem a ne jen komentáři, jak to že jste nenaprogramoval úpravu, kterou by on potřeboval pro svůj projekt a jinak by byla úplně k ničemu akorát by zaplevelila kód.
[Filip Jirsak]
Jenze ono je celkem irelevantni kolik podnetu dotycny da (navic je tam jasne napsano, ze na to tlacil - to asi nebudou dva e-maily). Podezrele je to uz ve chvili, kdy mi naprosto neznamy clovek zacne do projektu protlacovat jineho, o kterem taktez v podstate nic nevim uz proto, ze - z hlediska toho projektu - nijak extra neprispel. Jak jsem psal, jako spravce projektu nejsem povinen do nej pripustit kazdeho kdo jde zrovna kolem, a uz vubec si nenecham narizovat kdo ne nem ma pracovat.
Takze je celkem jedno jestli po prvnim nebo druhem. Dulezite je, ze bych se tim nenechal ovlivnit a uz vubec bych takve lidi do toho projektu nepustil a nebo jim rovnou znepristupnil repositar.
31. 3. 2024, 21:18 editováno autorem komentáře
D.A.Tiger: Když vy máte pořád hrozně naivní představu, že má takovýhle projekt desítky či stovky přispěvatelů, ze kterých si správce vybírá. Vzhledem k tomu, že ten projekt měl jediného správce, který navíc za sebe potřeboval náhradu, tipoval bych si, že to bylo spíš tak, že občas možná někdo přispěl. To, že vám do projektu přispěje někdo neznámý, je běžná situace – někde to možná budou prakticky všechny příspěvky. Někdo přijde, pošle patch na jednu chybu, která ho trápí, a už o něm nikdy neuslyšíte.
Jak jsem výše odkazoval na xkcd: Dependency, neodkazoval jsem na to jako na vtip, ale na popis reality mnoha OSS projektů. XZ na tom asi byl o něco lépe, ale ne o moc. Pokud se rozhodujete, zda nechat projekt osiřet nebo ho předat náhodnému týpkovi, co jde okolo, jasně že zvolíte náhodného týpka. Zejména když ho podpoří jiný náhodný týpek.
[Filip Jirsak]
"Když vy máte pořád hrozně naivní představu..."
Ale houby :-D To spis Vy mate naijivni predstavy o protistrane. Vzdyt ja jsem se svymi projekty v naprosto stejne situaci - s tim rozdilem, ze ja nemam zadne psychycke problemy, ale me diky zamestnani (vetsinou) chybi dost casu a sil se jeste venovat necemu dalsimu. Takze mam naprosto presnou predstavu.
31. 3. 2024, 21:35 editováno autorem komentáře
[Filip Jirsák] a [D.A.Tiger]
Organizované skupiny mají specialisty, kteří do projektu klidně mohou přispívat něčím zajímavým, TO JIM PŘIDÁ NA DŮVĚRYHODNOSTI.
Nezlobte se, ale vy oba pořád žijete v rozsahu malého českého mozečku a s mentalitou na úrovni pozdních devadesátek...
Přečtěte si třeba tohle:
https://sinopsis.cz/cinske-kriminalni-organizace-stavi-tovarny-na-podvody-v-jihovychodni-asii/
Takové organizace mají klidně STOVKY ZAMĚSTNANCŮ!
A pro Indii to platí stejně, tam je to mnohem, MNOHEM divočejší!
Pokud pro takovou společnost začnete pracovat, rychle zjistíte, že máte třeba dvacet kolegů pracujících na stejném "projektu", projektu je XY a že organizace má specialisty na COKOLIV a zbytek si umí koupit na darknetu.
Jak můžete jeden, druhej nebo třetí, co se tady hádáte, tvrdit že víte, o co jde? To úplně klidně mohla nějaká intelligence agency najmout nějakýho troubu z Indie, aby udělal oč žádají. Ať už Rusko, USA, Čína, Indie nebo další světoví hráči, kterým by se hodil backdoor do milionů systémů. Třeba holt jenom vybrali nesikovnyho Kumara... Šlo o poměrně sofistikovaný řešení... Nevypadá to na týpka, co chtěl víc strojů do svyho botnetu... Takoví publikujou aplikace na Play Store...
Jsou tisíce věcí, které se neměly stát a přesto se staly a nejen staly, dějí se denně. Ani na cestě z místnosti do mís místnosti si nemohu být jist životem, natož když se vydám na cesty, notabene něčím podobně nebezpečným, jako je třeba auto.
Nic vlastně není možné považovat za bezpečné. Jdou po vás. A psychiatrie je ten třetí dům vlevo. Nic ve zlém.
A pokud tohle bude uzavřeno bez úpravy procesů, tak Linux není možné považovat za bezpečný. Tohle se prostě vůbec nemělo stát.
Mně teda překvapuje, že tohle někoho překvapuje. Dalo se očekávat, že někdo něco takového zkusí – příkladů, že to jde, už bylo docela dost.
Komunitní opensource je stále založen především na důvěře. Pokud někdo přispívá a alespoň trochu to dává smysl, nikdo moc nezkoumá, co umí nebo dokonce jaké má úmysly. Komunitního opensource softwaru je pořád daleko víc, než kolik zvládnou lidé, kteří ho dělají, kvalitně obsloužit.
Podobných varování bylo už několik. Namátkou třeba vývojář Debianu, který chtěl vylepšit OpenSSL a místo toho způsobil to, že se generovaly slabé klíče. Pokud vím, nikdo to nepovažoval za úmysl, prostě se jen pustil do něčeho, čemu dobře nerozuměl. Nebo to byl případ odstranění knihovny left-pad z npm registry, které sice bylo úmyslné, ale úmyslem nebylo rozbít půlku internetu.
Dalo se celkem očekávat, že když k takovýmto chybám dochází omylem, může někdo zkusit udělat něco takového i úmyslně.
Po chybách v OpenSSL se vybralo pár nejdůležitějších projektů, které jsou pro internet klíčové ale nebyly z hlediska správy v dobrém stavu. Vznikla Core Infrastructure Initiative. Jenže projektů, na kterých opensource svět závisí a skrze které je možné zaútočit je řádově více. XZ je jenom jedním z moha – každý si přece řekne, že je to jen jedna z kompresních knihoven, kdyby s ní byl nějaký problém, můžeme si zvolit některou z jiných knihoven. Ano, můžeme – ale reálně se ta knihovna XZ používá ve spoustě případů a je možné skrze ní napadnout skoro kterýkoli systém – i takové systémy, které ji nepoužívají.
Přitom ta knihovna reálně závisí na jednom jediném člověku. Lasse Collin mohl nějaký kód přijmout nebo odmítnout, mohl přizvat nebo odmítnout dalšího správce, mohl mu správcovství předat. Já jsem přesvědčen, že Lasse Collin neudělal žádnou chybu, neměl důvod JiaT75 nějak více prověřovat. Ale ono je to vedlejší – i kdyby chybu udělal, problém je v tom, že to celé záviselo na jediném člověku a po něm už nebyla prakticky žádná kontrola. Za prvé nemůžeme po vývojáři spravedlivě chtít, aby rozpoznal léčku pravděpodobně nějaké tajné služby. Správci opensource jsou vývojáři, ne špioni.
Za druhé to celé posouváme jen o člověka dál. Co kdyby se tajným službám podařilo naverbovat přímo Lasse Collina? Třeba by mu dost zaplatili. Nebo co kdyby se s ním prostě něco stalo a on přešel k temné straně síly? Co kdyby byl Lasse Collin od začátku nastrčený?
Fungování projektu XZ ovšem není výjimkou, když to budeme brát na počet projektů, bude to spíš pravidlem. A jak je vidět, zneužít se dá i nějaký menší projekt, o kterém si po většinu doby ani neuvědomujeme, že ho používáme.
Řešením ale není něco měnit přímo na těch opensource projektech – že by se o ně staralo více lidí. To je absolutně nereálné.
Spousta lidí si myslí, že opensource je bezpečný proto, že v něm může hledat chyby kdokoli. Problém je v tom slovíčku může – ano, opravdu může, ale prakticky nikdo to nedělá, takže z tohoto důvodu je to stejné, jako by nemohl. Tj. aby se situace zlepšila, je potřeba, aby se ty problémy opravdu hledaly – pravděpodobně ne ručně, na to nejsou kapacity, ale automaticky. Nálezy aby pak hodnotili lidé mimo ty projekty a teprve to, co vyhodnotí jako problém, šlo ke správcům konkrétního projektu, včetně popisu, jak problém zreplikovat. (Postup „náš uzavřený nástroj, který vám nedáme k dispozici, našel těchto 150 potenciálních chyb, prohrabte se tím a třeba něco najdete“ je k ničemu.)
V případu XZ vidím jednu chybu, která měl rozeznít alarm, ale kterou by bylo triviální obejít – přidání souboru, který je v repository, do .gitignore. To ukazuje na chybu, ale zároveň to nejde použít jako spolehlivý signál útoku, protože pro útočníka by bylo snadné to obejít. (Spíš to ukazuje na to, že na technickém poli útočníci nebyli zas až tak dobří – pořád z toho plyne, že byli mnohem lepší zpravodajci než programátoři.)
Pak je tam jedna systémová chyba, která by se měla napravit, i když to bude obtížné. Ta chyba spočívá v tom, že různé nástroje na kontrolu kvality kódu mají možnost selektivně vypínat některé kontroly, když hlásí planý poplach. To vypnutí ovšem vypíná danou kontrolu úplně, není svázáno s původní chybou. Takže stačilo nejprve podstrčit legitimní kód, kvůli kterému bylo nutné vypnout nějakou kontrolu, a pak už se ten kód dá nahradit čímkoli jiným a ta kontrola zůstane pořád vypnutá. Ideální by bylo, aby se neuvádělo jen „vypínám kontrolu“, ale „vypínám kontrolu, protože X“ – a když přestane platit X, přestalo platit i vypnutí kontroly. Nebo se to dá obejít alespoň tak, že při změně kódu, u kterého je vypnutá kontrola, se ta kontrola musí zase zapnout – a teprve pokud znova neprojde, musel by ji někdo znova vědomě vypnout. To by se dalo hlídat automaticky.
Nejdůležitější je ale zefektivnit a zkvalitnit hledání (bezpečnostních) chyb. Místo sypání co největšího množství CVE na jednu hromadu investovat do jejich rozlišování, místo soutěží o odhalování zero-day zranitelností, které tvoří špičku ledovce, se věnovat té mase, která je pod hladinou.
Nebo to byl případ odstranění knihovny left-pad z npm registry, které sice bylo úmyslné, ale úmyslem nebylo rozbít půlku internetu.
Tohle podle mě ukazuje na mnohem závažnější problém - chybějící standardní knihovny a standardní funkce. Pokud i takovou blbost jako formátování stringu někdo tahá z náhodného místa na internetu, tak to znamená, že je něco prohnilého v samotné infrastruktuře.
Tohle mě neskutečně štve na vlastně všech moderních jazycích a nástrojích. Všechny (Go, Rust, Python, PHP, Ansible, ....) v podstatě doporučují tahat knihovny z náhodných míst na internetu, je to v každém tutoriálu apod.
Jenže jde o míru. Pokud každý musí tahat formátování stringů z náhodného místa na internetu, tak se jednoho dne buď omylem nebo schválně stane ta knihovna bezpečnostní hrozbou. Bude to velké lákadlo, protože tu knihovnu budou používat v podstatě všechny programy.
To, že nějakou vysoce specializovanou funkci nenajdu ve standardní knihovně ničemu nevadí. Protože ji použiju pouze do jednoho programu z tisíce a ten se používá pouze jednou za deset let. Ano, stále to někdo může využít k devastaci jaderného průmyslu nějaké země. Ale ne třeba ke sledování miliard lidí.
Tohle ale nemá řešení na začátku. Jednak pro to, že při té flexibilitě nikdo neví, kterým směrem se ten nástroj bude ubírat a co tudíž patří do standardní knihovny. Jednak pro to, že kdyby se Ryan Dahl před vydáním Node.js na dva roky někam zavřel a psal standardní knihovnu, nejspíš mezi tím vznikne něco jiného a budeme používat to a ne Node.js. Ryan to pak „napravil“ vydáním Deno, které má standardní knihovnu mnohem lepší. A startPad se nakonec dostalo i do standardu JavaScriptu, čímž se asi stal jedním z mála jazyků (vedle Pythonu), které to mají ve standardní knihovně.
Možná se to změní s AI, že pro jednořádkové funkce jako left-pad nebudeme stahovat náhodné knihovny z internetu, ale necháme si je náhodně vygenerovat AI…
No - open source (Linux...) není bezpečný, ale má tu výhodu, že když se na takovouhle chybu přijde (a ono se přijde), relativně snadno a transparentně ji lze napravit.
Pokud se něco takového přihodí v closed source projektu (Windows...), dost pravděpodobně se to hlavně ututlá. Ty projekty prostě vypadají bezpečnější, protože část těch chyb se nikdy na veřejnost nedostane - ať opravených, nebo neopravených.
Já nezpochybňuju, že je to výhoda. Jenom to není tak velká výhoda, jak si mnozí myslí – protože „může zkoumat každý“ ani zdaleka neznamená „aspoň někdo se na to určitě podívá“.
Naštěstí si to pravděpodobně myslí i útočníci, protože útoků tohoto typu je překvapivě málo na to, jak snadné podle mne jsou. Ne že by to byla úplná brnkačka, tak zlehčovat bych to nechtěl – ale kódu, který kromě autora vidí jen jedny další oči a dívají se na to způsobem „to je fajn, že také přispěl někdo jiný“ (takže v tom nehledají nějaký úskok) je podle mne spousta.
To co ti připadá neuvěřitelné je prostě jenom sociální manipulativní tlak. Mimochodem i zde na rootu se to v diskuzích tu a tam dělo a děje. Označoval jsem ty profily jako "noname nick" bez historie, a vždy se objevily když potřebovali ovlivňovat veřejné mínění na fórech či mediálních portálech ( viz. éra diskuzí např. k eet, blokování nelegálního hazardu nebo posledně invaze Ruska na Ukrajinu či cenzura webu). Spoléhají na to, že určité procento se bojí jít proti "proudu", nechtějí jít do konfliktů(např. kvůli lenosti, pohodlnosti, nebo jsou prostě nekonfliktní) a taky že někteří lidé si řeknou "dobře ať je po jeho ať už máme klid", apod.. Bude to znít jako "klíše" ale určitá míra "tvrdohlavosti, neústupnosti a zásadovosti" je velmi dobrou obranou proti těmto sociálním manipulativním attackům .
[technomaniak]
Dava to smysl, a asi mas pravdu, asi Collina (a ostatni) soudim prilis tvrde. Ale presto porad se nemuzu zbavit toho pocity "neuveritelna", ze jim nekdo na tak pruhlednou hru skoci. Zvlast programatori, od nichz by clovek ocekaval trochu logickeho uvazovani.
Nevim, jak jsem psal: asi mas pravdu, ale me to hlava nebere....
Ad stable/unstable - to že byl tenhle backdoor objeven zrovna ve chvíli, kdy byl v unstable a ještě ne ve stable ještě neznamená, že se takhle chytí všechny. To nikdo neví jistě. Nakonec tohle bude mít zřejmě dohru, i ve stable #1068024. Viz zápisek Joey Hess...
Ale ano, s unstable Debianem to riziko asi bude vyšší. Otázka je jak moc. S důvěrou v opensource se bude muset začít nějak vážněji pracovat.
[Žito]
"S důvěrou v opensource se bude muset začít nějak vážněji pracovat."
Hele, ja bych byl v tomhle ohledu dost opatrny. Chapu, ze jsou vsichni vystraseni - ja taky - ale osobne nevim o zadnem dalsim srovnatelnem pripadu. Podle me ted spoustu lidi nedela nic jineho nez ze to cele analyzuji a zjistuji krok po kroku jak presne k utoku doslo, co a kdo vsechno selhalo, a zda existovali nejake varovne signaly, ze se neoco takoveho deje.
Osobne bych si na nejake dalsi kroky pockal hlavne az trochu opadnou emoce, protoze takhle se nadela spis vic skod nez uzitku.
Tu ocitovanou větu jsem myslel obecně. Zrovna Debian dělá prakticky maximum možného, ale zdá se mi, že se objevují velké rezervy v souvisloti s balením větších celků software. Ať už se jedná o formáty aplikací, kterým se vyhýbám, protože už nějak vnitřně z toho mám blbý pocit - appimage apod, nebo kontejnerizaci, kdy se buildují různé docker image a vývojáři bez zábran šahají do nějakého hubu pro image, které se jim zrovna hodí. Teď jsem nucen konečně se trochu seznámit s Kubernetes, ale jak se to pomalu snažím vstřebat, tak u toho mám prostě takový vnitřní neklid. :-)
Já jsem tu větu myslel tak, že se na bezpečnost začne teď více hledět a vzniknout na to snad i nějaké nové procesy a automatizace. A je vidět, že jistý si člověk nemůže být ničím a je vhodné do produkčních systémů nasadit zábrany na vícero úrovních. Tak jako se začalo se SElinuxem, nebo AppArmor. Tak se prostě věci začnou snad více tlačit tímhle směrem. Na jednu stranu jsou cesty jak bezpečnost vylepšovat, ale stojí to energii, na druhou stranu to leckdo (zpravidla vývojáři) považuje za překážky, které jim brání v práci. Security moduly vypínají apod. Doufám, že se na to teď bude prostě klást větší důraz...
Asi tak jsem to myslel, ale rozhodně ne nějak znevěrohodňovat OS oproti komerčním softu, který na tom ve skutečnosti bude ještě hůře...
Tady je hezka timeline https://research.swtch.com/xz-timeline po precitani je docela pochopitelne, ako Kummar presadil "svoj nazor".
Dost desivy. Open source, asi ten kod videlo par lidi, proslo to testama a stejne tam byly zadni vratka... Aspon se clovek zamysli nad tema doporucenima jako pouzivat VPN ap.
Ten zásadní kód byl přidaný do nečitelného skriptu vygenerovaného autotools, který nikdo nečte. Payload byl v "testovacích datech", ale byl šifrovaný. Autoři se sice podle všeho chovali trochu jako slon v porcelánu (neotestovali si vliv změn na Valgrind nebo na fuzzery a hasili to až zpětně) ale prošlo jim to.
A pritom RSA_public_decrypt
je deprecated volani z openssl - i kdyz se stale pouziva. A jinymi slovy ta funkce neni specificka jen pro ssh - uskodit by to teoreticky mohlo i jinde (byt z dostupnych informaci se jevi, ze cilem bylo jen to ssh), staci tehoz presmerovani docilit v cemkoliv zavislem na openssl...
Pro informaci, ta celá hromada extra knihoven se linkuje pouze kvůli tomuhle:
https://github.com/bb4242/sdnotify/blob/master/sdnotify/__init__.py
> Veřejné síťové služby, které by měli používat pouze známí uživatelé (jako OpenSSH, IMAP server v malých firmách atd.), by měly být provozovány za VPN.
Jako jo a ne. Takže příště bude backdoor ve VPN serveru? :) Ale ano, bude lepší vystrkovat jen jednu VPN než všechno po částech.
> Na pracovních stanicích používejte OpenSnitch (pouze v Linuxu).
Já to zkoušel, ale bylo to dost peklo nastavit a stejně to pak nefungovalo na věci jako "aplikace si forkla wget".
30. 3. 2024, 23:32 editováno autorem komentáře
Já s tou VPN mám taky problém. Když se jako admin potřebuju připojit ke 30 serverům, mám si spustit 30 VPN? Chvíli jsem pracoval v týmu, kde přesně tahle politika byla (vše za VPN) a efektivita práce byla nulová, protože se neustále nahazovaly a shazovali VPN tunely.
Celkem chápu, odkud se tenhle nápad mohl zrodit a i tady na rootu byly zprávičky o tom, že někdo vykradl tu či onu DB, která byla volně přístupná a bez zabezpečení. Jenže odpověď na tohle není "dejte tam VPN". Odpověď na tohle je "zabezpečte si tu DB a pokud to není nutné, tak ji nepouštějte na internet".
Typickej devel s jednoduchym vnimanim sveta outsourcovane infrastruktury.
Uz jsi videl pytel nebo slozku s kapsickami ve ktery mas ruzny tokeny, otp appky, specialni cisla, kalkulacky atd? Co firma to jiny system vpn. Casto binarni blob nebo pod tom i sesna na rdp aby videli co presne delas.
A samozrejme co firma to jiny politiky. A kazda firma jeste pouziva ruzne systemy na config management.
Pouze na vybrane zakose je mozno mit admin backdoor vpn nebo dostat se pres agenty. Vetsinou nejake startupy kde se bezpecnost a audit logy moc neresi.
1. 5. 2024, 19:44 editováno autorem komentáře
Ale to si tak predsa mozete nastavit ze sa dostanete do 'svojej' siete alebo na 'svoj' pocitac cez VPN a odtial uz mozete ist cez 'permanentne' VPNky kam potrebujete.
A jak vám tohle funguje? Tohle jsme řešili někdy kolem roku 2010. Navázané VPN v rámci vyhrazené firemní sítě a zaměstnanci se přihlašují do této sítě. Na papíře krásné.
V praxi je problém se vším. Už třeba jenom adresy. Někdy je na "druhé straně" 10.0.0.0/8. Takže pokud máte 50 firem, 10 z toho používá 10.0.0.0 a jedna pro jistotu rovnou /8, tak jste víte kde. Takto stačí klidně 10 firem a máte vyčerpané 10/8, 192.168/16 a 172.16/12. Do toho pochopitelně ještě doma máte typicky něco z toho. A tento problém jsem já zrovna neměl, protože doma jsem měl veřejky (mám dodnes).
A to se vůbec nebavím o technologiích. Někdo OpenVPN, někdo L2TP, někdo Cisco krabičky (takže ve své serverovně máte 15 cisco krabiček pro 15 vzdálených bodů) a tak dále.
O IPv6 a povinném IPSec nikdo nechtěl slyšet.
Takže: na papíře prostě super
Ano bud musite medzi-firemne koordinovat address spaces, alebo pouzit ipv6 (co je podla mna celkom dobre a staci na prepoj nieco dnuka, vid. nizssie).
Potom este pomaha mat bouncer S2S, v DC, ktory translatuje address spaces jednotlivych klientov.
Po case zistite, ze je velmi dobre mat u klienta bouncer/bastion, za vpn samozrejme, kde vam bezi nejaky, ako to ja volam "persistent holder": screen (lol), alebo skor nieco pre dospleych, ako tmux.
Napr. tmux autor siel a specificky pridal podporu direkt servera, takze si tam mozte naspinovat "holder daemony" per user.
Ono zistite, ze mat takto nieco co vam drzi spojenia in-infra je extremne pohodlne. Pad VPN je potom len reconnect. Pripojite sa spat na tmux a mate svoju session v stave ako pred padom.
Napr ja si to automatizujem az na uroven window managera, kolegov to uz ale vtedy vypinalo, plus maju radi gnome. Cize ale ked mi spadne vpn a pripojim sa naspak, tak terminalove okna si pamtaju, ktora session bola kde.
Ale dnes uz robi vlny wiregurad, a medzi ludmi co maju tisice a stotisice strojov zacina byt popularny tailscale. Osobne som proti, lebo cloud (ale vraj mzote bezat aj vlastnu isntance gitlab style), ale dobry koncept, kuknite.
Technicky je velmi zajímavý ten postup, jak se jim to tam povedlo dostat, včetně opětovného důkazu, že nejsnazší cesta je přes sociální inženýrství a faktor lidské chyby. Ovšem obzvlášť zvědavý bych byl na to, kdo si tohle zaplatil. Je to zjevně věc velmi dlouho připravovaná, čili bych čekal, že to nejspíš platila nějaká zpravodajská služba. A teď by mě fakt zajímalo, která velmoc na tom měla takový zájem. Bylo by taky hezké, kdyby se FOSS komunita na tomto případě naučila, že přílišné rozdrobování sil (u Linuxu např. reprezentované nesmyslným množstvím distribucí) jen snižuje kvalitu výsledného produktu a že důkladný auditing je dneska prostě nezbytnost a že samotná dostupnost zdrojáků zdaleka není zárukou kvality/spolehlivosti.
...kdyby se FOSS komunita na tomto případě naučila, že přílišné rozdrobování sil (u Linuxu např. reprezentované nesmyslným množstvím distribucí) jen snižuje kvalitu výsledného produktu...
Mantra o "nesmyslným množstvím distribucí" se opět vynořila.
Významnou část těch lidí, kteří (F)OSS dělají ji dělají právě pro to, že mohou tvořit po svém. Z toho úhlu pohledu to není štěpení sil.
Navíc tenhle případ vůbec není o tom, jestli je distribucí moc nebo málo.
Bezpečnostní audit a mnohá další bezpečnostní opatření jsou samozřejmě potřeba, ať už je distribuce jedna nebo jich je 1000.
Naopak s tímto a dalšími bezpečnostními incidenty se otvírá další prostor, aby přibily distribuce, které se budou více zaměřovat na bezpečnost a z jejich přístupu a výsledků mohou těžit ti ostatní.
A na těch, kteří to používají je, aby si zvolili, i podle míry bezpečnosti, kterou nabízí.
PS: A 100% bezpečné, nejspíš, nebude nikdy nic.
V tom poctu distribuci bych problem nevidel. Zrovna tady se navic pouzilo technika, co sice neni soucasti upstreamu, ale vetsina distribuci ji nejak prebira. Zaplatpambu se na to prislo driv, nez to probublalo do produkcnich systemu.
Ale samotne zamereni se na bezpecnost krom jineho znamena zpomaleni znacne vyvoje - a tim spoustu lidi proste nenadchnete. Ono audity kodu nejaky cas proste zaberou, pokud to nema byt jen formalita - ale skutecny bezpecnostni audit, kdy resite i souvislosti. Realne se to moc nedeje ani u backportu do "LTS" kernelu a to ani po funkcni strance - kdy GKH obcas aktivne protahne neco - a nekdy tim cherry-pickingem i neco rozbije (takze nasleduje nove vydani s reverty, ze?).
Nebyly by místo dehonestujících nálepek jako "mantra" raději nějaké validní argumenty? Není to mantra, je to prokazatelná situace, která se dá velmi snadno doložit životním cyklem řady distribucí, které vznikají a zanikají s jediným správcem, či se neliší nijak funkčně, pouze předvýběrem balíčků, takže ke "změně distribuce" dochází pouhým odinstalováním jednoho desktopového prostředí a nainstalováním jiného.
Ano, je pravda, že část lidí do projektů přispívá proto, že mají příležitost dělat něco jinak a po svém. Nikomu neberu právo forknout si z GIMPu svůj vlastní Glimpse čistě kvůli změně jména (a možná i UI?), pouze poukazuji na to, že takový projekt měl životnost 2 roky a veškerá odvedená práce se proměnila ve zcela promarněný čas (změna loga/designu apod. je kosmetická zbytečnost a o reálných funkčních změnách, které by se zpětně objevily aspoň v GIMPu, jsem neslyšel).
Pokud jste četl článek a porozuměl postupu, jak k infiltraci došlo, nemohlo vám uniknout, že klíčovou částí v postupu bylo přinucení unaveného správce projektu přidat dalšího (neznámého a neprověřeného) člověka mezi správce a následné ustoupení původního správce z projektu. Je tedy zcela zjevné, že nedostatek prověřených vývojářů (na který má vliv mj. štěpení sil) byla jedna z hlavních příčin vzniku problému.
Nápad se vznikem distribucí zaměřených na bezpečnost je opravdu úsměvný. Už se těším, až budu někomu vysvětlovat, že základní rozdíl mezi distribucí A a B je v tom, že A se dá velmi snadno zavirovat a hesla v ní jsou jen formalita, zatímco B je "zaměřena na bezpečnost". Těm "nebezpečným distribucím" se říká developer preview a je sebevražda používat to jinak než v testovacím prostředí.
P.S.: Kde v původním příspěvku jsem předpokládal nějakou 100% bezpečnost?
Ten článek od Solène Rapenne je skvělý v tom, že si u každého toho bodu stačí říkat "a ono to tak není?"
Někde vedle u zprávičky se diskutuje nárůst komplexity. Roky jsem si říkal, proč obyč programy tahají někdy i stovky, průměrně desítky, knihoven. Poznal jsem to v roce 2015, kdy jsem přešel na FreeBSD a všechny porty si začal kompilovat. Některé programy mají desítky volitelných funkcí. By default je vše zapnuto. Kompiluje se to hodiny. Pokud si admin dá tu práci a vyzobe si skutečně jen to, co potřebuje, je kompilace na pět minut. Aktuálně celé distro mám zkompilované do dvou hodin (na staré i5).
Proč to píšu. Bývávalo standardem, že na každou další funkcionalitu je další program. Tedy je kravina mít jeden program s padesáti volitelnými (konfigurační volbou při kompilaci) funkcemi. Správně to má být padesát oddělených programů. A admin si nainstaluje pouze ty tři, které potřebuje.
Další věc, co se řešila i tady na rootu (tak před 15 lety) jsou funkce, které vlastně nikdo nechce, ale z hlediska nějakého "standardu" distribuce tam prostě jsou. Příkladem budiž třeba true
. Což je program, který vrací exit code 0. Toť vše. Jenže, teoreticky, může skončit chybou. Chyba je v angličtině. Což se, ehm, Čechovi, nemusí líbit. Takže true
linkuje knihovnu pro překlad do všech jazyků v galaxii. Velikost tohoto programu narostla možná tisíckrát, ale to není ten hlavní problém. Problém je, že všechny skripty (i běžící pod rootem) náhle inkludují tuhle "nevinnou" knihovnu. Takže někde na počátku byla myšlenka mít vše v národních jazycích (což prostě nechápu, ale ok) a tak se do všech skriptů zatáhla knihovna, která tam ale neplní vůbec žádnou primární funkcionalitu.
To je cela stara gamerga... oh sorry systemd debata. Kukajme co je tu pouzite ako bouncing vektor, zmurk zmurk.
Problem su "deti", ako ich ja volam. My sme uz stari a deti je vela a su cool. Bezia cloud a elastic scaling. Cez putty na windowse. Pripadne bezia ferdo-ru, sid, arch. Maju macos, windows envy. Vacsina adminov, ktorych dnes stretavam, ma polku mojho veku. Ja som sa ucil od ludi co maju dnes 60-70. To su ti pravi zverrori.
Dnes je spolocnost a secko tak doondate, ze sa v tom stratil unix spirit. Je tu stale, len sa ho treba extra ucit. A je to "zbytocne". Vacsina ludi uz od 90 rokov nechape unixu, uistujem vas.
Potom je tu GNU-itida alebo skor glibcitida, typickymi pacientami su systemd a dbus. Alebo core-utils (to je odpoved na vase flagy a features).
Co vam potom ostava? Bsdcka (aj tie pojdu za chvilu cestou lemikov), alpine, hocico musl based? Je pat a pol distra co maju alt-inity. Presvecte klienta na take daco.
Priznajme si dnes, ze aj tak vacsina ludi pod 30 a daktori aj nad 30 bachaju otazky rovno do chatgpt alebo copilota dnes. Buducnost bude glorious.
Ja len dufam, ze tie AI pojdu dopredu rychlejsie ako kolektivna degeneracia ludskej rasy, a preberu tieto tasky, skor nez sa to cele zosype.
Ono to skor aj tak konci tym, ze ohneme hlavu a ideme "spravnym" smerom s ostatnymi lemikmi.
Na gist stránce, která se snaží shromažďovat relevantní informace, je velký update se spoustou nových informací. https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
31. 3. 2024, 10:00 editováno autorem komentáře