Naja. Das FirmwarePWD ist aber keine OS-Funktion. Wenn das FirmwarePWD den Angriffsvektor über Firewire ausschalten kann (der ja, wenn ich das jetzt richtig geschnallt habe, dem USB-Angriff substanziell gleicht), dann sehe ich keinen Grund, warum es das nicht auch für USB können soll.
Weil das Problem anders gelagert ist. Firewire und USB sind nicht das gleiche.
Die
Auswirkung ist substantiell gleich, der Vorgang nicht.
Bei FW war das Problem, dass ein bereits vorhandenes und durchaus gewolltes Feature falsch im Treiber konfiguriert war (ist ?). Dort waren (oder sind ?) einige Addressbereiche, die "Filterzonen" im Treiber sehr lax und leichtfertig gesetzt, was durch eine ganz einfache und ansonsten reguläre Aktion ausgenutzt werden kann. Das ermöglicht den Zugriff auf absolut sperrwürdige Hardwarebereiche, im Extremfall sogar auf sämtliche Komponenten des Rechners.
Diese "Filter" haben eine ähnliche Funktion wie die Subnetzmaske für eine IP-Addresse: Sie trennen gültige von ungültigen Speicheraddressen durch eine Bitmaske voneinander.
Quell des Übels ist ein einst extra eingeführtes Feature, das aber seither so gut wie nie genutzt wird. Und zwar die Möglichkeit für FW-Geräte, sich völlig autonom zu verständigen und Daten auszutauschen, sogar ganz ohne Zuhilfenahme eines Rechners.
(Es war einmal eine Festplattenkopierstation auf dem Markt, auf der Basis von FireWire aufgebaut. Besser gesagt, auf der "generischen" Version davon, die auf den Namen IEEE1394 hört. Diese war als Werkzeug für Computermanufakturen gedacht, damit wurden am Fliessband mit Hochgeschwindigkeit Festplatten für neue Rechner geklont, und zwar mehrere Dutzend Platten pro Durchlauf ... simultan.
In oder an dieser Kopierstation befand sich kein richtiger PC, kein RAM und keine CPU, sondern im Grunde nur ein winziges Tastenfeld mit Display. Ein winziger Microcontroller im Wert von geschätzt 2,50 Euro hat genügt, um all die Kopiervorgänge anzustossen und zu steuern - dank der enormen Eigenintelligenz der FireWire-Controller.)
Zu diesem Zweck besitzt ein jedes FW-Gerät (auch der Hostrechner) gewisse Speicherbereiche, die anderen "Nodes" förmlich als "Briefkasten und Abholstation" zur freien Verfügung stehen.
Diese Datenaustauschbereiche wurden bei der Konzeption von FW mit derart grosszügig bemessenen Adressräumen ausgestattet, dass man ganze Rechnersysteme damit abdecken kann.
Auch ein Hostrechner hat eine solche Addresszone. Dummerweise hat man irgendwann vergessen, dass auch der Arbeitsspeicher deines Computers mitsamt sämlichen PCI Devices in diesem Adressraum auftaucht, oder besser gesagt, er verschwindet förmlich darin. Die Bitmasken zur Sperrung gefährdeter Bereiche korrekt zu setzen wurde versäumt.
Im Jahre 2004 hat sich jemand daran erinnert.
Setzt du das OF-Kennwort, werden die Filterwerte des Adapters beim Systemstart strenger als normal vorprogrammiert und die Gefahr ist gebannt. Dann liegt es allein in der Kontrolle des Treibers, welche Addressbereiche für Übertragungen geöffnet werden und vor allem, welche für
rein hardwaregesteuerte Transferanforderungen von ausserhalb geschlossen bleiben. OF setzt diese autonom hardwaregesteuerte Datenübertragung kurzerhand
völlig ausser Betrieb. Was EFI tut, ist bisher
unbekannt. Man müsste es mal versuchen...
Im Grunde ähnelt das ganze ein wenig der Neukonfiguration einer Firewallsoftware fürs Internet. Sozusagen: Port gesperrt - Problem beseitigt.
Anders bei USB, wo man früher ein solches Feature nicht schon von Anfang an hatte und es mit der Umstellung auf USB-2 mit heisser Nadel hinzugefrickelt hat. Und zwar auf ziemlich abenteuerliche und ulkige Weise, in dieser Disziplin ist intel wohl marktführend. Die Protokolle, mit denen auf USB gearbeitet wird.... wovon rede ich hier eigentlich? "Protokolle"? Hah! Pff!
Ein USB-Baum arbeitet *völlig* anders als ein FW-Netz. Dort herrscht eine hierarchische Struktur, in der nur ein einziges Gerät im Bus Übertragungen anordnen und abwickeln kann. Alle anderen Geräte im Bus haben den Anweisungen dieses Mastercontrollers widerstandslos zu gehorchen, sonst klappt nichts mehr.
Wer nun dieser Master im USB-Baum ist, ist schnell geklärt: Wer zuerst kommt, der mahlt zuerst. Der Hostadapter deines Rechners ist
immer der erste, der mit Strom versorgt wird und schon ist klar, wer das sagen hat. Das BIOS eines PC (bzw das EFI eines Mac) retten die Situation, falls doch einmal ein externes Gerät schon eingeschaltet und aktiv im Bus vorgefunden wird, während der Rechner bootet.
Während des Startvorgangs wird einfach mal für einen kurzen Moment der Saft abgedreht und laut "BUUUH! WEG DA!" auf die Datenleitung geschrien. Das "erschreckt" definitiv jedes externe Gerät so sehr, dass es den Busverkehr als völlig zusammengebrochen betrachtet und eine neue Verbindung versucht. Sobald die externen Geräte wieder "online" kommen, steht der Hostcontroller aber schon parat, nimmt seine Kumpels in Empfang und die Hierarchie ist klargestellt. Andere masterfähige Controller sind kaltgestellt und "an der Leine" des Chefs. Dieser hier sehr vereinfacht beschriebene Initialisierungsprozess nennt sich "Arbitration".
Nun soll der USB Controller natürlich auch arbeiten können und daher wird ihm von der Rechnerfirmware ein Addressfenster zugewiesen. Genauer gesagt sind es sogar mehrere, für verschiedene Zwecke. Eine Zone für ankommende, eine für abgehende Kommunikation mit dem Betriebssystem, eine für die Nutzdaten von DMA-Transfers und ggf. noch weitere Resourcen.
Wieviele und wie grosse Speicherzonen ein bestimmtes Gerät braucht, erfährt die Firmware dabei aus den "eingebrannten" Konfigurationsdaten der PCI-Schnittstelle des Geräts. In diesem Punkt unterscheidet sich ein USB Controller nicht von anderen Hardwarekomponenten, diese Grundprozedur ist im wesentlichen gleich für alle möglichen Arten von Geräten.
Die genauen Koordinaten dieses Fensters sind in einem "Plug and Play" Gerät sehr frei variabel und müssen daher dem Controller erst mitgeteilt werden. Das wird gemacht, der Adapter merkt sie sich und der Startvorgang des Rechners läuft weiter. Irgendwann dann ist dein OS "oben" und erhält von der Firmware diese Werte ebenfalls mitgeteilt. Diese können akzeptiert werden, oder aber auch nachträglich abgeändert falls der Treiber es wünscht. Wenn das geschieht, teilt der Treiber dem Controller die neuen Addressen für seine zukünftigen Operationen mit und (...hallo!!!...)
verlässt sich blind darauf, dass diese auch eingehalten werden.
Mehr
kann er gar nicht machen, und mehr braucht er normalerweise auch nicht zu tun.
Es genügt für den Betrieb völlig, jegliche
andere Software im System daran zu hindern, diese Addressen eigenmächtig zu manipulieren, dafür haben die Sicherheitskonzepte des Betriebssystems Sorge zu tragen. Das Treiberkonzept des OS schirmt die Konfigurationsschnittstellen des Adapters gegen fremde Zugriffe ab und sorgt so dafür, dass die authorisierte Software ganz alleine bestimmt, was der Adapter tun darf oder nicht tun darf. Der Treiber, bzw der Kernel hat aber keine wirkliche Kontrolle darüber, was der Adapter tut, wenn dieser plötzlich ein "Eigenleben" entwickelt und den ursprünglichen Resourcenzuweisungen nicht mehr gehorcht - zB wenn er kaputt ist, einen Bug in seinem Controllerchip aufweist - oder gekapert wird.
Im Normalbetrieb geschieht das nicht. Wenn du tatsächlich mal einen fremden Mastercontroller mit deinem eigenen Master zusammensteckst während das System normal läuft, kann man das abfangen. Solange der Controller "wach" ist und "sauber" im USB-2 Modus arbeitet, wird diese Situation erkannt und die Kommunikation erst mal gestoppt. Beide Adapter melden ihrem jeweiligen OS, was los ist. Die installierte Software kann jetzt entscheiden, was zu tun ist. Entweder passiert gar nichts und sämtliche Datentransfers bleiben angehalten, indem der Adapter auf seinem Befehlskanal eine entsprechende Anweisung dazu erhält. Diese Anweisung von aussen zu verhindern oder zu übersteuern ist meines Wissens nach nicht möglich. Erst wenn die Situation auf dem USB sich erneut ändert und für beide Controller wieder freie Fahrt herrscht, wird der Bus wieder angeworfen und normal weitergemacht.
Es gibt aber auch die Möglichkeit, dass auf beiden Rechnern eine Software läuft, die Rechnerkoppelungen im "Point-to-Point" Verfahren erlaubt. In diesem Fall muss der eine Treiber dem auf dem anderen Rechner laufenden Kollegen absolut blind vertrauen und
gibt freiwillig die Kontrolle über seinen eigenen Arbeitsspeicher an den fremden Rechner ab. Ab diesem Zeitpunkt entscheidet die Software auf dem entfernten Rechner, wann und von wo Daten geholt oder wohin sie geschrieben werden. Die Treiber kommunizieren weiterhin miteinander, und sobald die gewünschte Aktion beendet ist, gibt der führende Adapter die Kontrolle wieder zurück.
Das nennt man ein
kooperatives Verfahren, und das ist im IT-Bereich nichts besonderes. Es ist nicht lange her, da wurden nach dieser pragmatischen Vorgehensweise ganze Betriebssysteme realisiert, und die sind teilweise heute "hackersicherer" als so manches "moderne" Konstrukt.
Beim USB-Hack ist das Problem, dass du der CPU des Rechners (bzw dem zuständigen Treiber) die Gewalt über den Adapter entreisst. Und zwar
komplett, und ohne dass es verhindert werden könnte, denn es geschieht von aussen, und es geschieht durch eine integrierte Funktionalität des Adapters selbst. Es geschieht OHNE das Einverständnis des Treibers, es gibt keine Benachrichtigung und keine Erlaubnis, es passiert einfach. Der Adapter versucht eine neue Arbitration des Busses, diesesmal verliert er aber dabei, er bekommt die Rolle des Knechtes.
Wie das abläuft, hatte ich schon beschrieben.
Der Adapter wird (bildlich gesprochen) förmlich aus deinem Computer herausgerissen, umgedreht und "verkehrt herum" wieder in Betrieb genommen - unter der Kontrolle einer fremden Macht von ausserhalb. Was der Treiber dem Controller mal zugewiesen hat, zählt nichts mehr. Auf die Kommandos des Treibers hört er nicht, denn der schläft weiter und sendet gar keine. Und selbst wenn er das täte, der Adapter hat längst die Addressen dicht gemacht auf denen er sonst lauscht, er hört einfach nicht mehr hin. Aus USB wird OSB - O wie "Ohropax".
(Du erinnerst dich? Plug and Play - variable Resourcen und so...)
Er verhält sich plötzlich so, als wäre dein Rechner nur ein dusseliges Peripheriegerät wie ein Speicherstick oder ähnliches, und dementsprechend geht er damit um - weil er es
kann. Selbst wenn das OS während dieser Attacke normal weiterlaufen würde (was es nicht tut, denn während dieser Phase ist das System noch nicht wieder erwacht), könnte es nichts gegen diese Form von Angriff tun. Das wäre so als würdest du während einer Blinddarm-OP hellwach, kannst dich aber weder bewegen noch sprechen.
Das ähnelt eher der Aktion, mit einer Zange im laufenden Betrieb den USB Port rauszubrechen und innerhalb von Millisekunden was völlig anderes dort wieder anzulöten.
Klingt das leicht unterschiedlich zur "FireWireWall"-Problematik?
Was übrigens geschieht sobald die Aktion beendet ist, bleibt undefiniert. Der Pirat könnte sorgsam vorgehen und sämtliche Parameter und Speicherinhalte so zurücklassen wie er sie vorgefunden hat. In diesem Falle würde dein OS nur glauben, der USB Controller hätte zum Aufwachen etwas länger gebraucht als sonst, was aber nichts ungewöhnliches ist und keinen Verdacht erregt.
Im Regelfall aber wird er sich selbst nicht trauen und sogar davon ausgehen, dass es im Rechner eine spezielle Hardware geben könnte, die autonom von der sonstigen Rechnerhardware läuft und solche Vorfälle protokollieren kann. Manche Server der Titanic-Klasse besitzen eine solch hochentwickelte "Watchdog"-Einrichtung (Nicht zu verwechseln mit einem simplen Watchdog-Timer, den heute fast jeder PC hat).
Daher dürfte der Pirat wohl die Gelegenheit beim Schopfe packen, vor seinem Abschied kurz noch den Speicherbereich auszunullen, in dem sich dein Kernel tummelt und dein System so vollständig einfrieren lassen. Oder er ist höflich und erteilt der Hardware die Anweisung, den Strom abzustellen. Power... off.
Es wird dann auch kein Speicherabbild ("core dump") eines Debuggers o.ä. mehr möglich sein, und eine "post mortem" Analyse des Vorfalls ist unmöglich. Du findest keinerlei Spuren der Attacke.
Du findest nur einen aus ungeklärter Ursache abgestürzten Rechner vor.
Als ob das was besonderes wäre... was willst du tun?
Kleiner Tip übrigens noch:
Ich hab was läuten hören, dass in der nächsten Generation von Bluetooth auch so ein Feature für "autonomen Transfer" eingebaut werden soll, das sogar im ausgeschaltenen Zustand aktiv bleibt und so eine komplette Fernbedienung
aller Rechnerfunktionen per Funk erlauben soll, im Rahmen einer Erweiterung des "OnNow"-Konzepts.
Da kann man nur da sitzen und hoffen, dass da nicht auch solche Hintertürchen vorkommen, denn USB-Ports könnte man ja noch mit den guten alten
mechanischen Schlössern absichern, die es in ähnlicher Form ja schon für Diskettenlaufwerke gab. Aber Funkschnittstellen.....hmmm. Das wird dann echt schwierig. Vor allem wenn man sie nicht mehr abschalten darf, weil man seinen Rechner sonst gar nicht bedienen kann...
Wie sagen die Chinesen so schön: "Mögest du in interessanten Zeiten leben".
Wie wahr, wie wahr.
