[linux-l] Slightly off topic: Jagd auf Spam

Steffen Dettmer steffen at dett.de
So Okt 26 21:38:37 CET 2003


* Jan Krueger wrote on Fri, Oct 24, 2003 at 19:25 +0200:
> On Friday 24 October 2003 17:05, Steffen Schulz wrote:
> > http://web.lemuria.org/security/WormPropagation.pdf
> 
> Mein, in meiner Unwissenheit, nicht ganz ernst gemeinter
> Globaler Neustart mit folgendem Stromausfall ist also durchaus
> realistisch. Ohjehminee, ich glaub die Verantwortung dafür kann
> MS nicht mehr tragen und MS ist somit durch seine eigene Größe
> und Marktmacht dem Untergang geweiht.

Leider kommen vermutlich nur 10% der Anwender und 1% der
Entscheidungsträger ebenfalls zu dieser Erkenntnis...

> Man nehme einen kleinen Micro- oder Nanokernel- (zB. L4, MIT
> Exokernel o.ä.) Prozeß aus einem Execute in Place ROM-Bereich
> und/oder spezielle Hardware welche folgendes tut:

interessante Idee-Mail - fetzt ja :-)

"Execute in Place ROM-Bereich" gibt es in Form von BIOS schon.
Weil ROM so langsam ist, kam man dann zu Shadow :)

> Code Segmente dürfen sich zur
> Laufzeit nicht verändern.
> -Falls diese unterschiedlich sind so hat sich der Code durch, zb. einen wurm, 
> verändert. 
 [...] 

Kann man doch einfacher erreichen: es darf nicht in Code-Bereiche
geschrieben werden, wie Du unten wohl meinst. Macht Sparc, glaub
ich. Auch auf embedded hat man sowas öfter mal, auch wenn der
Code ins RAM kopiert wird.  Weiß nicht, aber vielleicht kann das
sogar ne Standard MMU von einem PC, benutzt vielleicht bloß
keiner?

> -Code im Datenbereich kann nicht ausgeführt werden

Macht Sparc auch, glaub ich. Dazu kommt noch: "Code im Stack draf
nicht ausgeführt werden" (no-exec-Stack).

dynamisches Laden von Bibliotheken muß dann direkt über das
Betriebssystem (kernel space oder was anderes priviligiertes)
gemacht werden - ich glaub, daß ist der Hauptgrund, warum man das
nicht macht.

Ebenso muß das OS sicherstellen, daß Daten- und Codesegmente sich
nicht überlappen (falls man sowas hat) bzw. die virtuellen
Speichertabellen dies nicht tun. Bei i386 geht das ja, man kann
sich seinen Stackpointer auf den Code laden und damit dann Code
"auf den Stack pushen". Na, und andere Kleinigkeiten - geht aber.

Dann muß man sicherstellen, daß die binaries nicht verändert
werden dürfen, da binaries ja in die Orignal-Dateien "geswappt"
werden.

> -besondere Hardwareunterstützung kann zb. durch physikalische Auftrennung der 
> Daten- und Code-Speicher erreicht werden 

Ja, muß ne MMU Funktion sein. Da die ja in die CPUs integriert
sind (glaub ich), müßte das prima gehen.

> Die besondere Eigenschaft des Code-Speichers ist, daß er sich
> nur einmal durch das initiale Laden des Codes nach dem Starten
> des Rechners beschreiben läßt 

Das ist ja blöd - dann kann man ja weder Programme nachladen oder
entladen und braucht so unheimlich viel Speicher. Gut, kenne das
vom Embedded-Bereich, aber für'n PC? Muß man dann bei Booten X,
StarOffice und alle Mailprogramme schon mal laden...

> und danach während der Laufzeit schreibgeschützt ist. Es bedarf
> einer besonderen Behandlung dieses Speicherbereiches (durch zb.
> Anforderung eines Passworts oder explizite Freigabe durch einen
> physikalischen Schalter oder Anwendung eine SmartCard oder
> ähnliches) um ihn erneut beschreiben zu können. 

"Um das Mailprogramm starten zu können, legen Sie die SmartCard
in einen Klasse-3 [das ist einer mit Display und Tastatur] ein".

Der Anwender muß dann prüfen (wie?!), ob es das richtige Programm
ist (secure hash?) - sonst könnte sich ja ein Trojaner über das
Mailprogramm mitladen.

> Oder anders ausgedrückt: Diese Turingmaschine hat 2 Bänder,
> eines für Code, zu Laufzeit read only, eines für Daten, wie
> gehabt.

Dann geht dynmisches Binden gar nicht mehr...

Ich denke, es würde reichen, die Seiten im virtuellen Speicher
eben typisiert zu verwalten: Code, Stack und Daten müßten dann
eben grundsätzlich verschiedene Sachen sein. Der dyna-Lader ist
dann ein (kernel-?) Prozeß. Wenn man das konsequent macht, kann
ein User keinen eigenen Code mehr starten, nur noch systemweite
Programme - damit kann ein User dann keinen Code mehr ändern und
ausführen, nur noch "das System" (was auch immer das jetzt mal
genau sein wird). Natürlich darf dann kein Dienstprogramm mit
diesem hohen Berechtigungslevel arbeiten.

> -alternativ befindet sich Code grundsätzlich in einem (Flash-)ROM und ist 
> daher zur Laufzeit nicht manipulierbar und darf/kann auch nur in diesem 
> Bereich via Execute in Place ausgeführt werden.

Wird langsam, oder?

> -Wenn man also dem System auszuführenden Code hinzufügen möchte, muß das 
> System in einen besonderen Installationsmodus versetzt werden, welcher den 
> Transfer von Code aus dem Datenbereich ind den (Flash-)ROM Bereich erlaubt 
> und nichts anderes.

Also wieder mit z.B. SmartCard oder Schalter am Gehäuse, ja?

> Daraus wird ersichtlich:
> -Solange der Code noch nicht geladen ist, ist er wie Daten zu betrachten und 
> weiterhin manipulierbar.
> -Code laden bedeuted: Transfer vom datenbereich in den Codebereich (daher hat 
> Turing wohl auf das 2te Band verzichtet) und ist daher gesondert abzusichern

Na ja, dann mußte ja eben auf dem Klasse-3 Leser die Prüfsumme
anzeigen, der Benutzer muß die in einer Liste der vertrauten
Anwendungen nachsehen, um zu erkennen, ob jemand versucht,
manipulierten Code zu laden. Du hast aber Recht, selbst wenn man
das nicht macht, funktionieren gegenwärtige Cracks nicht mehr
gut (glaub ich) - wenn es aber alle "haben" gibt's dann auch
Cracks dafür :)

> -Wir brauchen alle mehr Speicher und/oder Flash-Speicher.

Sowieso, oder? :)

> -existierende Sicherheitsprobleme lassen sich ohne eine änderung der 
> architektur ( Software und/oder HW ) nicht lösen

Es gibt solche Architekturen. Mit einer gut implementierten JVM
z.B. sollte das schon nicht mehr gehen. Gleiches gilt für Ada und
viele andere. 

> -TCPAbla könnte obiges Checksumming Verfahren unterstützen? Keine Ahnung. 
> womöglich nicht. TCPAbla ist sinnlos?

TCPA (oder wie das heißt) ist sogar mehr: der Code muß signiert
sein, so daß man nicht alle Prüfsummen kennen muß - man kann dann
ausrechnen, ob die stimmen. Für Hardware-Sicherheitsmodule eine
gängige Praxis mindestens beim Update: lade nur signierten Code.

Denke, wenn man nur signierten Code laden kann und einer Deiner
Verfahren verwendet, müßte das schon reichen. Allerdings finde
ich den Preis ziemlich groß: möchte so ein System nicht im Büro
adminstrieren müssen, wird bestimmt sehr sehr aufwendig und damit
teuer. Also kauft's keiner: billig muß es sein, Funktion ist kein
Verkaufsargument heutzutage...

> Call for Investors:
> Wenn jemand das nötige Geld sponsort implementier ich gerne einen derart 
> sicheren Rechner :)

Du kannst sowas auch einkaufen, gibt's ja. Wird vermutlich teuer
für ein Server-System. Bei signierter Software wünsche ich mir
dann natürlich, daß per Policy nur das signiert werden darf, was
ein Sicherheitsgutachten erhalten hat. Die Software für ein sehr
einfaches Bürosystem kann man vermutlich mit wenigen Millionen
Euro Kosten zertifizieren lassen :-)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.




Mehr Informationen über die Mailingliste linux-l