Lowlevel
OffZone => Offtopic => Thema gestartet von: SörenK am 22. February 2013, 22:54
-
Ich denke in letzter Zeit über Sicherheit von Betriebssystemen nach und bin zum Schluss gekommen, dass man möglichst weit unten anfangen sollte. Mit unten meine keinen Bootloader oder ähnliches - sondern direkt ein eigenes BIOS zu schreiben oder wenn möglich eine eigene Firmware zu nutzen. Ob das klappt, weiß ich nicht, aber könnte man dieses "OS" noch OS nennen? Schließlich bauen Betriebssysteme auf dem BIOS auf.
Viele Grüße, Sören
-
Schau dir embedded devices, z.B. ARM an. Die Trennung BIOS/Firmware und Bootloader existiert dort nicht. Die Firmware initialisiert die zum Booten benötigte Hardware (CPU, RAM, Bootdevice) und startet das OS. Danach läuft sie nicht weiter und hat keinen Einfluss auf die Sicherheit mehr.
Dieses Gewürge mit halben Betriebssystemen, die später noch weiterlaufen können, wie UEFI (oder auch GRUB) ist PC-spezifisch.
Ein eigenes BIOS für den PC? Vergiss es. Eine eigene Firmware für einen nicht-PC SoC? Machbar. Das schließt x86 nicht aus, IIRC fürs Bifferboard könnte das gut möglich sein. Da ich dich von dem Trip aber nicht runter kriege, verweise ich erneut auf Coreboot und die Vorträge von 25c3 und 26c3.
-
Ja, aber noch sind es nur überlegungen :wink: und die theoretischen Sicherheitsprobleme würde ich ebend gerne entfernen. Und wenn ich das Geschaft habe kann ich immernoch ein OS schreiben :-D
-
Die Sicherheit eines Betriebssystems ist definiert in der Zuverlässigkeit genau das zu tun, für das es eingerichtet wurde. Das Bedeutet es muss möglich sein die passenden Berechtigungen eines Programms festzulegen und dann müssen diese Berechtigungen durchgesetzt werden. Letzteres wird mit steigender Komplexität des Betriebssystems umso schwieriger.
Ein unsicheres Programm wird man dafür zwar noch immer schreiben können, allerdings kommt der Code aus sicht des Betriebssystems von außen, weshalb Bewertungen zur Sicherheit eines Programms nicht trivial sind.
-
Was für theoretische Sicherheitsprobleme? Erwartest du, dass der BIOS-Herstellen dein OS hacken will?
-
Ich meine damit nicht, dass jeder Intelarbeiter oder jeder andere, der Microchips herstellt, entwickelt oder ein BIOS für den Chip entwickelt, zwangsläufig schlechte absichten haben wird. Aber aufgrund der Tatsache, dass der Code nicht Public ist, können dort Hintertürchen eingebaut werden. Und da mein Betriebssystem verdammt sicher sein soll, versuch ich diesen uneinsichtigen Code zu hinterfragen, bzw. versuche gleichguten Code zu entwickeln. Vielleicht mag dies sehr weit hergeholt klingen, aber wenn ich es nicht versuche - wie kann ich dann mein Betriebssystem sicher nennen?
FG, Sören :wink:
-
Stimmt. Das heißt, du solltest vor allem erst einmal den Prozessor selbst bauen. Denn wer sagt dir denn, dass der wirklich das ausführt, was in der Dokumentation steht?
-
Ich denke, dass der Prozessor zwangsläufig das machen muss, was in der Dokumentation steht (falls es überhaupt eine gibt). Aber muss sich ein Prozessor an seine öffentlichen Grenzen halten? Ein weiteres, unbekanntes Register könnte vorhanden sein, über dem das BIOS mit dem Chip kommunizieren könnte, ohne das Betriebssystem einzuschalten. Aber ohne BIOS gäbe es dieses Risiko nicht, und da sind wir wieder bei meinem Thema. Ich selbst finde es ebend Interessant, ein OS von Grund auf zu programmieren. Und die Sicherheit würde ich dadurch gleich mit an Bord nehmen.
LG, Sören
-
Das impliziert, dass nur das BIOS dazu in der Lage ist und lässt die Möglichkeit außer acht, dass außerdem noch dir vollkommen unbekannte Software auf einem versteckten Kern im Prozessor laufen könnte. Oder so.
-
Ja, auch dies ist möglich. Übrigens: Ich habe einen Chip gefunden, bei dem genau dies passiert ist: http://www.activemind.de/hintertur-in-computerchips-entdeckt/
-
Ich habe noch eine Seite mit einem anderen Chip gefunden, der Manipuliert wurde und dadurch ein Sicherheitsleck bekam: http://www.pcwelt.de/news/Chip-Hacker-Manipulierter-Prozessor-oeffnet-Hintertuer-261811.html
-
Ich denke, dass der Prozessor zwangsläufig das machen muss, was in der Dokumentation steht (falls es überhaupt eine gibt).
Muss er nicht. Stichwort "Fehler", "errata" oder auch "silicon bugs". Durchsuche den (Linux-)treiber deiner Wahl und du findest die im Dutzend. Wäre Hardwareherstellung nicht so teuer, würde man die sicher beheben, statt auf Software zu setzen...
Die out-of-band-Kommunikation bei x86 heißt SMM, existiert seit dem 80386SL und ist - wie üblich - eine Spezialität von x86 (und PCs). Andere Architekturen haben das nicht.
-
Ich meine man kann sowas nie komplett ausschließen.
Wenn du wirklich sicher gehen willst, müsstest du eine alte Platine haben,
die noch kein Internet kannten ;) Da hätte sowas auch keinen sinn ergeben.
Und selbst wenn du dein OS auch auf einem eigenen BIOS aufbaust, dann könnte
ein CHIP evt. sogar selbständig kommunizieren, wenn also ein CPU Hersteller z.B.
Daten von dir sammeln will kann er sowas nutzen->>> http://de.wikipedia.org/wiki/System-on-a-Chip
-
Ich zitiere hier einfach mal aus dem Wiki:
Da ich die OS-Modes (Real-/Protectet) nicht ganz ausgereift finde, werde ich einen Vivian-Mode schreiben, in welchem das Betriebssystem den höchsten Rang hat und die Programme, je nach Funktionen, einen geringeren besitzen.
Das sind die Betriebsmodi des Prozessors. Die Firmware hat damit nichts zu tun. Wenn du andere willst, kannst du keinen x86 nehmen. Abgesehen davon bietet der Protected Mode genau diese Trennung von Kernel und Userspace.
Da mein Betriebssystem eine Sicherheit von 100% haben soll, habe ich einiges zum Thema Bootloader, BIOS/UEFI und Firmware gelesen. Heraus kam aber nichts gutes: Wenn ich mein Ziel verwirklichen will, muss ich mindestenst den BIOS/UEFI-Code ändern oder noch besser - die Gesamte Firmware aller Chips ändern.
Was genau sind die Schwachstellen an den existierenden Implementierungen, die du verbessern willst?
Mein Vorschlag wäre ja, dass du erst einmal das OS zu einem gewissen Level schreibst. Bootloader und Firmware kannst du dann immer noch relativ unabhängig machen. Wenn du es hinkriegst, das OS so zu schreiben, dass es eine gewisse Funktionalität hat und trotzdem sicher ist und von uns auch mit Einsicht in den Quellcode nicht gehackt werden kann, dann kannst du darüber nachdenken, dich in Richtung der niedrigeren Ebenen vorzutasten - und wenn nicht, dann würdest du das Vorhandene mit deinem neuen Code nur noch verschlechtern.
-
Dann arbeite ich jetzt an Vivian :-) Man, ich habe nur die Sicherheitslücken gesehen und mich in einiges hineingesteigert, ohne eine gewisse Basis geschaffen zu haben. Sobal Version X fertig ist, werde ich es euch mitteilen!
Und sorry, wenn ich auf gute Kritik falsch reagiert habe - mir ging erst jetzt das Licht auf...
-
Übrigens: Der Real Mode unterstützt tatsächlich keinen Speicherschutz, keine (zuverlässige) Trennung zwischen Betriebssystem und Anwendungsprogramme und jedes Programm kann den Computer zum Absturz bringen oder die CPU anhalten. Er ist also wirklich unsicher. Darum hat Intel schon 1982 (80286) den Nachfolger entwickelt. :-)
Der Protected Mode wirkt an manchen Stellen darum so furchtbar kompliziert, weil er verschiedene Dinge ermöglicht, die es woanders nicht gibt. Das Betriebssystem muss den Anwendungen nicht vertrauen, aber die Anwendung muss auch dem Betriebssystem nicht vertrauen (Call-Gates mit DWord-Count). Du kannst getrennte Adressräume (Segmentierung) haben, die dich vor jeder Form von Stack-Overflow und kaputten Zeigern schützt und bis zu vier verschiedene Berechtigungsebenen verwenden. Das Handwerkszeug ist also vorhanden.
Nur an der Umsetzung wird es scheitern: Call-Gates sind langsam, getrennte Adressräume sind hochsprachenfeindlich und zwei Berechtigungsebenen reichen eigentlich auch. Wenn es einfach wäre, wäre es schon gemacht.
Übrigens schützt dich auch das beste Betriebssystem nicht vor Angriffen auf Gerätetreiber. Und da (DMA-fähige) Geräte jederzeit (sofern keine IOMMU verwendet wird) auf den gesamten Speicher lesend und schreibend zugreifen können,...
Gruß,
Svenska
-
Tja, wer hat lust eine eigene Computerfirma aufzumachen? :wink:
Auf baldige, höchst mögliche Sicherheit, Sören...
-
Den Gedanken einer eigenen Firma habe ich für mich persönlich verworfen - einerseits bin ich nicht kreativ genug, andererseits habe ich wenig Lust, einen Großteil der Zeit mit Buchhaltung und Verwaltung und Juristerei zu verbringen. Vielleicht kommt die geniale Idee, vielleicht auch nicht.
Ansonsten: Wart's mal ab. Wenn die intelligenten Stromzähler in allen Haushalten stecken und dann ein Remote-Exploit gefunden wird, macht's doch eh viel mehr Spaß. Vielleicht fällt den Fachleuten aus der Politik dann auf, dass Infrastruktur nicht angreifbar sein sollte. Wir sind ja hier im OT, da darf ich sowas schreiben.
-
Tja, wer hat lust eine eigene Computerfirma aufzumachen? :wink:
Klar, wie viel Geld hast du? Ich hab 0.
-
Den Fachleuten aus der Politik ist noch vieles andere nicht aufgefallen...
-
Vielleicht ist dies zu persönlich, aber wie verdient ihr euer Geld? Ich z.B. würde gerne einmal Spieleentwickler, Websiteentwickler und/oder Ingeneur werden.
Zum Glück ist es OT :)
-
Vielleicht ist dies zu persönlich, aber wie verdient ihr euer Geld?
FPGA Programmierung. Mein tip: mach Was was dir so sehr Spass macht dass du es sogar umsonst machen würdest. Du wirst es nämlich 50 Jahre lang machen.
-
Vielleicht ist dies zu persönlich, aber wie verdient ihr euer Geld?
Garnicht (Masterstudent embedded devices). Vorher Informationstechnik/Elektrotechnik.
-
Ich mache qemu kaputt und werde dafür bezahlt. ;)
-
Jetzt mal was ganz anderes, wenn man z.B. einen Virus schreiben will, muss man sich mit dem Programm/Betriebssystem besser auskennen als der Entwickler?
-
Wenn man Bugs ausnutzt, vermutlich schon. Sonst hätte der Entwickler die Bugs ja gefixt, wenn er sie kennen würde (okay, das ist optimistisch gedacht, aber tendenziell halt...)
Aber man muss ja keine Bug ausnutzen, wenn man andere Möglichkeiten hat, seinen Code zur Ausführung zu bekommen.
-
Mit unten meine keinen Bootloader oder ähnliches - sondern direkt ein eigenes BIOS zu schreiben oder wenn möglich eine eigene Firmware zu nutzen. Ob das klappt, weiß ich nicht, aber könnte man dieses "OS" noch OS nennen? Schließlich bauen Betriebssysteme auf dem BIOS auf.
Es gibt mindestens ein Betriebssystem(OS 3.9) bei dem sich Teile(Genau die exec, dos, graphics und intuition.library) in einem BIOS besser gesagt ROM(Kickstart) befinden.
Vielleicht ist dies zu persönlich, aber wie verdient ihr euer Geld? Ich z.B. würde gerne einmal Spieleentwickler, Websiteentwickler und/oder Ingeneur werden.
Zur Zeit bin ich auch Student aber das meiste Geld verdiene ich mit SAS Programmierung.
-
Es gibt mindestens ein Betriebssystem(OS 3.9) bei dem sich Teile(Genau die exec, dos, graphics und intuition.library) in einem BIOS besser gesagt ROM(Kickstart) befinden.
Bei allen Heimcomputern der 80er befand sich das vollständige Betriebssystem in einem ROM und war mit dem BIOS identisch. Die Trennung zwischen den fürs Booten notwendigen Hardwaretreibern (BIOS) und dem Betriebssystem wurde erst möglich, als Speicher groß&billig (OS liegt plötzlich im RAM) und Massenspeicher üblich (Tape ist doof) wurden. Darum ist auch das klassische MacOS (zumindest für 68k-Macs) größtenteils in der "Macintosh Toolbox" im ROM implementiert.
Den Begriff "BIOS" kenne ich nur im Zusammenhang mit PCs (Teil des Mainboards) sowie CP/M und DOS (Teil des OS). In anderen Bereichen spricht man von "Firmware", welches genau der Teil ist, der in einem Flash/ROM sitzt und je nach Gerät von Bootloader bis Betriebssystem reichen kann. Die von einem PC-BIOS/EFI geleistete Hardwareabstraktion existiert dort nicht (von dem neuen Windows-ARM-UEFI mal abgesehen).
Gruß,
Svenska
-
Bei allen Heimcomputern der 80er befand sich das vollständige Betriebssystem in einem ROM und war mit dem BIOS identisch.
Beim Amiga 1000 Befand sich der Kickstart auf Diskette und wurde beim anschalten in einen speziellen Speicher(WOM) geschrieben.
-
Aber auch nur, weil die Entwicklung zum Erscheibungszeitpunkt noch nicht rechtzeitig fertig war. Alle Nachfolger hatten Kickstart-ROMs. Ich korrigiere meine Aussage: Alle Heimcomputer der 80er außer der Amiga 1000. :-)
-
Aber auch nur, weil die Entwicklung zum Erscheibungszeitpunkt noch nicht rechtzeitig fertig war. Alle Nachfolger hatten Kickstart-ROMs. Ich korrigiere meine Aussage: Alle Heimcomputer der 80er außer der Amiga 1000. :-)
Aus reinem Spaß an Haarspalterei möchte ich einwerfen, dass es beim Amiga 500 genauso war ;)
-
Nö. Der hatte bereits ein Kickstart ROM (Upgradeanleitung (http://www.vesalia.de/d_kick31_a500.htm)).
-
Nö. Der hatte bereits ein Kickstart ROM (Upgradeanleitung (http://www.vesalia.de/d_kick31_a500.htm)).
Mist, mein müdes Gehirn hat doch glatt Kickstart mit der Workbench verwechselt. Aua. Vielleicht ist es auch einfach zu lange her, dass ich meinen Amiga 500 mal angeschlossen hatte.
-
Jetzt mal was ganz anderes, wenn man z.B. einen Virus schreiben will, muss man sich mit dem Programm/Betriebssystem besser auskennen als der Entwickler?
Wenn ICH einen Virus schreiben wollen würde, würde ich mir zuerst alle Programme und Betriebssysteme vornehmen, die weit verbreitet sind: Web-Browser, Email-Clients, PDF-Reader, Office-Programme sowie Spiele und bei den Betriebssystemen Windows, Linux und Mac OS. Bei den Betriebssystemen würde ich mir vor Allem die Libraries für den Netzwerkstack, Treiber allgemein, Videocodecs und Grafikroutinen vornehmen.
Dann würde ich mir einem Emulator schreiben, der die entsprechende Umgebung simuliert und den Maschinencode des entsprechenden Programms oder der Library ausführen kann. Mit diesem Emulator würde ich für jedes Stück Code analysieren, in welchem Kontext dieses normalerweise ausgeführt wird. Dazu betrachte ich den Callstack, die Parameter und die globalen Variablen. Dann untersuche ich den Code auf mögliche use-after-free, integer-overflows, buffer-overflows und besonders stack-overflows. Überall wo Arrays indiziert oder Puffer verwendet werden reicht eine fehlende Bereichsprüfung um den Stack zu manipulieren. Niemand schreibt Code mit Checks bei jeder Adressberechnung. Format-Bugs lasse ich mal außen vor, die können mit einfachen Mitteln behoben werden.
Mit einem funktionierenden Exploit würde man schon mal in den Usermode kommen. Hier kann man bereits beliebige DLLs patchen, um etwa SSL abzufangen, Mails mitzulesen oder Passwörter zu klauen. Über das Dateisystem lassen sich versendete Dateien oder USB-Sticks infizieren. Aus dem Usermode lässt sich auch sehr bequem ein Dienst einrichten, der sich in den Autostart schreibt und so bei jedem Start geladen wird (bei XP, Win 7 weiss ich nicht genau).
Um vom Usermode zum root zu kommen reicht ein weiterer Overflow in irgendeiner Library oder Treiber. Am effektivsten ist es, Code dort im Kernel zu platzieren, wo er häufig ausgeführt wird. Wenn man es darauf anlegt, kann man auch in dem Bootloader gehen und alles virtualisieren, was eine Entdeckung riskieren würde.
Die Kommunikation würde ich über frei verfügbare Online-Dienste machen und zwar in beliebigen XML-Formaten oder anderen geläufigen Formaten, welche die Kommandos enthalten. Je nach Typ der Schwachstelle kann man über das Netzwerk weitere Computer infizieren oder den Schadcode mit Dateien versenden. Eine Entdeckung durch Virenscanner vermeidet man in der Regel, indem man einen kleinen Compiler für eine rudimentäre Sprache verwendet, der sich selbst und seine Payload in diversen Variationen generieren kann. Eventuell versteckt sich der echte Code noch zwischen einem großen Haufen nutzlosem Maschinencode. Den Exploit an sich kann man auch variieren oder an unterschiedlichen Stellen im Dokument platzieren.
Aber ich bin ja einer von den guten ;-)