Root jogokhoz juttathatja a támadót a regreSSHion OpenSSH szerver sérülékenység

Bug
  • an Unauthenticated Remote Code Execution (RCE) vulnerability in OpenSSH’s server (sshd) on glibc-based Linux systems
  • CVE-2024-6387
  • grants full root access
  • marks the first OpenSSH vulnerability in nearly two decades—an unauthenticated RCE that grants full root access
  • it affects the default configuration and does not require user interaction
  • this regression was introduced in October 2020 (OpenSSH 8.5p1)
  • over 14 million potentially vulnerable OpenSSH server instances exposed to the Internet

Részletek itt és itt.

( trey | 2024. 07. 01., h – 19:42 )

Szerkesztve: 2024. 07. 01., h – 19:47

OpenBSD systems are unaffected by this bug, as OpenBSD developed a secure mechanism in 2001 that prevents this vulnerability.

🤷‍♂️

trey @ gépház

( arpi_esp v | 2024. 07. 01., h – 20:49 )

meg jo hogy az elozo libxz/libsystemd benazasnal attertem masra.

( n.balazs v | 2024. 07. 01., h – 22:01 )

Minő érdekesség, hogy ez pont ma került napvilágra. Pont tegnap járt le a Centos 7 támogatási ideje.

Szerencsére Centos 7 SSH nem érintett (OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017). Ettől még migrálnom kell most júliusban.

Igaz, hogy ez offtopic, de válaszolok szívesen.

1. Ugye Centos 7 EOL / EOS. Valamit lépnem kell. Még akkor is, ha ezen a szerveren nincsenek más számára kritikus szolgáltatások, csak a saját cuccaim.

2. Ami a Linux disztribúcióknál folyik az utóbbi 5-10 évben, az felháborít engemet. Tragikus lázálom. Egy rossz vicc. Ennek tetőpontja a systemd-s (direkt kisbetűvel) marhulás. Rosszabb, mint a Windows registry. Szerencsére elég jól ismerem a Linuxokat, Windowst is, így van összehasonlítási alapom.
Lehet, hogy írok egy rövid blogbejegyzést, ott majd kifejtem.

hat a systemd-tol en is kivagyok, pedig az elejen meg kifejezetten tetszett, amikro meg csak init rendszer volt, es nem akart minden is lenni, mint most: dns, selinux, syslog, inetd stb.

most ugy vagyok vele, ha egy imap vagy webszerver kell akkor ubuntu lts es leszarom a systemd es tarsait, csinaljon amit akar felolem :)

ha meg tudni akarom mi tortenik a gepen, akkor slackware... mar nem annyira fapad mint regen, egesz hasznalhato.

Én ha tudni akarom, mi történik a gépen, akkor megismerkedek azzal a technológiával, azokkal a dolgokkal, amerre megy a világ...

Ja, Ubuntu LTS-en is systemd van - igaz nem kevés olyan csomagot láttam, ahol gyakorlatilag csak annyi van, hogy a régi sysvinit-es scriptet (konfigok begyűjtésével/ellenőrzésével, defaultok beállításával, ingyombingyommal mindennel _is_ foglalkozik) hívja meg, nagy igényességében...

( zsolt | 2024. 07. 01., h – 22:17 )

Néhány fontos infó:

How can users identify exploitation attempts of this vulnerability?

Exploitation attempts for this vulnerability can be identified by seeing many many lines of “Timeout before authentication” in the logs.

 

Are there any mitigations for this vulnerability?

If sshd can’t be updated or recompiled, set LoginGraceTime to 0 in the config file. This exposes sshd to a denial of service by using up all MaxStartups connections, but it prevents the remote code execution risk.

 

Gondolom, utóbbi után csak kulccsal lehet belépni.

Ha a LoginGraceTime 0, akkor nem csak kulccsal lehet belépni, épp ellenkezőleg, 0 = no limit, tehát akármeddig nyitva maradhat az unauthenticated ssh session. Ha meg a MaxStartup-ot eléri, akkor amellett se kulcs, se jelszó, mert nem forkol új processzt.. szóval hotfixnek jó, de bármelyik vicces gyerek aki pl. épp ezt az exploitot próbálja kihasználni, lefogja előled a max processz számot, és nem tudsz belépni. Szóval ez azért erősen rövidtávra ajánlott csak :S

( XMI | 2024. 07. 02., k – 00:20 )

Lényeges további részletek (NevemTeve által linkelt elemzésből):

- Legkedvezőbb tesztelt körülmények között átlagosan 6-8 óra folyamatos próbálkozás kell a sikeres támadáshoz

- Ez 32biten van így, x86-64-re jelenleg nincs működő PoC. Nincs elvi akadálya, hogy legyen, csak nem volt még elég idő kidolgozni. Várhatóan 64 biten tovább fog tartani a nagyobb ASLR keresési tér miatt.

- Ubuntu 24.04-en egy - egyébként biztonsági szempontból általánosságban ellenjavallt - módosítás miatt a hiba nem kihasználható. Ez egy teljesen véletlenül kiadódott szituáció, ami ráadásul - wait for it - egy systemd integrációs patch miatt alakult így. Mivel a rexec_flag le lett tiltva, az sshd gyerekfolyamatok ASLR-je nincs újrarandomizálva, ezért a támadó által kiprovokált signal handlerben levő syslog() hívás éppen úgy adódik, hogy nem az első futás lesz, emiatt a malloc()-ot már nem hívja újra.

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

( bennyh | 2024. 07. 02., k – 06:00 )

Minek is a a sok sz@r bloat, mint a Rust... :)

Ezt majdnem beírtam én is.

Aztán majdnem meg +1-eztem.

Aztán elgondolkodtam rajta :)

A rust (amíg safe-en belül maradsz) a memória-biztosságot garantálja, versenyhelyzetek esetén is. Ezen felül ad bizonyos garanciát a "data race"-ek (konkurens írás-olvasás vagy írás-írás) ellen. Ez nem 100%-os, mutable referenciákkal kijátszható. Nyilván általános, külső-eredetű események közötti versenyhelyzetekre a rust sem garantál semmit.

Itt nagyon az implementációs részleteken múlik, hogy ezt a hibát a rust alapból kivédte-e volna vagy sem. A leírás alapján (https://www.openwall.com/lists/oss-security/2024/07/01/3) nekem az jött le, hogy a glibc-ben levő függvények által, belül hívott malloc()-ok között kellett a versenyhelyzetet előidézni, hogy a támadás sikerüljön. Ha ezeket teljesen rust-ban teljesen safe függvényekkel oldanák meg, akkor igen, védett volna (a memória-allokáció teljesen versenyhelyzet-biztos). De mondjuk egy syslog() vagy hasonló hívásnál valahol kell lennie legbelül egy unsafe résznek, mert a külvilággal kommunikál. Ha ezt a részt meg lehet oldani hogy memóriát ne allokáljon akkor még mindig jók vagyunk.

Én most arra hajlok, hogy ez ellen konkrétan védett volna a rust. Ez nyilván nem minden versenyhelyzetből adódó biztonsági hibára igaz.

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

Mert

- már az egyszem OpenSSH-t se fogja senki újraírni Rustban (de ha véletlenül igen, akkor is még kb 8-10 év, mire eljut a jelenlegi funkcionalitásának a 70%-hoz, ráadásul rohadtul nem lesz annyira átnézve, mint a régi)

- meg az általa használt összes függvénykönyvtárat se (de ha igen, az nem 8-10, hanem 30-40 év

- és akkor bizton számíthatunk rá, hogy de, valamelyik programozó trehány lesz a fentieket lekódolók közül.

 

No most nekem erre már nincs 30-40 évem.

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

Teljesen félrement a dolog. Az eredeti felvetés úgy hangzott, hogy

"Én most arra hajlok, hogy ez ellen konkrétan védett volna a rust."

Nekem az "arra hajtok" azt sugallja, hogy 100%-ban még akkor sem biztos a hozzászólás írója, hogy valóban védene a Rustban írt ssh.

Én viszont erre reagáltam, hogy ez X, Y és Z feltételek esetén igaz csak, viszont ezek a feltételek olyannyira drágák fejlesztésben (*) , hogy sokára lehetne ebből valami.

Ezt akarta jelezni az "ennyit nem ér" - nem azt, hogy bárhol bele tudnék ebbe folyni (elvben tudnék, gyakorlatban nem fogok).

(*) szerintem a legdrágább a nem trehány fejlesztő(k) - mindegyik, aki ezzel kapcsolatba kerül; ezt követi a librust, és csak a sor végén kullog magának az ssh-nak a reimplementálása.

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

20 ev utan talaltak ismet egy ilyen bugot, amikor a rust meg sehol se volt. Orulnek ha minden networkre kitett program tudna ezt, es nem ott tartananak hogy a get parameterben atadott stringet egy az egyben atadja egy system hivasnak meg tarsai.

I hate myself, because I'm not open-source.

Az OpenSSH nem Rust-ban van. Vannak persze sérülékenységek, ami ellen a Rustban írás véd, de az sem csodafegyver. Azért, mert valami Rust-ban van írva, nem lesz mindjárt sebezhetetlen.

Az OpenSSH csapata azonnal foltozta, és Arch még 1-én ki is jött az új verzió, még 24 óra sem telt el a publikálás óta. Így kell ezt. Mondjuk nálam alapból nem fut az sshd, de az openssh fent van más csomagok függőségeként.

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

( trey | 2024. 07. 02., k – 10:54 )

Mai MOTD az Ubuntu Software Updater-ében:

OpenSSH CVE-2024-6387 has been fixed for 22.04 LTS, 23.10 and 24.04 LTS.
RegreSSHion: Possible RCE Due To A Race Condition In Signal Handling.
For more details see: https://ubuntu.com/security/notices/USN-6859-1.

trey @ gépház

( Dwokfur v | 2024. 07. 03., sze – 13:43 )

Annyi, hogy a most a logokban sshd helyett sshd-session kezdettel jelennek meg az authentikációs problémák. Ezért a fail2ban szűrőn változtatnom kellett.

"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."

Persze, lehet cifrázni, egyéni preferencia.

Pl. a HUP ssh portjára sem lehet az egész világból csatlakozni. Miért is kéne? Fel van véve ahonnan lehet, oszt' csókolom.

Bebaszna, ha még az ilyen próbálkozások miatt is aggódni kéne ...
 

trey @ gépház

en azt talaltam ki erre - bar meg nem implementaltam - hogy ha uj ip-rol kene belepni, akkor egy egyszeru minimal webserver (pl. py tornado) beker egy kulon jelszot vagy inkabb TOTP kodot, es ha jo akkor 1 percre megnyitja az ssh portjat arrol az ip-rol ahonnan a kliens jott. ipset-el egyszeruen megoldhato, es nem is kell default 80/443 porton logjon, lehet barhol.

( trey | 2024. 07. 03., sze – 17:19 )

Na, az imént megjött a "Nemzeti CSIRT incidenskezelés"-től is a figyelmeztető :)

A Nemzeti Kibervédelmi Intézet tájékoztatót ad ki glibc alapú Linux rendszereket érintő, OpenSSH (regreSSHion) sérülékenységgel kapcsolatban, annak súlyossága és kihasználhatósága miatt.

A dokumentum az alábbi hivatkozáson keresztül érhető el:

https://nki.gov.hu/figyelmeztetesek/tajekoztatas/tajekoztatas-az-openssh-regresshion-serulekenysegerol/

trey @ gépház