Arbeitsspeicher über Firewire auslesbar und manipulierbar, ohne Einloggen?

[Noether]

In der aktuellen c't steht auf seite 58 unten links, das es unter jedem Betriebssystem möglich ist mit irgendeinem gefakten Firewire-Gerät DMA-Zugriff auf den gesammten Arbeitsspeicher zu erlangen.
Darüber kann man sich auch ohne Passwort einloggen.

Aber soweit ich weiß, ist die MMU genau dafür da, sowas zu verhindern und das DMA, das nicht beim Booten vom BIOS vergeben wird, kann ansonsten nur über einen DMA-Controller, der nur von einer CPU programmiert werden kann, gemacht werden (sonst würden sich ja verschiedene Geräte um Speicher streiten und eine Synchronisation von Prozessen nicht möglich).

Wie also soll ein Angriff über Firewire funktionieren können? :confused:

[zyrusthc]

http://www.fscklog.com/2008/02/schwachstelle-a.html

Greeez Oli

[MiGo]

zyrusthc:
Das hat ja mal mit der Anfrage gar nix zu tun - ganz andere Baustelle.

@Noether:
Die DMA (direct memory access)-Fähigkeit von Firewire steht afaik schon in den FW-Spezifikationen drin.
Und meines Wissens wird FW unter Openbsd ab und an zum Kernel-Debuggen von einer anderen Maschine aus verwendet.

[Noether]

zyrusthc:

Die DMA (direct memory access)-Fähigkeit von Firewire steht afaik schon in den FW-Spezifikationen drin.
Und meines Wissens wird FW unter Openbsd ab und an zum Kernel-Debuggen von einer anderen Maschine aus verwendet.

Aber es kann doch wohl nicht sein, das von Außen irgendein Prozess auf den Arbeitsspeicher beliebig zugreift; damit würde sich ja jedes Betriebssystem erübrigen; da könnte man auch die MMU einsparen und hätte Verhältnisse im Rechner wie vor 1950.

[SirSydom]

Holla, da gehts doch um diese Adam Boileau Geschichte, oder?
(http://storm.net.nz/projects/16)

Nach meinem Verständnis ist es Bestandteil der Spezifikation von Firewire dass auf den gesamten Speicher zugegriffen werden kann. Realisiert wird das per Treiber, und der sitzt ja im Betriebssystem.. Sprich wenn der Programmierer dem Treiber die Macht gibt den Memory zu schreiben und zu lesen, dann kann er das auch. Der Treiber ist eben kein "irgendein Prozess"..

It's not a bug, it's a feature!

(Ich weiß schon warum meine 1394 Schnittstellen immer deaktviert sind!)

[Noether]

Ok, ich habe es auch hier gefunden, mit einer Seminararbeit zum Thema, von vor einem Jahr:

http://eh2008.koeln.ccc.de/fahrplan/events/2466.de.html

Das man die MMU so einfach umgehen kann, halte ich für einen Design-Fehler, aber der PC hat ja viele davon; das merkt man schon daran, das man nicht einfach Karten reinstecken kann, sondern häufig mit der Reihenfolge experimentieren muß und das manche Kombinationen überhaupt nicht funktionieren.

[Noether]

Nachtrag: Die Lösung ist nach der Studienarbeit den Treiber ohci1394 ohne DMA-Support zu laden (Option "phys_dma=0") oder überhaupt nicht laden.