Re: "ProPolice-Stackschutz" auch bei FreeBSD?

From: Christian Weisgerber <naddy(at)mips.inka.de>
Date: Fri, 2 May 2003 14:27:19 +0000 (UTC)

Peter Ross <Peter.Ross(at)alumni.tu-berlin.de> wrote:

> An Olli zum Ursprungsthema (sorry, da war mein Delete-Knopf zu schnell
> gedrückt) - das eine Schutzmaßnahme nicht perfekt ist, halte ich nicht für
> ein Argument, darauf ganz zu verzichten. Ist ja auch nur ein Baustein zu
> einem sicheren System.

Und so ist das auch bei OpenBSD. Seit 3.2 werden dort eine Reihe
von Maßnahmen implementiert, um das Sicherheitsproblem Pufferüberlauf
in den Griff zu bekommen. Das wird von beiden Seiten angegangen.
So gibt es das anhaltende Unterfangen, im gesamten Basissystem
gefährliche Funktionen (strcat, strcpy, strncat, strncpy, sprintf)
durch sichere (strlcat, strlcpy, snprintf, asprintf) zu ersetzen.
Auf der anderen Seite soll die Ausnutzung von Pufferüberläufen so
schwierig wie möglich gemacht werden. Dazu gehören Propolice, ein
(per Default) nicht ausführbarer Stack, Detailarbeiten am Executable-
Layout und W^X. Letztere sollen sicherstellen, dass Speicherbereiche
entweder schreibbar oder ausführbar, aber niemals beides sein können.

Man kann sich jetzt zurücklehnen und sagen, dass das ja alles nur
Flickschusterei ist, und ein richtige Lösung, wie die Verwendung
von Programmiersprachen mit eingebauten dynamischer Speicherverwaltung,
viel besser wäre. Es gehört aber nicht viel dazu vorherzusagen,
dass auf absehbare Zeit diese richtige Lösung nicht kommen wird,
und wer steht inzwischen besser da?

> Allerdings habe ich den gcc-Patch noch nie benutzt und weiß nicht, wie
> sauber das läuft. Wenn der erzeugte Code buggy ist und das System dann
> abschmiert, ist das ja auch nicht so toll.

Propolice ist in dieser Hinsicht inzwischen ziemlich stabil.

Das war nicht immer so. Ich war einer der ersten Leute bei OpenBSD,
die Propolice ausprobiert haben, noch bevor es ins System aufgenommen
wurde, und uns sind insbesondere abseits von x86 viele Compiler-
und Laufzeitabbrüche um die Ohren geflogen. Zwar haben sich seinerzeit
schon einige Linux-Distributionen damit geschmückt Propolice
einzusetzen, aber in Anbetracht der Menge an Fehlern, die erst bei
OpenBSD zu Tage gefördert wurden, kann ich das nicht ernst nehmen.

Und natürlich hat Propolice auch den einen oder anderen bis dahin
unbemerkten Pufferüberlauf aufgespürt.

> Daß es bei OpenBSD nun Default ist, erzeugt bei mir ein gewisses Vertrauen
> darin.

Und die Zahl der -fno-stack-protector in den Makefiles hält sich
sehr in Grenzen. In den Ports ist KDE ein prominenter Fall, wobei
es noch nicht gelungen ist herauszufinden, ob der eigentliche Fehler
bei KDE, Propolice, oder sonstwo liegt.

> Und es sieht erst einmal auch für FreeBSD plausibel aus - gcc patchen und
> dann das System damit kompilieren und schon habe ich eine
> Angriffsmöglichkeit weniger.

Ich habe die entsprechende Anleitung nicht gelesen, aber ganz so
einfach kann es nun doch nicht sein. Propolice benötigt eine Funktion,
die aufgerufen wird, wenn ein Stacküberschreiben bemerkt wird. In
Etohs ursprünglichen Patches war diese Funktion in libgcc, was heute
immer noch so sein mag. Da diese Funktion aber auch auf typischerweise
in libc definierte Funktionen zurückgreift, handelt man sich damit
abenteuerliche, wechselseitige Abhängigkeiten ein. Bei OpenBSD ist
dieser Schnipsel daher in die libc gewandert. So oder so ist Vorsicht
geboten bei Code, der nicht in der normalen Laufzeitumgebung
ausgeführt wird: Bootstrap, Kernel, dynamischer Linker. Hier muss
man Propolice abschalten oder Anpassungen vornehmen.

Ich habe seinerzeit mehrfach Systeme mit Propolice aufgerüstet und
es wieder entfernt. Man muss dabei tunlichst die Abhängigkeiten der
einzelnen Komponenten verstehen und berücksichtigen, sonst sitzt
man schnell mit einem System da, das keine Executables mehr ausführen
oder dessen Compiler keine lauffähigen mehr erzeugen kann. Ist mir
aber nur einmal passiert. ;-)

-- 
Christian "naddy" Weisgerber                          naddy(at)mips.inka.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 02 May 2003 - 16:31:37 CEST

search this site