Mitternachtshacking

Die Telekom (bzw. T-Online) hat ihren Kunden da einen ADSL-WLAN-Router Speedport W 700V angedreht, der per Browser aus dem Internet konfigurierbar ist. So etwas ist bekanntlich keine besonders gute Idee. Dieses Konfigurationsinterface lässt sich leider auch nicht abschalten und wenn die Anwender schlechte Passwörter verwenden oder sogar das Standardpasswort („0000“) lassen, kann man z.B. die Zugangsdaten klauen oder anderen Unsinn anstellen. Das Gerät wird von Arcadyan, einem Joint Venture von Accton und Philips hergestellt. Verbockt haben das beide:

1. Arcadyan hat, es musste wohl billig sein, schlicht ein paar Konfigurationsoptionen oder eine brauchbare ACL-Implementierung weggelassen. (Vielleicht wollten sie auch nur nicht von Harald Welte verklagt werden.)
2. T-Online hat das eigentlich übliche Due Dilligence beim Abschluss eines solchen Liefervertrags grob vernachlässigt, bereits bei einfachen Tests der Geräte hätte so etwas auffallen müssen.

Nun gut, jetzt gibt es ein Firmware-Update auf 1.16, das dieses Problem löst. Das laden die Router sogar automatisch (ich hoffe das hat T-Online vorher auch getestet), es dauert nur eine ganze Weile bis das auf allen Geräten drauf ist. Nicht jeder ist schließlich rund um die Uhr online.

Und da ist T-Online auf die geniale Idee gekommen, einfach komplett für alle User, vermutlich auf allen Routern, den TCP-Port 8085 zu sperren. Den Port verwendet normalerweise eh keiner. Herausgekommen ist das, weil eine Bank für ihr Online-Banking zufällig genau diesen Port nutzt, lt. IANA ist der Port „unassigned“. Im Prinzip ist das nichts neues. Das Leibniz Rechenzentrum der Münchner Hochschulen macht so ettwas auch, da nennt sich das Sicherheitspaket D und sperrt von außen den Zugriff auf bestimmte Microsoft-Ports.

Nur, das LRZ kommuniziert mit den angeschlossenen Instituten. Da weiß jeder Bescheid. T-Online sperrt einfach und gibt niemandem Bescheid. Auch wenn eine solche Maßnahme im Sinne der meisten Kunden ist, halte ich es für absolut inakzeptabel, dass solche Sperren nicht öffentlich bekanntgegeben werden. Für jeden sonstigen Werbekäse verschickt T-Online ja auch eine E-Mail.

Ach ja, die Kollateralschäden: World of Warcraft braucht in vielen privaten Server-Installationen die Ports 3724, 8080 und 8085. Sipgate bietet über Port 8085 anscheinend eine Abfrage des Onlinestatus und Sun Java will den Port auch für irgendwas verwenden. Dumm gelaufen.

Andererseits könnte das auch eine clevere Geschäftsidee sein:

• Internet-Zugang Basisanschluss (nur Port 80 HTTP): 19,90 Euro
• Aufpreis Mailabruf per POP3: 4,95 Euro
• Aufpreis WoW Ports: 4,95 Euro

Da kann man richtig was verdienen. Beim Mailversand mit eigenen Mailadressen kassiert T-Online ja schon länger. Das war übrigens einer der Hauptgründe, warum ich nicht mehr bei T-Online bin. Da bleibt es dem Verbraucher unbelassen, mit den Füßen abzustimmen. Aber das passiert eh schon.

Ist das eigentlich noch mit Netzneutralität vereinbar?

Anmerkung: Der SpeedPort W701V von AVM ist davon übrigens nicht betroffen.

Soso, nun ist Intel also aufgescheucht worden und hat deutlich reagiert:

„We’ve addressed a processor issue by providing a BIOS update for our customers that in no way affects system performance. We have documented this as an errata.“

Das glaube ich gerne, aber ob die BIOS-Updates dann auch überall eingespielt werden ist eine ganz andere Frage. Klar, neue Motherboards, die in vielleicht einem halbe Jahr produziert werden, haben das Update dann drin. Ältere Motherboards aber nicht. Da werden noch genug angreifbare Systeme übrig bleiben.

Ob das dann tatsächlich zu Root-Exploits führt, wage ich in diesem Fall ja zu bezweifeln. Dafür ist die Materie zu komplex und von zu vielen Rahmenbedingungen abhängig. Außerdem gibt es mit Vista eine große Spielwiese.

Andererseits hat Theo de Raadt auch nicht unrecht:

„Part of exploitability is being able to crash a machine reliably, We’re trying to build reliable systems on an unreliable framework.“

Bei The Register und dem Inquirer gibt es mehr zum Thema

Theo de Raadt, genialer aber selten diplomatischer Chefentwickler von OpenBSD hat offensichtlich einen neuen Lieblingsgegner ausgemacht: die Intel Core 2 CPUs. In einer Mail an die OpenBSD-Liste beschreibt er die Entwicklerprobleme mit der Intel-CPU.

These processors are buggy as hell, and some of these bugs don’t just cause development/debugging problems, but will *ASSUREDLY* be exploitable from userland code.

Eine coole Vorstellung … Sicherheitslücken, die zu Root-Exploits führen können treten nicht mehr nur im Betriebssystemcode auf sondern inzwischen vermehrt auch in Prozessoren. Und wenn es sich um richtig fiese Fehler handelt, ist unter Umständen gar kein funktionierender Workaround möglich. Der berüchtigte Pentium-FDIV-Bug ist harmlos dagegen.

Im einzelnen führt Theo de Raadt folgende Fehler auf:

• AI56: Update of Read/Write (R/W) or User/Supervisor (U/S) or Present (P) Bits without TLB Shootdown May Cause Unexpected Processor Behavior
• AI79: REP Store Instructions in a Specific Situation may cause the Processor to Hang
• AI43: Concurrent Multi-processor Writes to Non-dirty Page May Result in Unpredictable Behavior
• AI39: Cache Data Access Request from One Core Hitting a Modified Line in the L1 Data Cache of the Other Core May Cause Unpredictable System Behavior
• AI90: Page Access Bit May be Set Prior to Signaling a Code Segment Limit Fault
• AI99: Updating Code Page Directory Attributes without TLB Invalidation May Result in Improper Handling of Code #PF

Theo de Raadt schreibt dazu:

„We bet there are many more errata not yet announced — every month this file gets larger. Intel understates the impact of these erraata very significantly. Almost all operating systems will run into these bugs.Basically the MMU simply does not operate as specified/implimented in previous generations of x86 hardware. It is not just buggy, but Intel has gone further and defined „new ways to handle page tables“ (see page 58).Some of these bugs are along the lines of „buffer overflow“; where a write-protect or non-execute bit for a page table entry is ignored. Others are floating point instruction non-coherencies, or memory corruptions — outside of the range of permitted writing for the process — running common instruction sequences.All of this is just unbelievable to many of us.“

Oder anders ausgedrückt: Wir werden in Zukunft vermutlich eine komplett neue Klasse von Exploits sehen, die sich gar nicht auf ein Betriebssystem ausrichten sondern auf die darunterliegende CPU. Sehr spannend, das werde ich mal im Auge behalten.

Zum Nachschlagen: die komplette Liste der Intel Core 2 Fehler