20. Januar 2013 13:37

Re: Die Chinesen wissen schon...

memger schrieb am 17. Januar 2013 22:09

> das ist richtig; aber GCC / Linux hat keinen vtable
> Schutzmechanismus. Das hab ich dir aber auch schon vor 5 Posts
> gesagt.

Und weil alle anderen Punkte schon gefallen sind, klammert man sich
am letzten fest. Ich fürchte aber, auch der bleibt möglicherweise
nicht bestehen. 

Erstens soll besagter Schutz ja gerade dann greifen, wenn andere
Schutzmechanismen schon versagt haben (der Angreifer wütet ja schon
am Heap). Das ist also generell schon mal der falsche Ansatz. Wenn
Stack-Smashing Protector und co. funktionieren, wäre ein
zusätzlicher, expliziter Schutz der vtable ja unnötig, denn die wäre
damit ja schon geschützt.

Und zweitens gibts selbst da Entwicklungen bei gcc. Bald wohl mit
vtable-verify noch eine weitere. Oder auch nicht? Keine Ahnung. Noch
ist der Patch wohl noch nicht im Stable Release.

Wie auch immer. Die Liste überragender Punkte für Windows 8 ist
mittlerweile gehörig zusammen geschrumpft. Bzw. es ist wie es ist,
wofür sie im Original wohl auch steht: Neue Errungenschaften eines
neun Windows gegenüber einem älteren. Und eben keine Liste toller
Punkte, in denen Windows 8 anderen OS überlegen ist, auch wenn das
vielleicht in einzelnen Punkten doch der Fall sein sollte. Was sie
jedenfalls völlig außer Acht lässt: Die Punkte, in denen Windows noch
immer Nachholbedarf hat bzw. halt eben in denen andere OS überlegen
sind.

Man stelle sich mal vor, hier würde nicht ein Laie nur auf die
erwähnten Punkte reagieren, sondern ein Fachmann Vorteile auf der
anderen Seite auflisten. 

Was mir aber auch so nach der Aktion klar ist: Hier hat sich ein
"Fachmann", der das Thema sogar zum Beruf hat, als ziemlich
fehlinformiert geoutet.

> kann sein, dass es mittlerweile im Linuxkernel gefixt ist. Als ich
> das letzte Mal geguckt hatte, gings noch wie oben beschrieben.

Nun ja, wenn ich das Dokument aber richtig verstehe, sollte das so
einfach noch nie funktioniert haben. An der Aussage lässt sich also
durchaus zweifeln.
Aber naja, ist ja egal, es kam jedenfalls vor Windows.

> > Natürlich können manche Schutzmaßnamen eine bestimmte Möglichkeit für
> > einen Exploit völlig verhindern. Man könnte es gar 100% sicher
> > gestalten. Das macht nur keiner, weil man dann einen

> Nein kann man nicht.

Du meinst wirklich, es gäbe keine Möglichkeit, z.B. Pufferüberläufe
(als eine Möglichkeit für Exploits) in einem bestimmten Programm oder
Programmabschnitt generell zu verhindern? Keine Möglichkeit einer
sicheren Implementierung einer Puffer behandelnden Bibliothek? Keine
Möglichkeit, Pufferlängen (Arraylängen, etc) wirkungsvoll zu
beschränken?
Da ist die Fachwelt aber anderer Meinung, wenn ich das richtig sehe.

> > Marktwirtschaftlichen Nachteil gegenüber der Konkurrenz hat, die halt
> > nur so sicher ist wie jetzt. Daher sind Systeme nicht 100% sicher,
> > weil immer mehr neuer Code hinzu kommt, wie man sicher überprüfen

> Der Grund warum Systeme nicht 100% sicher sind, hat null mit
> Marktwirtschaft zutun. Sollte dann nicht BSD oder Linux sicher (tm)
> sein? 

Warum sollten sie das, wenn sie doch ebenfalls Teil der
Marktwirtschaft sind? 
Auch Linux ist Teil des Marktes und es werden Features implementiert,
die Vorteile am Markt bringen. Das heißt ja nicht einmal, dass Geld
eine Rolle spielt. Es ist eine allgemeine Konkurrenzsituation. Wenn
es mehr Beliebtheit bringt, zwei Features zu implementieren als mit
der gleichen zur Verfügung stehenden Arbeitsleistung ein Feature und
das dafür sicher, dann wird auch dort durchaus ersteres vorgezogen.
Linux ist generell kein akademisches Projekt, das unabhängig von
eventuellen Nutzern ist. Auch wenn das für manch Programmierer
durchaus zutreffen kann. Am Kernel arbeiten mehr Leute bezahlt mit
entsprechendem Auftraggeber als kostenlos in der Freizeit.

Und es hat ja nicht nur marktwirtschaftliche Gründe. Auch in der
Freizeit macht es viel mehr Spaß, viele neue Funktionen möglichst
schnell zu implementieren als am Ende ein völlig konkurrenzlos lahmes
und dennoch schlichtes Produkt zu haben, das dafür aber ein Feature
hat, was beim Kunden eher weniger nachgefragt wird: Sicherheit.
Immerhin kommt der Wunsch jetzt immer mehr, so dass auch die Systeme
immer sicherer werden.
Aber man sehe sich mal die Nachfrage nach OpenBSD (mit eher sicherem
Ruf) an im Vergleich zu anderen BSD oder gar Linux, die teils eher
Featuritis unterliegen. Oder wie sehr das Interesse der Wirtschaft an
seL4 o.ä. ist.

> Hat eher damit zutun, dass man Programmkorrektheit nicht beweisen
> kann etc pp

Natürlich kann man das durchaus. Nur steigt die Zeit, die man dafür
benötigt, halt mit der Problemgröße und auch die Problemklasse ist
wichtig (logarithmisch, linear, polynomial, exponentiell, je nach
Klasse). Aber selbst Probleme in NP oder gar EXP sind ja deshalb
nicht unbeweisbar. Ist die Entscheidungsmenge klein genug, kann man
halt eben doch alle nichtdeterministisch durchraten.

Die Frage ist halt, ob sich das Problem auf eine Komplexität
reduzieren lässt, die praktisch berechenbar ist. Für den Fall
Programmkorrektheit im Sinne von "macht, was es soll", ist das bei
modernen Programmen wohl nicht immer der Fall. Für den Fall "macht
auch bei Fehlerhaften eingaben nichts kaputt" hat man das aber
mittlerweile selbst für so etwas komplexes wie einen OS-Kern
bewiesen:
http://news.cnet.com/8301-1009_3-10310255-83.html
http://tech.slashdot.org/story/09/08/13/0827231/worlds-first-formally
-proven-os-kernel

Und zwischen "macht, was es soll" und "macht immerhin nix kaputt" ist
ein gehöriger Unterschied. Wenn dein Browser auf einer Schadseite vom
System mit der Meldung "wurde aus Sicherheitsgründen beendet"
abgeschossen wird, gehört das sicherlich nicht zu ersterem, aber
durchaus zu letzterem. Allgemein meint man beim "Beweis der
Korrektheit" aber durchaus eher ersteres.

Damit können ganze Systemumgebungen absoluten Schutz bieten. Wenn man
den Fall "schreibe Eingabestrom so lange in einen Puffer unbekannter
Größe, bis ein Nullzeichen kommt" erst gar nicht zur Verfügung
stellt, sondern eben nur Varianten wie "schreibe maximal so viel, wie
der Ausgabepuffer groß ist", dann kann man hier eben keinen
Pufferüberlauf generieren. Das ist zwar keine zwingende Voraussetzung
für ein sicheres Programm, macht die Sache aber einfacher. Es ist nur
so, dass man das bei heute üblichen Systemen eben nicht macht oder
diese eigentlich sicheren Funktionen wiederum auf unsichere
Funktionen zurückgreifen, bei denen das nicht sichergestellt ist
(Bugs in Bibliotheken z.B.).

Anzeige

heise online Themen