Ist ein hacksicheres OS möglich? [Archiv]

PHuV

2016-11-21, 16:03:15

Aktuell geistert folgende Meldung durch die IT-News:
Kaspersky OS soll nicht zu hacken sein (https://www.computerbase.de/2016-11/betriebssysteme-kaspersky-os/)
Kaspersky: Eigenes Betriebssystem Kaspersky OS soll unknackbar sein (http://www.pcgameshardware.de/Sicherheit-Thema-229955/News/Kaspersky-Eigenes-Betriebssystem-Kaspersky-OS-soll-unknackbar-sein-1213889/)

Aufgrund der nicht sehr ergiebigen Diskussion in Computerbase möchte ich hier ein Diskussion starten:

Ist ein hacksicheres OS möglich?

Ich halte es per se für nicht nicht unmöglich. Wer mit Betriebssystemen intensiv zu tun, hat sehr wohl Ideen, wie man diese sicherer machen kann. Das geht mit relativ einfachen Mitteln:

Reduzierung der Komplexität
Beschränkung von Änderungen
Einschränkungen auf spezielle Anwendungsfelder
Konsequente Einhaltung von Richtlinien in Programmierung und Desgin (z.B Vermeidung von Pufferüberläufe durch entsprechende String- und Speicherprüfung)
Verwendung einer eigenen und bisher unbekannten Programmiersprache
Keine Implementierung von Backdoors und Ausweichzugänge
Keine Einbindung externer Software wie Bilbliotheken usw.
Was spricht dagegen, ein sich selbst repararierendes OS zu schaffen?
http://i.imgsafe.org/7c445d2f9e.gif
uvm, was mir noch einfallen würde
:

Wenn man dann noch die Freiheit hat, auf gängige Kompatbilitäten zu pfeifen, kann sehr wohl ein nahezu unhackbares OS zu schaffen.

Sven77

2016-11-21, 16:11:54

lumines

2016-11-21, 16:13:03

Ist eben die Frage, unter welchen Annahmen es sicher sein soll. Selbst der als formal korrekt bewiesene Kernel seL4 ist nur unter der Annahme korrekt, dass die Hardware fehlerfrei ist. Rowhammer hat aber gezeigt, dass das in der Praxis nicht der Fall ist. Trotzdem wird seL4 (oder generell L4) in Relation zu anderen Kerneln vermutlich sicherer sein, einfach weil er formal anhand der Spezifikationen verifiziert wurde.

Solange man nicht definiert, was „sicher“ ist, ist das übrigens eine ziemlich mühselige Diskussion, weil darunter jeder etwas anderes versteht. Je nach Kontext können die Ziele auch vollkommen unterschiedlich sein.

Verwendung einer eigenen und bisher unbekannten Programmiersprache

Keine Implementierung von Backdoors und Ausweichzugänge

Keine Einbindung externer Software wie Bilbliotheken usw.

Warum überhaupt? Der erste Punkt ist doch klassisches Security through Obscurity und der dritte Punkt ist so pauschal doch auch überhaupt nicht gültig. Soll ich meine eigene TLS-Library schreiben und damit auf die Nase fliegen? Was habe ich dadurch gewonnen?

Und keine Implementierung von Backdoors muss ja nicht bedeuten, dass ich das selbst implementieren muss. Gab es nicht schon Compiler, die selbst Backdoors eingebaut haben? Da ist meine Implementierung ja vollkommen egal, weil ich darauf keinen Einfluss habe, wenn ich nicht auch den Compiler kenne.

Ganon

2016-11-21, 16:19:44

Wenn man die Komplexität immer weiter runterschraubt, dann ist es auch kein Problem ein unknackbares System zu schaffen. Ist ja nicht so als wäre KasperskyOS das erste seiner Art. Siehe z.B. auch https://sel4.systems/

Auch andere Microkernel-basierte Systeme haben im _Grundkonzept_ (also nichts zusätzliches, sondern es geht einfach nicht anders) ein Whitelisting der Möglichkeiten eines Programmes (und hier ist ein Treiber auch nur ein Programm), im Gegensatz zum Blacklisting normaler Sandbox-Systeme.

Man stößt aber schnell auf Grenzen des Ganzen. Hauptsächlich weil mal eben sämtliche Anwendungssoftware umgeschrieben werden müsste. Weiterhin existieren für solche Systeme kaum Treiber und selbst diese müssten dann ähnlich sicher programmiert sein, um "unknackbar" zu sein. Weiterhin beißen sich einige Sicherheitsfeatures mit Performance-Features wie Just-in-Time Compiler.

Es ist hier dann im Endeffekt wichtig einen Spagat zwischen Nutzerfreundlichkeit und Sicherheit zu geben.

Fehlerfreiheit egal welcher Komplexität durch menschliche Entwickler zu verlangen ist Utopie. Dann kommt Software _nie_ raus. Fehlerfreiheit durch Softwarehilfe basiert schon darauf, dass der Erschaffer der Software keine Fehler gemacht hat... geht auch nicht. Versuchen sämtliche Programmfehler nicht ausnutzbar zu machen hat ebenfalls Schwächen in Sachen Nutzerfreundlichkeit.

Letztendlich benutzt man einen Mix aus allem.

PHuV

2016-11-21, 16:25:10

1. Wird es von Menschen entwickelt?
2. Ist es kommerziell?

Wird eine der beiden Fragen mit ja beantwortet ist es nicht sicher. Werden beide Fragen mit ja beantwortet ist es potentiell unsicher. Gilt auch für andere Dinge wie AKWs usw.
Ich würde es nicht ausschließen, daß Menschen sehr wohl ein System schaffen können, auf das sie selbst verändernd nicht mehr zugreifen können, ohne das System dann komplett zu zerstören, so daß es gar nicht mehr geht. Ob das wiederum sinnvoll ist oder nicht, ist eine andere Frage. ;)

Ein großes Problem sind ja immer die undokumentierten Zweizugänge, die Backdoors, um ein Notzugriff zu haben, für Wartungszwecke usw. Aber das habe ich ja in meiner Punkteliste ausgeschlossen.

Ganon

2016-11-21, 16:26:31

Und wer gerne mal ein halbwegs benutzbares, deutlich sichereres Betriebssystem ausprobieren will, der kann sich ja mal gerne OpenBSD angucken. Wer sich dann aber wundert, dass sein PC im Randfall nur noch knapp 1/10 der Performance hat... das liegt nicht an inkompetenten Programmierern, sondern schlicht daran, dass die Sicherheit so dermaßen hochgeschraubt ist, dass dort Sachen durch mehrere Prüfungen laufen, die bei anderen Betriebssystemen einfach ausgeführt werden.

PHuV

2016-11-21, 16:29:59

Wenn man die Komplexität immer weiter runterschraubt, dann ist es auch kein Problem ein unknackbares System zu schaffen. Ist ja nicht so als wäre KasperskyOS das erste seiner Art. Siehe z.B. auch https://sel4.systems/
:
Man stößt aber schnell auf Grenzen des Ganzen. Hauptsächlich weil mal eben sämtliche Anwendungssoftware umgeschrieben werden müsste.
:
Es ist hier dann im Endeffekt wichtig einen Spagat zwischen Nutzerfreundlichkeit und Sicherheit zu geben.
Sehe ich auch so. Ich habe ja nicht die Frage gestellt, ob das System dann gut zu bedienen sei oder sonstwas, sondern es ging nur um "unknackbar" mit den aktuellen und bekannten Mitteln. Das halte ich - wie Du - für sehr wohl möglich. Ob das System dann auch gut anwendbar ist, ist wieder eine ganz andere Frage. ;)

Fehlerfreiheit egal welcher Komplexität durch menschliche Entwickler zu verlangen ist Utopie. Dann kommt Software _nie_ raus. Fehlerfreiheit durch Softwarehilfe basiert schon darauf, dass der Erschaffer der Software keine Fehler gemacht hat... geht auch nicht. Versuchen sämtliche Programmfehler nicht ausnutzbar zu machen hat ebenfalls Schwächen in Sachen Nutzerfreundlichkeit.
Fehlerfreiheit ist ja auch nicht gefordert, und ein fehlerhaftes System ist auch nicht widerspruchsfrei zu unknackbar. Wenn sichergestellt werden kann, daß Fehler im System keine Zugriff auf relevante Komponenten erlauben, können noch so viele Fehler im System existieren, es stört nicht.

lumines

2016-11-21, 16:30:43

Ich würde es nicht ausschließen, daß Menschen sehr wohl ein System schaffen können, auf das sie selbst verändernd nicht mehr zugreifen können, ohne das System dann komplett zu zerstören, so daß es gar nicht mehr geht. Ob das wiederum sinnvoll ist oder nicht, ist eine andere Frage. ;)

Genau das ist übrigens die Secure Enclave von Apple. Physisch kann man die nicht modifizieren, ohne sie zu zerstören. Auf der SE läuft L4 als Kernel.

Fehlerfreiheit ist ja auch nicht gefordert, und ein fehlerhaftes System ist auch nicht widerspruchsfrei zu unknackbar. Wenn sichergestellt werden kann, daß Fehler im System keine Zugriff auf relevante Komponenten erlauben, können noch so viele Fehler im System existieren, es stört nicht.

Ist das wirklich so? Eine Sandbox fängt auch viele Sicherheitslücken ab, aber die Sandbox selbst hat auch wieder eine gewisse Angriffsfläche. Praktisch erreicht man damit meistens ja eine relativ hohe Sicherheit, aber unknackbar?

PHuV

2016-11-21, 16:32:36

Genau das ist übrigens die Secure Enclave von Apple. Physisch kann man die nicht modifizieren, ohne sie zu zerstören. Auf der SE läuft L4 als Kernel.
Ich habe leider noch nicht auf iOS und Co. entwickelt, und hab hier keinerlei Erfahrungen, deshalb mal blöd gefragt, wie funktionieren dann die ganzen Jailbreaks?

lumines

2016-11-21, 16:37:16

Ich habe leider noch nicht auf iOS und Co. entwickelt, und hab hier keinerlei Erfahrungen, deshalb mal blöd gefragt, wie funktionieren dann die ganzen Jailbreaks?

Meistens über die Software in iOS. Damals™ gab es einmal einen Remote Exploit über FreeType (die Schriftbibliothek). Da hat das Aufrufen einer Webseite in Safari ausgereicht, um Root-Rechte zu erlangen. Da waren noch mehr Exploits involviert, aber grundsätzlich ist Software ja immer sehr anfällig, wenn sehr viele oder sehr komplexe Dateiformate geparst werden müssen.

Fun Fact: OpenType (das Schriftformat) ist sogar turing-vollständig.

Übrigens auch kein Zufall, dass immer wieder die libpng oder imagemagick schwere Sicherheitslücken enthalten. Auch der Mediaserver von Android hatte mit Stagefright große Probleme. Komplexität hat eben seinen Preis. Da kann man dann nur drum herum arbeiten, z.B. hat Android jetzt einige Maßnahmen ergriffen, um den Mediaserver besser vom restlichen System zu isolieren.

Hat auch seine Gründe, warum der PDF-Viewer von Mozilla in JavaScript geschrieben ist und dort einige Teile der Software neu in Rust geschrieben worden sind. Manche Programmiersprachen sind einfach besser für bestimmte Dinge geeignet als andere, aber das hat nichts damit zu tun, dass die Programmiersprachen niemand sonst kennt. Das sind einfach harte Fakten, wenn man mit manchen Programmiersprachen gewisse Fehlerklassen praktisch ausschließen kann.

Argo Zero

2016-11-21, 17:01:11

Wie schaut es eigentlich mit diesen "HW Exploits" aus. Wenn die Software dicht ist, kann man trotzdem über diesen Exploit Dinge machen, die eigentlich nicht vorgesehen waren?

Ganon

2016-11-21, 17:22:30

Wie schaut es eigentlich mit diesen "HW Exploits" aus. Wenn die Software dicht ist, kann man trotzdem über diesen Exploit Dinge machen, die eigentlich nicht vorgesehen waren?

Wurde hier ja schon angesprochen. Rowhammer ist sowas. Da kann das OS nicht mehr machen als es zu erschweren, solange bis der Hardwarefehler behoben ist.

Gänzlich ausschließen kann man halt nichts.

d2kx

2016-11-21, 17:55:29

Wenn keine eigenen, nativen Anwendungen ausgeführt werden sollen und es sich um ein Gerät für Endanwender handelt:

Chrome OS.

Wenn eigene, native Anwendungen ausgeführt werden sollen, z.B. als IoT-Lösung:

Ubuntu Core und vergleichbare Systeme kommen den Anforderungen schon am nähesten. Im Kernel ausschließlich Treiber für die jeweils benutzte Hardware shippen, read-only base system, snaps, die in der Sandbox laufen, ... natürlich ist das nicht "hacksicher", aber letzteres impliziert, dass Netzwerkfähigkeiten vorhanden sein sollen, und ab dann lässt sich Komplexität (je nach Definition) kaum noch vermeiden.

Dass das Verwenden von nicht erforschten Programmiersprachen und das Neuschreiben von elementaren Funktionen, wie sie etwa etablierte Bibliotheken mit TLS-Implementationen o.ä. bereitstellen, ein großes Risiko darstellen würde, sollte klar sein.

Ganon

2016-11-21, 20:10:01

Nein. Solange so ein großer Klumpen wie Linux unter der Oberfläche läuft, dann hilft alles nichts. Natürlich kann man auch ein Netzwerksystem bewiesen sicher implementieren. Das darf dann aber auch nicht 100000 Features haben, sonst wird das beweisen schwierig.

Android ist vom Konzept her auch sehr sicher. Dort wird auch so ziemlich alles aufgefahren was Linux an Sicherheitsfeatures hat. Aber hier ist, wie bei all den IoT Geräten auch: Fehlende Updates, selbst geschriebene, minderwertige Bibliotheken, etc.

Außerdem ist der Begriff Sicherheitslücke auch ziemlich weit gedehnt. Es muss nicht unbedingt immer direkt in root-Access bis in den Kernel enden. Es reicht auch schon wenn der Browser ne Lücke hat und man dort Programme mit Nutzerrechten einrichten kann. Stichwort Botnetz. Außerdem kann man so auch sensible Informationen raustragen.

Als Beispiel mal Heartbleed bei OpenSSL. Dort wurde keine Sicherheitslücke auf Kernel-Ebene ausgenutzt, sondern bloß die Arbeitsweise von OpenSSL so verbogen, dass OpenSSL selbst die Daten rausgereicht hat. Darum funktionierte der Angriff auch unter OpenBSD. Ganz einfach weil OpenSSL aus Performance-Gründen selbst mehr Speicher allokierte und selbst verwaltete. Hätte man das z.B. OpenBSD überlassen wäre die Lücke unter OpenBSD nicht ausnutzbar gewesen.

Gerade wenn man so arbeitet wie OpenSSL es tut, dann hilft auch die sicherste Programmiersprache nicht. Das Problem liegt da auf einer ganz anderen Ebene.

lumines

2016-11-22, 12:09:50

Gerade wenn man so arbeitet wie OpenSSL es tut, dann hilft auch die sicherste Programmiersprache nicht. Das Problem liegt da auf einer ganz anderen Ebene.

Ich meinte auch nur einige bestimmte Angriffsvektoren, nicht alle.

Iruwen

2016-11-23, 20:59:26

StefanV

2016-11-23, 21:16:25

Ja, ist durchaus möglich, wenn mans wollen würde...
Ist aber deutlich aufwändiger und damit teurer als es nicht zu tun. Und könnte ev. auch etwas Performance kosten.

Dabei darf man eben auch nicht den Ansatz verfolgen das System so sicher wie möglich zu machen sondern man muss davon ausgehen, dass irgendwer irgendwie rein kommen wird.
Und genau hier könnte man z.B. eine virtuelle Angriffsfläche bieten, die für den Gegenüber den ANschein erwirkt, dass er im System drin ist und auch alles machen kann, was er will - aber eigentlich macht er gar nix...

Aber bis das gemacht werden wird??
Oder ob das überhaupt jemand machen wird??

Iruwen

2016-11-23, 21:18:45

Klingt nach Security by Obscurity.

Ganon

2016-11-23, 21:37:04

Honeypots sind jetzt auch nichts Neues. ;)

Wilhelm

2016-11-24, 11:34:38

Ein hacksicheres OS ist sicher möglich. Aber Security through Obscurity ist sicher nicht der richtige Weg. Komplett selbst geschrieben? Das geht immer in die Hose.
Um ein hacksicheres OS zu erhalten müsste man die komplette Codebasis (auch Programme die unter dem OS laufen müssen sicher sein!) einfrieren (und ALLE Fehler beseitigen) und auch die Hardware betrachten. Es wird sehr lange dauern und sehr teuer werden.

PHuV

2016-11-24, 11:37:46

Na ja, Kaspersky bastelt da ja - laut eigenen Aussagen - schon 14 Jahre rum.

lumines

2016-11-24, 12:02:07

Und unter der Annahme, dass die Spezifikation korrekt ist?

Spezifikationen kann man mit formalen Sprachen darstellen. Ich kenne mich damit nicht so aus, aber Wikipedia meint, dass es da Notationen gibt, die auf Zermelo-Fraenkel-Mengenlehre basieren und dann kann man natürlich alles beweisen wie man das in der Mathematik sonst auch macht. Mathematik lässt sich letztendlich ja auch auf ZFC herunterbrechen.

Na ja, Kaspersky bastelt da ja - laut eigenen Aussagen - schon 14 Jahre rum.

Was bei Kaspersky nicht unbedingt bedeuten muss, dass sie es auch 14 Jahre aktiv entwickelt haben. Ihre Webserver liefen bis vor kurzem ja auch noch mit 5 Jahre alten OpenSSL-Versionen mit aktivem SSLv2. :^)

Ehrlich gesagt fände ich es besser, wenn sie ihre Prestige-Projekte einstellen und sich lieber um die Sicherheit ihrer Produkte kümmern würden, die man auch kaufen kann. Manchmal muss man sich schon fragen, ob solche Projekte der Antivirenhersteller einfach nur von ihren eigenen, klaffenden Sicherheitslücken ablenken sollen. Ich will das nicht schlechtreden, aber das Geld für die Forschung an solchen Systemen wäre sicher besser in den Produkten angelegt, die sie aktiv verkaufen und das dringend nötig hätten. Imagepflege kann man dann ja noch immer betreiben.

Wilhelm

2016-11-24, 12:16:41

Na ja, Kaspersky bastelt da ja - laut eigenen Aussagen - schon 14 Jahre rum.
Was das Produkt nicht besser macht. In den letzten 14 Jahren hat sich viel getan.

Rooter

2016-11-27, 16:17:48

Wenn man dann noch die Freiheit hat, auf gängige Kompatbilitäten zu pfeifen, kann sehr wohl ein nahezu unhackbares OS zu schaffen.Da relativierst du es ja schon selbst. ;)

Ich denke 100% hacksicher gibt es nicht. Mag aber sein, dass man 10 Jahre dafür braucht, damit wäre es dann zumindest in Polynomialzeit 100% hacksicher. :D

Fehlerfreiheit egal welcher Komplexität durch menschliche Entwickler zu verlangen ist Utopie. Dann kommt Software _nie_ raus. Fehlerfreiheit durch Softwarehilfe basiert schon darauf, dass der Erschaffer der Software keine Fehler gemacht hat... geht auch nicht. Versuchen sämtliche Programmfehler nicht ausnutzbar zu machen hat ebenfalls Schwächen in Sachen Nutzerfreundlichkeit.THIS!
Fehlerfreiheit ist ja auch nicht gefordert, und ein fehlerhaftes System ist auch nicht widerspruchsfrei zu unknackbar. Wenn sichergestellt werden kann, daß Fehler im System keine Zugriff auf relevante Komponenten erlauben, können noch so viele Fehler im System existieren, es stört nicht.Um das sicherzustellen müsste aber doch zumindest ein (Kern-)Teil des Systems fehlerfrei sein.

MfG
Rooter

DavChrFen

2016-12-04, 22:08:20

Ein bewiesener, fehlerfreier Kernel ist z.b.:
https://www.heise.de/newsticker/meldung/Microkernel-seL4-beweisbar-fehlerfrei-2277750.html

Die Frage ist: Hilft das weiter, weil so ein Kernel ist ja sehr minimalistisch. Also braucht man haufenweise zusätzliches Zeug. Und ob man dann beweisen kann, das jede zusätzliche Softwar auch fehlerfei ist, weiß ich nich.

Außerdem ist beweisbar fehlerfrei != hacksicher.

lumines

2016-12-04, 22:37:08

Ein bewiesener, fehlerfreier Kernel ist z.b.:
https://www.heise.de/newsticker/meldung/Microkernel-seL4-beweisbar-fehlerfrei-2277750.html

Hatten wir schon auf der letzten Seite.

Foobar2001

2016-12-04, 22:51:35

Außerdem ist beweisbar fehlerfrei != hacksicher.
Der Anteil an Hacks die wirklich Fehler in der Spezifikation ausnutzen geht gegen Null. So gut wie alles sind Speicherueberlaeufe [1] und diese sind in bewiesener Software nicht moeglich.

Noch dazu verlangt ein Software-Beweis auch dass man die Spezifikation dem Theorem-Prover bis ins Detail angibt, was es fast unmoeglicht macht corner cases zu uebersehen.

Die Aussage ist also fast vollstaendig falsch. Wenn man nicht gerade ein offenes Scheunentor vor den Augen uebersieht ist bewiesene Software sehr wohl "hacksicher".

[1] https://cve.mitre.org/data/downloads/allitems.html

lumines

2016-12-04, 23:10:53

Die Aussage ist also fast vollstaendig falsch. Wenn man nicht gerade ein offenes Scheunentor vor den Augen uebersieht ist bewiesene Software sehr wohl "hacksicher".

… wenn die Hardware denn auch fehlerfrei ist.

Foobar2001

2016-12-05, 05:42:33

Ich bin nicht der Meinung das es da große Probleme gibt abgesehen von Rowhammer. Wird Zeit das RAM immer ECC hat.

Ganon

2016-12-05, 09:51:10

Intel hat wohl bereits ein Patent auf Rowhammer Aware DRAM oder so. Von daher wird vermutlich eher das kommen als überall ECC RAM. Man will ja noch vom Server-Bereich abtrennen, sonst kauf ja keiner mehr Xeons.

StefanV

2016-12-05, 14:35:43

Wird Zeit das RAM immer ECC hat.
War das nicht vor ganz ganz langer Zeit mal Standard, dass zumindest Parity vorhanden war?

Aber ich gebe dir hier Recht, ECC sollte schon zum Standard werden.

Hat nicht Amazon letztens bewiesen, dass Speicherfehler wesentlich häufiger auftreten als gedacht??

lumines

2016-12-05, 14:50:13

Ich bin nicht der Meinung das es da große Probleme gibt abgesehen von Rowhammer.

Wenn man von „hacksicheren“ Betriebssystemen redet, dann muss das trotzdem auch für die Hardware gelten, wenn man das irgendwie beweisen will. Mit Meinungen kommt man da nicht weit.

Ob das in der Praxis notwendig ist, ist aber auch noch einmal eine andere Frage. Bei AES und Co. geben wir uns auch mit „praktisch unknackbar“ anstatt „perfekt sicher“ wie bei One Time Pads zufrieden. Das macht ab einem bestimmten Punkt einfach keinen Unterschied mehr. Wenn man mehr Ressourcen und Energie aufwenden muss, als die Erde bereitstellt, dann kann man das wohl auch so „praktisch sicher“ nennen.

Vielleicht wäre das bei Betriebssystemen und der darunterliegenden Hardware ähnlich. Vielleicht gäbe es noch Fehler und Sicherheitslücken (Hardware formal zu beweisen stelle ich mir schwierig vor), aber eventuell könnte man zeigen, dass die so selten auftreten, dass es keine praktische Relevanz hat.

Ganon

2016-12-05, 14:54:41

Ich glaube normaler DDR4 RAM hat intern auch noch ein paar Möglichkeiten Fehler zu erkennen. Aber soweit ich das überblicken kann, geht es hier nur um das Erkennen. ECC kann ja zusätzlich noch korrigieren. Zumindest einzelne Bitflips.

Also ein bisschen wird schon in der Richtung getan.

DekWizArt

2016-12-05, 15:43:27

Also ich bin mir sehr unsicher was dieses Kaspersky OS angeht. Dafür sind die bisherigen Infos noch echt zu wenig, die es bisher gab. Dazu halte ich es für sehr unwahrscheinlich das etwas nicht knackbar ist, außer es ist so sehr minimiert in seinen Funktionen, dass es nicht mehr wirklich als OS gelten kann.

Ich bleibe da sehr skeptisch, aber ich freu mich wenn das in freier Wildbahn auftaucht. ;)