Infos zur TCP Options Lücke – CVE-2026-98432

Wer verzweifelt auf der Suche nach einem Patch für seinen Uralt-Embbedkernel ist, könnte das hier brauchen:

iptables -I INPUT -p tcp –syn -m length –length 61:65535 -j DROP

Das blockt die überlangen SYN TCP Optionspakete mit dem Exploitcode drin ab, bevor diese eine Anwendung erreichen und passend verarbeitet werden.

Es gibt nur einen kleines Problem damit: 

Wenn Ihr ein Appleprodukt benutzt um Webseiten auf einem so geschützten Gerät aufzurufen oder andere TCP basierte Dienste nutzen wollt, dann geht das direkt danach nicht mehr.

Die Entwickler bei Apple haben nämlich entschieden, daß sie als einzige beim Aufbau einer TCP Verbindung ein SYN Paket MIT TCP Options senden und das ist immer länger als die 60 Bytes von Windos, Unix, Linux und Android. Die Regel lehnt das sofort ab, und das wars dann mit Appleconnections zu dem Host.

Es gibt eine Alternative Firewallregel, von der ich mal behaupte, daß keiner von Euch dieses Modul auf dem Schirm hat:

iptables -I INPUT 1 -m u32 –u32 ‚0>>24&0x0f=6:15‘ -j DROP

Abgefahren , oder? 🙂 Auch die DROPPED die Pakete, wenn TCP Optionsflags vorkommen, aber die könnte man so anpassen, daß die Standardoptions von Apple durchgehen, die bösen Exploitcodes aber draußen bleiben. Dazu hatte aber keine KI Lust. Armes Apple ;D

Was macht „iptables -I INPUT 1 -m u32 –u32 ‚0>>24&0x0f=6:15‘ -j DROP“ ?

Der IP header wird Bitmäßig so gefiltert, daß nur das IP hdrlength Feld übrig bleibt. Das gibt an, wieviele LONG (32bit) Tokens der Header hat. Alle normalen haben 5 * 4(32-Bit) = 20 Bytes , also ist alles was > 5 ist entweder ein Apple Syn oder der Exploit.

Updated lieber den Kernel, haben wir auch gemacht, sowas ist nur was für Legacygeräte wie IoT, Ebbed usw. ohne Updates, wo auch niemand mit Apple jemals wieder drauf muß.

 

Fails von TrendMicro und Bosch

Ihr wollt, daß bei Euch auf dem Mailserver Emails von vaiden Absendern ankommen? Da nehmt mal nicht TrendMicros AI Appliance, deren Daten sind leider nicht so verläßlich, wie es das Thema erfordert. Nur weil AI dransteht, muß es nicht besser sein.

Was ist mit TrendMicro passiert?

Nun ja, ich wollte der Volkshochschule in Braunschweig eine Email senden und die ging fast 48h nicht raus, sondern wurde absichtlich in einer Warteschleife festgehalten, auf meinem Server wohlgemerkt. Das lag an der Antwort den die TendMicro Instanz von sich gegeben hat (450 temporärer Fehler), nur so temporär wie er sein sollte, war er nicht 🙂

Die IP des Servers, der keine Kundenpräsenzen hat und seit über 16 Jahren keine Spams gesendet hatte, stand bei der tollen KI Lösung in der Liste „kürzlich“ erfolgten Spamprobleme. Da scheint TrendMicro eine andere Vorstellung zu haben als ich, was „kürzlich“ meint. Da Sie keinen echten Grund angegeben haben, was auch schwierig werden dürfte nach 16 Jahren, werden wir das wohl nie erfahren 😉

Einzig positiver Lichtblick: Das Entsperren per Removerequest ging deutlich schneller 😉

Und was ist jetzt mit Bosch?

Liebe Bosch-(Tochter)-IT,

wir schreiben das Jahr 2026. In 2016 gab es EU-weit eine eher unbeachtete Einführung von Datenschutz für Firmen, da steht drin zu lesen, daß der Transport von Personenbezogenen Daten dem Schutzniveau der Daten entsprechend nur noch verschlüsselt passieren darf, wenn das mit zumutbar geringen Aufwand leistbar ist. Ich stelle fest: Das ist es.

Da ich da nicht ganz unbeteiligt dran war, hier ein interessanter Link für Euch: 20210616_orientierungshilfe_e_mail_verschluesselung.pdf

Kommen wir wieder ins Jahr 2026 zu Bosch:

2026-11-02 13:49:01 H=mail.qbrx.com (mail.my.qbrx.com) [85.184.248.248] F=no-reply-portal@em-mail.bosch-nexospace.com rejected RCPT REDACTED@REDACTED.de: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.

und ja, das war heute, ja das waren Personenbezogene Daten, denn die DSK hat gesprochene Emailadressen wie name.vorname@ u.ä. als Personenbezogene Daten definiert und um noch eins drauf zu legen, der Server kann TLS 1.3, wenn man sich hin verbindet, er nutzt es nur nicht, wenn er Mails versendet. Das ist jetzt blöd gelaufen für Bosch 🙂

 

Update: Fedora hat das PHP Update verkackt.

Vorhin noch geschwärmt, jetzt ist PHP2SHELL Alarm in der Bude:

Fedora hat die PHP Updates nicht in ins Stable gepusht.

Stand: 1:20 Uhr  sind die Pakete zwar im Koji, aber nicht im stable Repo.[mindestens F43 nicht]

Angesichts der Dringlichkeit sollten Sie aber das Testing Repo überspringen.

Wenn Ihr das lest noch kein update habt, zieht Euch die Files für Eure Architektur direkt aus dem Koji.

https://koji.fedoraproject.org/koji/packageinfo?packageID=72

alles was keine DEBUGINFO im Namen hat runterladen und per :

dnf update ./php*rpm 

updaten!

Update: 12:49 Uhr

Die Pakete haben es in das Testing Repo geschafft. So könntet Ihr jetzt updaten:

sudo dnf –enable-repo=updates-testing update php-fpm

oder auch nur „php“ , je nachdem was Ihr so braucht.