Bakdörr i xz/liblzma resulterade i bakdörr i sshd

Huj, tack för headsup, blir att uppdatera ett par maskiner när man kommer hem!

Bra att du lyfter detta @blunden
Själv fick jag lite minnen ifrån när man rattade OpenBSD i början på 2000-talet och SSHD innehöll en "remote exploit", så jag har gått igenom systemen jag har hand om. Och jag tror inte jag varit drabbad, men ska ta en extra koll under dagen.
Frågan är om det ens är värt att tipsa Sweclockers-redaktionen om detta eller om det bara är bumpade artiklar och quiz som gäller.

Vad jag minns är processen som forkas för inloggning normalt sandboxad och laddar inget externt före autentisering, av just såna här anledningar. Är det det som linuxfolket patchat sig runt, eller när görs ropet till systemd och varför?

Jag har tänkt samma tanke, men valde att inte tipsa. Det är en Linux-nyhet och jag ser inte hur den passar in i det nuvarande flödet när jag kollade. Som du säger, mycket trivialt material nuförtiden. Denna sårbarhet kunde slunkit in i vartenda system som kör Linux eller BSD; som routrar, smartswitchar, telefoner och stora servrar (Tieto et.al.). Idag var den riktad mot sshd på systemd-system, men vem vet hur det sett ut imorgon, när grunden blivit lagd överallt. Små obskyra ändringar i XZ kunde breddat attackvektorn väsentligt i framtiden.

Tolkar det som att ett extra steg görs före nyckelverifieringen, alltså före loginsekvensen. Om nyckeln passar i hackerlåset så avkodas lasten som skickas till system(). Om nyckeln inte passar så fortsätter koden enligt den vanliga kodvägen (som förmodligen skapar sandboxen). Det låter enkelt, men allt har gömts i flera lager och det finns ingen möjlighet att skanna systemet från nätverket för att se om sårbarheten finns. Bland annat så byts två funktioner kopplade till IFUNC ut.

Den här användaren "Jia Tan (JiaT75)" har gjort 750 ändringar i XZ-koden under de här två åren. Diskussionen nu är om man helt enkelt ska backa allt, eller gå igenom och verifiera varje förändring han gjort. Det är lite olyckligt då xz behöver få in en del nyare modernare funktioner som nyttjar dagens system bättre. Man kan sammanfatta det som att xz kan tappa två års utveckling från att redan tidigare ha varit i bakvattnet.

Branchen har reagerat unisont och snabbt; i princip allt som den här personen (och flera runt omkring) rört vid har effektivt tagits ned och backats till kända marker. Bl.a. så blev även den tidigare administratören av XZ helt avstängd när utredningen tog fart.

Detta var vad upptäckaren såg; ett ypperligt sinne för detaljer. Med sitt ansvar för sina system så vägrade han att släppa in den nya utgåvan på sina produktionssystem innan han förstod vad denna halva sekund berodde på.

# time ssh nonexistant@...alhost

before:  nonexistant@...alhost: Permission denied (publickey).
real	0m0.299s    user	0m0.202s    sys	0m0.006s

after: nonexistant@...alhost: Permission denied (publickey).
real	0m0.807s    user	0m0.202s    sys	0m0.006s

openssh does not directly use liblzma. However debian and several other
distributions patch openssh to support systemd notification, and libsystemd
does depend on lzma.

Det var mer den biten jag undrade över, vilket syfte fyller det att lägga till den här funktionaliteten till sshd, i vilket stadie av inloggningen och med vilka privilegier görs anropen?

Och, vilka fler program har man potentiellt saboterat på det här sättet, för att de ska stödja systemd-notify?

Den här bakdörren är endast åtkomlig om man har ssh öppet ut mot internet?

Jag bygger mina system med "-systemd" och kör OpenRC istället, så har ingen kännedom om vilka "finesser" som systemd behöver/erbjuder. Det läskiga är att ingen funktionalitet har lagts till i SSHD, deras kod är sund och opåverkad. Bakdörren kommer in helt via xz-biblioteken (liblzma). Faktum är att attackvektorn kunde varit bredare redan idag, men man har infört en rad begränsningar när bakdörren skapas, förmodligen för att minimera upptäckt. (Man försöker bl.a. att inte aktivera bakdörren om koden körs i debug-läge!)

Även detta stycke kommer från första länken i denna tråd. (Ursäkta alla Linux-specifik jargong.)

Observed requirements for the exploit:
a) TERM environment variable is not set
b) argv[0] needs to be /usr/sbin/sshd
c) LD_DEBUG, LD_PROFILE are not set
d) LANG needs to be set
e) Some debugging environments, like rr, appear to be detected. Plain gdb
   appears to be detected in some situations, but not others

Det finns xz-kod i linux-kärnan också som aktiveras om man konfigurerar för det, men denna kod har de inte påverkat. Som brukligt i Linux så kan man själv välja mellan ett antal komprimeringsalgoritmer.

Detta hade verkligen varit en suverän nyhetsartikel.

Måste ändå säga är det är ett rätt imponerande arbete. Tur att de hittade det i tid iallafall.

Vilka system blir påverkade av detta? Det det de flesta distros eller bara specifika? Brandväggar som pfsense mm?

Arch 5.6.1-2 är en patchad version btw, så kör man arch kan man uppgradera till den. Oklart om bakdörren var aktiv i Arch dock.

Jag hoppas dock att alla program som använder xz byter till zstd eller så nu, xz bör inte tas i med tång.

Arch var inte drabbad eftersom de inte länkar sshd mot liblzma, och samma gäller även t.ex. Gentoo och OpenMandriva. De flesta distributioner på den listan är nog i själva verket inte drabbade. Men de rekommenderar förstås ändå att man uppgraderar för säkerhets skull.

Exploiten hänger på att man länkar mot libsystemd som i sin tur länkar mot liblzma. Läste just på hackaday att

och

Föreslår tjära, fjädrar och en särskilt dum strut till den som skrev den patchen.

Ja, det var det jag menade, det är bara vissa distributioner som patchar openssh för systemd-notify.

Lite väl long con för någon random med tanke på hur länge det pågått. Inte för att vara alltför konspiratorisk men känns lite som någon större gruppering eller (diktatur)statsgrupp ligger bakom.

Bra att det upptäckts och får hoppas man börjar granska mer kod nogrannare. Toppen av isberget.

Jisses... antingen har man rejäl horn i sidan till OSS och har psykopatiska drag för att ha uthållighet att under > 2 års tid manipulera koden och lirka med människorna som håller i detta att gå den vägen man tänkt sig eller så är man betald för den här typen av angrepp och det var dessutom välplanerat.

Den eller de som är bakom detta är förmodligen inte så glada att det avslöjats i förtid innan det är ute i det vilda en tid bland alla Linux-distrubitioner pga. misstag i koden som käkade CPU-resurser och av någon som är observant och undrade varför en cli-kommando tog en halvsekund längre än förväntat...

Detta är på nära samma nivå som NSA:s Dual_EC_DRBG hack i försök att kunna läsa av HTTPS: trafik i realtid, men förmodligen driven av en annan stor aktör.

Nu är jag ingen fan av Microsoft men det är hatten av för de som jobbar där och faktiskt hittat ganska intrikata och väldolda bakdörrar ett flertal gången den senaste åren

Nu uppmärksammad i DN
En ensam kodare kan ha stoppat gigantisk cyberattack

Poddar om det:
https://sakerhetspodcasten.se/posts/sakerhetspodcasten_259_xz...
https://kodsnack.se/578/