Nächste kritische Sicherheitslücke in Firefox 124.0

Einmal alle auf Firefox 124.0.1 updaten..

https://www.mozilla.org/en-US/security/advisories/mfsa2024-15/

CVE-2024-29944: Privileged JavaScript Execution via Event Handlers

Reporter Manfred Paul via Trend Micro’s Zero Day Initiative
Impact critical
Description

An attacker was able to inject an event handler into a privileged object that would allow arbitrary JavaScript execution in the parent process. Note: This vulnerability affects Desktop Firefox only, it does not affect mobile versions of Firefox.

Die Lücke ist OS unabhängig.

PVA: kleines Sicherheitsloch im IMAP Modul

Wie das so mit komplexer Software ist, CVE Meldungen sind quasi vorprogrammiert, aber einfache Programmierfehler tun es meistens auch 🙁

PVA: kleines Sicherheitsloch im IMAP Modul

Jetzt ist der Einschlagkrater durch die im PVA gefundene Sicherheitslücke nicht besonders groß, man müßte Ihn vermutlich mit der Lupe suchen, weil kaum wer von dem neuen Feature wußte und es ausprobiert hat, aber, zur Vermeidung gleichartiger zukünftiger Unfälle, soll die Lücke seziert und dokumentiert werden.

Was ist passiert?

In der MailConnection-Komponente, die macht die IMAP Verbindung auf, war ein Programmierfehler drin, der die verschlüsselte Verbindung zum IMAP Server unterband. Wer also die neue Funktion schon ausprobiert hat , muß mindestens auf diesen Commit updaten: 685ee5ecaa486006a0cee04cac763ee479160e6e

Hier der fehlerhafte Code:

Properties props = System.getProperties();
if ( m.secure == true ) {
       props.setProperty("mail.store.protocol", "imaps");
} else props.setProperty("mail.store.protocol", "imap");

Session session = Session.getInstance(props, null);
Store store = session.getStore("imap");
store.connect(m.servername, m.username, m.password);

Statt die laut Konfiguration (m.secure) gewünschte Verbindungsart „imaps“ zu wählen, zog es der Code vor, dann doch unabhängig davon „imap“ zu verwenden. Korrekt wäre diese Zeile gewesen:

Store store = session.getStore();

Was war die Ursache?

Als Ursache konnte „mangelndes Verständnis“ der Methode getStore(…) ausgemacht werden, um genau zu sein, wurde erwartet, daß es sich um den Unterschied zwischen „POP3“ oder „IMAP“ handelt, weil der Sicherheitslevel wurde ja vorher schon festgelegt, aber leider überschrieb der Aufruf diese Voreinstellung wieder.

Was müßt Ihr tun?

Im Repo ist das Update bereits enthalten, so daß alle die, die Automatische Updates einspielen, schon sicher sind.
Wer seinen PVA selbst baut, der muß einmal updaten und compilieren.

Wie wurde es gefunden?

Vor 11 Jahren, ja, einfach weiterlesen, entschied ich, daß meine POP3/IMAP Serverlogs von einer Software auf genau diese unverschlüsselten Verbindungen prüft und den Benutzer darüber informiert, daß er irgendwo eine unsichere Konfig hat. 11 Jahre lang habe ich keine Email erhalten, und jetzt rettet dieses kleine Script dem PVA den Arsch 😉

PS: Falls wer dachte, daß man im Github einfach mal so ein Security Advisory schreiben könnte, der hat das noch nie versucht und mir ist jetzt klar, warum so viele Projekte mit Lücken, keine Securityeinträge haben 🙁

BleedingTooth: Remote Code Execution in BlueZ Kernelstack

Kritische Sicherheitslücke im Bluetooth-Stack von Linux und Android entdeckt. Bluetooth eingeschaltet zu haben, reicht aus um angreifbar zu sein.

BleedingTooth: Remote Code Execution in BlueZ Kernelstack

Kritische Sicherheitslücke im Bluetooth-Stack von Linux vor Kernel 5.9 entdeckt. Der Fix wurde am 29.9. bereits heimlich in einen Kernel Branch eingepflegt und wartet seitdem auf den Merge in den Hauptkernel. Erst für Kernel 5.9 war das der Fall, so daß derzeit alle Geräte die mit Linux angreifbar sind, bis auch dort Backportpatche verfügbar sind.

Gefunden hatten diese Lücken Intel ( „Intel – wie konnte das passieren, die finden doch sonst nichts“ )  und Google. Bei Google kann ich das verstehen, die verdienen damit Geld, aber Intel? 😉

Also RCE, Remote Code Execution, und das auch noch ohne Anmeldung. Meint: Jedes Gerät mit aktiviertem Bluetooth in der Nähe ist angreifbar, nur weil es da ist. BleedingTooth ist dabei nicht nur eine Lücke, sondern ein ganzes Sammelsurium an Schwachstellen, die kombiniert, den RCE mit Privilegien Eskalation erlauben.

Bis auf weiteres: BlueTooth abschalten!

Quellen:

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html

https://github.com/google/security-research/security/advisories/GHSA-h637-c88j-47wq  ( Die erlaubt die Code Ausführung )