Thema: C - Inline Assembler: Sicherheitslücke?

[Asso]

Schönen guten Tag,

ich würde gerne wissen wie ein Betriebssystem das C-Programme ausführen kann gewährleistet, dass Inline-Assembler keinen "Unfug" anstellt. Was hindert ein solches Programm daran, mit bestimmten Assemblerbefehlen z.B. den PC zum Absturz zu bringen oder gar Schlimmeres. Assembler soll ja meines Wissens nach alles können was der Prozessor so hergibt.

Braucht man für Inline-Assembler eine spezielle C-Bibliothek?
Ist Inline-Assembler eine Art begrenzter Assembler-Befehlssatz, dass es nicht alle möglichen (auch "bösartigen") Maschinenbefehle ausführen kann?

Ich überlege ob es überhaupt sinnvoll ist ein Betriebssystem, das auf "absolute Sicherheit" ausgelegt ist in C zu schreiben, wenn die Programmiersprache selber nicht sicher ist.

Ich würde mich auch über Links die mit C und seiner Sicherheit zu tun haben freuen. Meine Suche hat leider nichts aufschlussreiches ergeben.

Frohe Ostern!

[iksnagreb]

ich würde gerne wissen wie ein Betriebssystem das C-Programme ausführen kann gewährleistet, dass Inline-Assembler keinen "Unfug" anstellt. Was hindert ein solches Programm daran, mit bestimmten Assemblerbefehlen z.B. den PC zum Absturz zu bringen oder gar Schlimmeres. Assembler soll ja meines Wissens nach alles können was der Prozessor so hergibt.

Ja, Assembler kann alles, was der Prozessor hergibt. Aber ein Programm im Protected Mode läuft normalerweise im Usermode (Ring 3). Im Ring 3 hat man keinen Zugriff auf den vollständigen Befehlssatz. Nicht zugelassene Befehle (z.B. cli) erzeugen dann einen General Protection Fault.

Ich hoffe damit geholfen zu haben.

[DerHartmut]

Assembler ist das menschlich-lesbare 1-zu-1-Equivalent zu Maschinencode. Der Prozessor führt Maschinencode aus, keinen puren C-Code.

Im Userspace sind etliche Befehle verboten und führen bei Ausführung zu einer Exception, sodass ein Userspace-Programm nicht irgendwelchen Schaden verursachen kann.

Eine per se unsichere Sprache würde ich behaupten gibt es nicht, es liegt eher daran, erfahren der Programmierer mit ihr ist und wie er damit programmiert. C ist keine unsichere Sprache, die Unsicherheit des Programms ergibt sich aus dessen Implementation. Du kannst auch in einer vermeindlich sicheren Programmiersprache logische Fehler in dein Programm einbauen, Usereingaben nicht validieren etc. - das hat nichts mit der Sprache zu tun. Die Sprache kann es dir lediglich einfacher machen, indem sie die weniger Freiheit gibt bzw. geringere Möglichketen etwas falsch zu machen.

Für Inline-Assembler brauchst du keine externe Bibliothek, wohl aber haben verschiedene Compiler einen anderen "Inline-Assembler-Dialekt".

[Asso]

Von den Ringen hab ich schonmal gehört. Ich bin aber davon ausgegangen, dass man das softwareseitig löst... Möglich wäre es ja.

Naja, danke Euch!

[TheThing]

Ich bin aber davon ausgegangen, dass man das softwareseitig löst... Möglich wäre es ja.

Nur bedingt. Wenn du den Anwendern erlaubst Programme in Maschinencode auszuführen, kannst du softwareseitig nicht viel machen. Eine Möglichkeit wäre allerdings nur Programme in Managed Code zu erlauben wie das meines Wissens nach Singularity tat. Das ist dann softwareseitig gelöst und du kannst auf die hardwareseitigen Sicherheitsmaßnahmen größtenteils verzichten, theoretisch brauchst du noch nicht einmal mehrere Adressräume. Allerdings hat das den Nachteil dass jegliche Software in Managed Code sein muss, d.h. es wird sich vermutlich nicht viel auf das OS portieren lassen.

[DerHartmut]

Die Notwendigkeit von solch "Managed Code" erschließt sich mir persönlich nicht sonderlich, x86-Prozessoren bieten ja "fast alles" um solche Eskalationen den Wind aus den Segeln zu nehmen. Lediglich hinsichtlich sonsitger Einfalltore wie Buffer Overflows o.ä. könnte das ganz sinnvoll sein. Ich mein, Singularity wurde auch aufgegeben, da sich die Managed-Code-Variante nicht sehr rentiert hat, das meine ich aber nur mal so gehört zu haben, bin mir da nicht sicher.

[TheThing]

Ich selbst bin auch kein großer Freund von Managed Code, solte man jedoch (aus welchen Gründen auch immer) auf die hardwareseitigen Sicherheitsmechanismen verzichten wollen ist das meines Wissens nach die einzige Möglichkeit Unfug zu unterbinden. Ich würde jedoch stets dazu raten sich mit den harwareseitigen Sicherheitsmechanismen abzufinden, der Aufwand den man betreiben muss bis etwas zufriendestellend läuft ist bedeutend geringer und man hält sich die Möglichkeit des Portierens von Software offen.

[Svenska]

Hallo,

managed code ist zwar toll, aber schützt gegen Maschinencode-Angriffe nur begrenzt, wie man an den diversen Sicherheitslücken in Java oder anderen Hypervisoren sieht. Das einzige, was Bugs in Software zuverlässig verhindern kann, ist Hardware; alles andere sind Mitigationstechniken.

Deswegen ist jetzt in x86 (und demnächst auch in ARM) auch Hardwareunterstützung für Hypervisoren/Hardwarevirtualisierung drin. Es wird nicht mehr lange dauern, bis Anwendungen ihr eigenes Betriebssystem bekommen werden (aktuell Xen, KVM, VMware - demnächst ChromeOS). Speicher ist billig.

All das ist aber unabhängig von der Programmiersprache, denn im Endeffekt muss irgendein Programm auf der realen CPU laufen.

Gruß,
Svenska