Archiv für den Monat: August 2014

IT-Security – Das Nicht-Handeln der Regierungen

Ich bin kein IT-Security-Experte, aber ich frage mich schon, warum bei der IT-Security so rumgeeiert wird.

Ständig wird von Politikern in Sonntagsreden mehr Sicherheit gefordert. Aber die Politik reagiert überhaupt nicht darauf, dass der „Markt“ anscheinend recht gut daran verdient, dass die aktuellen, am meisten verbreiteten Rechnerarchitekturen eher unsicher sind – was nicht so sein müsste.
Aber möglicherweise wissen die meisten Politiker auch gar nicht, dass IT-Unsicherheit nicht gottgegeben, sondern größtenteils Folge unglücklicher früherer Hardware- und Software-Designentscheidungen ist.

Was spricht eigentlich gegen sicherere Prozessoren, Calling-Conventions, und allgemein eine sichere Hardware- und Software-Architektur?

Wenn man sich ansieht, wie die meisten Remote-Exploits funktionieren, so zeigt sich fast immer das gleiche Schema:

Es wird ein Puffer-Überlauf ausgenutzt, um auf dem Stack die Rücksprungadresse so zu ändern, das eingeschleuster oder „missbrauchbarer“ vorhandener Code angesprungen wird, wodurch der Angreife die Kontrolle über den Rechner übernehmen kann. Zusätzlich wird entweder Shell-Code eingeschleust oder mittels „Return Oriented Programming“ konstruiert, in beiden Fällen unter Ausnutzung ungünstiger Eigenschaften des x86-Befehlssatzes, wie z.B. der heute eher nutzlosen NOP-Operation oder der unterschiedlich langen, nicht-alignten Op-Codes. Alles Dinge, die man ändern könnte.

  1. Warum verhindert man die Überschreibbarkeit der Rücksprungadressen nicht durch einen sicheren Befehlssatz, der bei jedem Unterfunktionsaufruf die älteren Bereiche des Stacks per MMU vor Zugriffen aus dem aktuellen Funktionsaufruf schützt, oder durch die Hardware-gestützte Speicherung der Rücksprungadressen auf einem separaten Stack, auf den das laufende Programm gar keinen Zugriff hat? Es ist doch nicht notwendig, dass die änderbaren lokalen Variablen und die eigentlich nicht notwendigerweise zu ändernden Rücksprungadressen in einem vom ausgeführten Programm beschreibbaren Speicherbereich liegen. Ich halte diese Vermischung von lokalen Variablen und quasi „Rücksprungkonstanten“ für einen gefährlichen Designfehler.

  2. Um Code ausführen zu können braucht man entweder einen Shell-Code, den man von außen einschleust, oder Techniken wie Return-Oriented-Programming, bei denen man vorhandenen Code zu einem schädlichen Programm zusammenpuzzelt.
    Es gibt Schwächen z.B. in der x86-Architektur, die diese Techniken erleichtern, wie z.B. den NOP-Opcode, oder die Tatsache, dass Opcodes unterschiedliche Längen haben können und nicht an Wort-Grenzen ausgerichtet sein müssen, wodurch man dann Befehls-Sequenzen für das ROP einfacher zusammepuzzeln kann.
    Diese Schwächen könne man in einem auf Sicherheit optimierten Prozessor ausbügeln und damit das Schreiben von Exploits ganz wesentlich erschweren.

Warum passiert nichts?

Es wäre sehr viel möglich, sowohl auf Seiten der Hardware, aber auch beim Betriebssystem, wenn der Wille bestünde, an dieser Stelle etwas zu tun. Hier sollte die Politik sich vielleicht einfach mal trauen, etwas anzuschieben, denn die „freie Wirtschaft“ versagt an dieser Stelle ganz offensichtlich schon seit Jahren. Klar, Sicherheit ist meist kein Verkaufsargument, solange kein Hacker-Angriff erfolgt ist; statt dessen zählen Giga-Herz, Kompatibilität, Tera-Flops, MIPS, SAP-Transaktionen-pro-Sekunde, Leistung pro Watt und vieles mehr.

Auch weil bei Hardware- und Softwarearchitektur immer nur kleine Schritte gemacht werden verdienen sich Kriminelle und „White Hats“ dumm und dämlich, spionieren Geheimdienste Länder aus etc., und die Politik sieht zu und glaubt anscheinend immer noch, dass „das der Markt regeln wird“. Das würde er ziemlich sicher auch, wenn die Politik durch entsprechende Vorschriften und Leitlinien dafür sorgen würde, dass es sich lohnt, sichere Produkte zu produzieren.
Wenn Produkte, die z.B. europäischen Richtlinien für die IT-Produktsicherheit nicht genügten, in der EU nicht verkauft werden dürften oder „Sicherheits-Klasse F“-Aufkleber bekämen, dann würden sich auch die großen US-Konzerne bewegen; wenn nicht Intel und Microsoft, dann vielleicht AMD oder IBM oder die Freunde aus Fernost.
Vielleich würde sogar eine europäische IT-Industrie wiederauferstehen, was nicht unmöglich scheint angesichts der Tatsache, dass immer noch oder wieder Fertigungsstraßen auch für Elektronik in der EU errichtet werden und z.B. der Raspberry Pi in England produziert wird.

Warum reicht der ePerso nicht mal für ein sicheres Mail-Zertifikat?

Wir haben übrigens den tollen elektronischen Personalausweis mit der Möglichkeit der qualifizierten elektronischen Signatur. Aber damit kann man sich nichtmal ein sicheres X.509-Zertifikat für sein Email-Programm erstellen. Was soll die Scheiße?
Es würde die Regierung ein paar tausend Euro und ein Lächeln kosten eine CA aufzuziehen, die X.509-Zertifikate generiert und signiert, wenn man sich mit seinem ePerso authentifiziert hat. Aber was soll’s…

Also, zusammenfassend: Der Zustand der IT-Sicherheit in Deutschland, Europa und der Welt liegt auch daran, dass weder in der Politik noch in der Wirtschaft echtes Interesse besteht, hier etwas zu ändern. Man könnte ziemlich schnell ziemlich viel erreichen, wenn man denn wollte. Apple konnte seine Prozessor-Architektur binnen weniger Jahre von Motorola 68k auf PowerPC auf x86 ändern, und jedesmal Emulatoren für den Betrieb von Altsoftware mitliefern, ohne das sich wirklich jemand darüber beschwert hätte, dass die alten Programme auf dem neuen Prozessor nicht mehr nativ liefen.
Aber in der Windows-Intel-PC-Welt hält man an der Rückwärtskompatibilität zur PC-Steinzeit fest, als wollte wirklich heute noch jemand MS-DOS 3.3 auf seinem Intel i7 laufen lassen können, und als wäre es nicht ein leichtes, die ganze verfügbare Software einfach für eine andere Plattform zu kompilieren, so wie das bei Linux anscheinend sehr gut geht.

Hier gilt es, politischen Druck zu erzeugen, damit IT-Architekturen, die seit 30 Jahren quasi unverändert und rückwärtskompatibel sind, die IT-Sicherheit nicht weiter gefährden.