Viper780
ModeratorEr ist tot, Jim!
|
Autsch! Dann kann ich mal grob alles durch patchen. Was mich immer wieder beeindruckt ist sowas: OpenBSD systems are unaffected by this bug, as OpenBSD developed a secure mechanism in 2001 that prevents this vulnerability. Warum haben nur die bei OpenBSD Security wirklich drauf?
|
Smut
takeover & ether
|
sie adden auch weniger funktionen und halten das system schlank. würd das als "nur" markieren - also allgemeinen beleg dafür hätte ich keinen. wichtig ist bei der lücke zu schauen a) welche distributionen sind affected b) wo gibt es überhaupt schon einen patch. aktuell ist kein "patch now" möglich. die ausnutzung ist nicht ohne weiters möglich aufgrund von ASLR. auch auf 64bit schwerer (weil ASLR dort effektiver sein kann). zumindest hier ein beleg: As of July 1st, 2024, no exploitation of this vulnerability has been identified in the wild, and there aren’t any publicly available exploits. The vulnerability has only been proven as exploitable under lab conditions on 32-bit Linux/glibc systems with ASLR. Exploitation on 64-bit systems has not been proven but is believed to be possible. https://www.wiz.io/blog/cve-2024-63...cal-rce-openssh
|
COLOSSUS
AdministratorGNUltra
|
Warum haben nur die bei OpenBSD Security wirklich drauf? Dieses Problem wurzelt allerdings nicht in der glibc, sondern in Portable OpenSSH, also einem OpenBSD-adjazenten Projekt In einem Signal Handler darf man halt keine Funktionen aufrufen, die nicht explizit als Signal-Safe "markiert" (leider halt nur in der Dokumentation bzw. statischen Analysetools) sind. Deswegen patchst du heute auch OpenSSH, und nicht die (g)libc. Ich habe/Wir haben schon alles durchgepatcht, aber nachdem kaum jemand meinem Gefuehl nach heute noch i386-Systeme auf breiter Basis betreibt, ist die Luecke wohl in der Praxis deutlich weniger desastroes als es zuerst schien. Das Advisory hat aber sehr gut beim Munterwerden geholfen
|
Viper780
ModeratorEr ist tot, Jim!
|
Klar es ist eine relativ kleine Distribution und sehr eingeschränkt. Aber wenn man sich bei den CVE/CVSS Listen schaut steht da im Vergleich zu anderen nur 1/10
|
Smut
takeover & ether
|
die bewertungen sind auch noch nicht durchgäng da. aber es ist eine RCE somit wirds mal 8++ haben. gibt halt nur wenig systeme auf die es anwendbar ist. was halt in dem fall sein kann ist, dass jetzt die alten cves nach oben gespühlt werden, die damals offensichtlich niedriger bewertet wurden. problem ist halt, dass man bei linux jetzt nicht klar sagen kann welche distributionen die CVE vielleicht schon gefixt haben/hätten. der qualys artikel geht z.b. nur auf debian/ubuntu ein. was hat redhat gemacht? (gut, weiß man jetzt weil sie selbst schon ein advisory rausgebracht haben das nur rhel9 meldet). aber die lücke braucht etwas an eingrenzung - habs im stress vorhin aber nur unkommentiert posten können. hier z.b. aktuelle bewertungen für cvss3 https://nvd.nist.gov/vuln/detail/CVE-2024-6387
|
mr.nice.
differential image maker
|
Könnte z.B. fail2ban vor diesem SSH Exploit schützen, sprich sind da fehlgeschlagene Loginversuche vorhanden, oder rutschst das durch?
|
Smut
takeover & ether
|
per default nicht. der (failed)login wird nicht durchgeführt und damit auch nicht protokolliert. je nach sshd config kannst aber (wie im qualys q/a angeführt) ein "˜login timeout before authentication" im erhalten. die logmessage kannst dann via fail2ban parsen und einen counter bauen etc. macht logischwerweise nur sinn wenn aus irgendeinem grund kein patch vorhanden wäre bzw. man das timeout nicht nach unten stellen kann - also sehr theoretisch. also nein, fail2ban fängt es nicht ab. hth
|
Philipp
Here to stay
|
problem ist halt, dass man bei linux jetzt nicht klar sagen kann welche distributionen die CVE vielleicht schon gefixt haben/hätten. der qualys artikel geht z.b. nur auf debian/ubuntu ein. was hat redhat gemacht? (gut, weiß man jetzt weil sie selbst schon ein advisory rausgebracht haben das nur rhel9 meldet). aber die lücke braucht etwas an eingrenzung - habs im stress vorhin aber nur unkommentiert posten können. Die wichtigen Distributionen kündigen ohnehin ihre Sicherheitsupdates an. Selbst Arch hat gestern ein Security Advisory dazu veröffentlicht. Betroffen sind eigentlich nur Distributionen der letzten 2-3 Jahre oder Rolling Releases. Ältere Distributionen wie Debian 11 oder RHEL 8 sind nicht betroffen. Red Hat hat bisher keine Updates veröffentlicht hat. Weder für RHEL 9 noch für Fedora Linux. AlmaLinux ist derzeit die einzige RHEL basierende Distribution, bei der dieses Problem behoben ist. Edit: Von SUSE gab es bisher auch kein Update.
Bearbeitet von Philipp am 02.07.2024, 06:29
|
Philipp
Here to stay
|
Fedora Linux, RHEL 9, Oracle Linux 9 und Debian Trixie (Testing) haben das Update jetzt auch bekommen. Von SUSE wurde bisher noch immer nichts angekündigt und für Rocky Linux ist es auch noch nicht verfügbar.
|
SergejMolotow
Here to stay
|
Authy: Hacker greifen Millionen von Telefonnummern über eine ungesicherte API abNachdem Kriminelle eine CSV-Datei mit Telefonnummern von angeblich 33 Millionen Authy-Nutzern geleakt haben, drohen unter anderem SMS-Phishing-Attacken. Link: www.heise.de
|
davebastard
Vinyl-Sammler
|
autsch, das hatte ich früher schon mal verwendet. aktuell hab ich aber wegen arbeit den von microsoft
|
wergor
connoisseur de mimi
|
Keine Sicherheitsupdates in Sicht: Avast Free Antivirus ist verwundbarSicherheitsforscher warnen vor Schwachstellen in Avast Free Antivirus und raten aufgrund fehlender Patches von einer Nutzung ab. Link: www.heise.de benutzt noch jemand avast?
|
mr.nice.
differential image maker
|
Ist jetzt nicht dramatisch, da es einen lokalen, administrativen Zugriff braucht, aber dennoch, supply chain Attacken mit für das OS unsichtbarer firmware malware sind damit durchführbar. CPU-Sicherheitslücke in AMD-Prozessoren ermöglicht Malware-InfektionenSicherheitsforscher haben eine als Sinkclose bezeichnete Sicherheitslücke in AMD-CPUs entdeckt und auf der Defcon 32 in Las Vegas präsentiert. Link: www.heise.de
|
davebastard
Vinyl-Sammler
|
|
Smut
takeover & ether
|
Attacking UNIX Systems via CUPS, Part IHello friends, this is the first of two, possibly three (if and when I have time to finish the Windows research) writeups. We will start with targeting GNU/Linux systems with an RCE. As someone who’s Link: www.evilsocket.net
|