- A hozzászóláshoz be kell jelentkezni
Hozzászólások
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Pedig se glibc, se Linux nincs benne. A fene se érti :-(
- A hozzászóláshoz be kell jelentkezni
OpenBSD systems are unaffected by this bug, as OpenBSD developed a secure mechanism in 2001 that prevents this vulnerability.
🤷♂️
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
meg jo hogy az elozo libxz/libsystemd benazasnal attertem masra.
- A hozzászóláshoz be kell jelentkezni
Mire váltottál?
- A hozzászóláshoz be kell jelentkezni
dropbear, eleg minimalra forditva (sajat crypto libje, disable libz stb)
az openssh kulcsokat at kell konvertalni elotet vagy ujat generalni, de amugy muxik vele minden, es lenyegesen gyorsabb a belepes meglepo modon.
- A hozzászóláshoz be kell jelentkezni
libxz/libsystemd benazasnal
BSD-n van systemd?
- A hozzászóláshoz be kell jelentkezni
Még csak az kéne!
- A hozzászóláshoz be kell jelentkezni
Az egy sokadik evolúciós lépcső az init rendszerek sorában, több, nehezen kihagyható fejlődési fázissal :-P
- A hozzászóláshoz be kell jelentkezni
Akkor megnyugodtam, hisz a BSD-k már a SysV initig se jutottak el.
- A hozzászóláshoz be kell jelentkezni
Iiiigen, erre próbáltam célozni :-D :-D
- A hozzászóláshoz be kell jelentkezni
Szerencsére nincs. És nem is lesz. Remélhetőleg.
- A hozzászóláshoz be kell jelentkezni
🍿
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A FreeBSD 13.2-nek is tegnap járt le a supportja. Attól még kijött rá a javítás.
- A hozzászóláshoz be kell jelentkezni
Valahol ismerik az órát. Nem kellene patchelni a FreeBSD-s NTP-t? ;)
- A hozzászóláshoz be kell jelentkezni
Migrálással lehet várni decemberig. Oracle Linux 7 dec. 31-ig támogatott, onnan vehetsz át security update csomagokat, akár rpm, akár srpm+rebuild formában.
- A hozzászóláshoz be kell jelentkezni
Mindenképp migrálnom kell. Valószínűleg FreeBSD irányba fogok menni.
- A hozzászóláshoz be kell jelentkezni
miert?
- A hozzászóláshoz be kell jelentkezni
Miért kell migrálnom vagy miért FreeBSD irányba mennék?
- A hozzászóláshoz be kell jelentkezni
utobbira gpndoltam, de vegulis az elso is erdekes kerdes :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A "Rosszabb, mint a Windows registry." almát a körtével :-) Egyébként meg a registry-t is meg kell ismerni, ahhoz hátrébb kell lépni két lépést, és onnan megszemlélni, hogy mi az, miért és mire jó. Ebben valóban hasonlít a systemd-hez.
- A hozzászóláshoz be kell jelentkezni
Ugye nem baj, ha a registry megismerését a unixos reinkarnációján (*) keresztül tettem meg? De az tény, hogy nemhogy 2, hanem legalább 200 lépést léptem hátra hozzá.
(*) gy.k.: AIX ODM
- A hozzászóláshoz be kell jelentkezni
Majd bucko kolléga helyretesz téged is :-D Anno neki mondtam azt, hogy az ODM az registry a'la IBM... :-P
- A hozzászóláshoz be kell jelentkezni
Ugye nem baj, ha eléggé ismerem a Windows registryt pusztán az alábbi minősítéseim révén is: MCP, MCSA, MCSE, MCSE+S stb. ;)
A Windows registry az átgondoltság mintaképe a systemd-hez képest. Ettől még van WTF faktor.
- A hozzászóláshoz be kell jelentkezni
Attól még almát a körtével hasonlítás...
- A hozzászóláshoz be kell jelentkezni
Pontosabban, rohadt almat rohadt kortevel.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
É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...
- A hozzászóláshoz be kell jelentkezni
szerintem nincs ember a vilagon aki teljesen ertene mikor mit es miert csinal a systemd... beleertve potteringet.
es ennek kovetkezmenye a sok osszekokanyolt service file is...
- A hozzászóláshoz be kell jelentkezni
Ahogy anno a sysvinit alapjaival sem volt tisztában sok-sok csomagsza... izé, karbantartó, disztribúciógányoló...
- A hozzászóláshoz be kell jelentkezni
+1 a Slackware-re.
Én Slackware-rel kezdtem. Sokáig használtam szervereken is. Imádtam, hogy úgy faragható GYORSAN, ahogy nekem kényelmes. Nem rettentem meg a csomagok kézi újrafordításától sem.
- A hozzászóláshoz be kell jelentkezni
Amikor 1234 szervered van, és azt kell üzemeltetni, karbantartani, frissíteni, akkor azért a "fordítsuk újra" nem biztos, hogy játszik... Meg a salakhoz dukáló kézimunka sem biztos, hogy öröm...
- A hozzászóláshoz be kell jelentkezni
Hát pedig Centosnál, RHEL-nél, SLES-nél is volt olyan, hogy cégen belül patcheltük azt a pár gyárilag hibás komponenst, majd azt terítettük 1234+ darab szerverre. Nem, nem írtam el a szerverek darabszámát.
- A hozzászóláshoz be kell jelentkezni
+1, ha mar van workflow arra hogy modositani a csomagot, ujrabuildelni megfelelo rendszerekre, akkor mind hogy 10 vagy 1234+ gepre megy fel a sajat repobol. nyilvan ha a 1234+ gep az 123+ fele rendszer, akkor az meg onszopatas...
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Ja, még az jutott eszembe, hogy mintha egy ideje Windowsokban is lenne natív OpenSSHd. Azzal mi van?
- A hozzászóláshoz be kell jelentkezni
Verzió alapján akár érintett is lehet, de egyébként sem nagyon frissitik.
- A hozzászóláshoz be kell jelentkezni
https://security-tracker.debian.org/tracker/CVE-2024-6387
Debian bookworm fixed. Jó tudni, megvolt az upgrade.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Minek is a a sok sz@r bloat, mint a Rust... :)
- A hozzászóláshoz be kell jelentkezni
Rust-ban is lehet szar kodot irni. Es C-ben is lehet jot. a nyelv csak egy eszkoz...
- A hozzászóláshoz be kell jelentkezni
Hol segít a Rust egy versenyhelyzet ki-nem-alakulásában?
- A hozzászóláshoz be kell jelentkezni
hat a RUSTimado babzsakfejlestzokTM azt se tudjak mi az a verseny ;)
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Röviden: ha az Openssh Rrustban lenne írva, meg a glibc is glibrust lenne, és a programozó se trehány, akkor talán.
Ennyit nem ér.
- A hozzászóláshoz be kell jelentkezni
Miért nem?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nade miért csinálsz úgy, mintha neked ez bármi befektetésbe kerülne vagy akár csak kerülhetne?
Semmi hatással nem vagy rá, ha jól sejtem..
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Abszolút értem.
Az nem jön át, nem értem, h miért ne értené?
Ha nem neked kell bele fektetned és ha csak sokára is, de idővel jobb lesz (ha nem is 100% védelem mindenre), akkor én nem látok olyan pontot, amitől nem megérős lehet.
- A hozzászóláshoz be kell jelentkezni
> a jelenlegi funkcionalitásának a 70%-hoz
amugy ezt sose ertettem miert kell egy ssh serverbe ennyi sok funkcionalitas :)
- A hozzászóláshoz be kell jelentkezni
szisztemde' rossz, eseshade' yo, eeerteeeem? :)
- A hozzászóláshoz be kell jelentkezni
mert mar mas nekiallt?
https://github.com/warp-tech/russh
erdekes, h az MS is forkolta es fejlesztik:
- A hozzászóláshoz be kell jelentkezni
Match *
ForceCommands
ControlMaster
JumpHost
AuthorizedKeyCommands
DenyUsers,AllowUsers
DenyGroups,AllowGroups
funkciók eléggé fájnának ha nem lennének így 1 perc gondolkodás után.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
azert nem ez volt az egyetlen sshd bug 20 ev alatt...
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Hogyan lépsz be a szerverekre sshd futása nélkül?
- A hozzászóláshoz be kell jelentkezni
Telneten :D
- A hozzászóláshoz be kell jelentkezni
IPSEC, VPN (bármi, ami korrekt titkosított tunnelt biztosít) használata esetén nincs is azzal semmi gond. Vagy pl. kerberizált környezet.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
Továbbra is abban hiszek, hogy csak az a biztonságos sshd, amit csak megszűrt forrás IP-kről lehet elérni. Tessék használni bounce szervert, a fail2ban nem tökéletes megoldás.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
ez alap (kene legyen), de a bounce szerverre is kell valami :) bar en mar egyre inkabb vpn-t hasznalok erre is
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Bounce szerver az ugyanaz, mint a jump szerver?
A google elég irreleváns találatokat adott.
- A hozzászóláshoz be kell jelentkezni
Nevezd aminek akarod, egy szerver / VPN hálózat / saját FIX IP-s internetkapcsolat akármi, amire biztonságosan bejelentkezel, amin keresztül tunnel-ezel / ahonnan SSH-hoz. Az SSH szerver pedig csak ezekről a megbízható forrásokról fogad el csatlakozást.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Világos, köszi. Egyetértek! Így megy nalam is. Ahol valamiért nem megoldható, ott 3x port kopogtatas van.
- A hozzászóláshoz be kell jelentkezni
👍
Ha így teszel, akkor kb. ezek miatt a támadási formák miatt nem kell aggódnod.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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:
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
lassu munkahoz ido kell!
- A hozzászóláshoz be kell jelentkezni
:-) Én is haloványan elmosolyodtam rajta, hogy milyen reakcióidejük van... Mire ideért, hogy "gáz van", addigra a frissítések rég kimentek az összes érintett gépre...
- A hozzászóláshoz be kell jelentkezni
SUSE Linux Enterprise 15 SP5-ig bezárólag nem érintett.
SP6-ra van workaround:
https://www.suse.com/support/kb/doc/?id=000021482
- A hozzászóláshoz be kell jelentkezni
A RHEL9-be is megérkezett valami hasonló...:
https://bugzilla.redhat.com/show_bug.cgi?id=2295085
https://nvd.nist.gov/vuln/detail/CVE-2024-6409
- A hozzászóláshoz be kell jelentkezni
11 nappal a bejelentés után.
Az ám az Enterprise!
- A hozzászóláshoz be kell jelentkezni