Qbi's Weblog

Um die auch hier angesprochene OpenSSL-Lücke wird zwischen den OpenSSL-Team und Debian eine Diskussion geführt. Der Paketbetreuer von Debian fragte damals auf der Liste openssl-dev nach und Ulf Möller, einer der Entwickler, antwortete. Die OpenSSLer behaupten nun, es sei die falsche Liste gewesen und die Debianer haben darauf eine großartige Antwort.

Kürzlich meldete sich Ulf Möller nochmal zu Wort. In seiner Antwort auf die Frage ging er nicht davon aus, dass der Quellcode gepatcht werden soll und dass sein Gegenüber natürlich grundsätzlich ein Verständnis für den Quellcode entwickelt hat. Aus der Diskussion entwickelte sich das schöne Zitat:

Und jetzt komme ich mir vor wie ein Arzt, der dachte, dass er mit einem Kollegen über Operationstechniken diskutiert hat, und nun plötzlich erklären soll, wieso er das Kettensägenmassaker nicht verhindert hat.

Über die schwere Sicherheitslücke im OpenSSL-Paket von Debian wurde in verschiedenen Quellen berichtet. Wer mehr Informationen haben will, findet im Debian-Wiki Anweisungen. Außerdem stehen bei Zak B. Elep Hinweise und HD Moore stellte auch eine nette Seite zusammen. Doch was bedeutet diese Lücke für Tor? Gibt es da überhaupt Probleme?

In der Tat gibt es da richtig große Probleme, wie auch das Advisory zeigt. Tor nutzt für seine Krypto sehr intensiv OpenSSL und ist damit direkt betroffen. Roger Dingledine, einer der Entwickler, hat in einem längeren Artikel im Blog zu Problemen Stellung genommen.

Eines der entstandenen Probleme sind Tor-Server, die schwache Schlüssel einsetzen. Insgesamt handelt es sich um mindestens ein Siebtel aller Server. Angreifer können hier alle möglichen Attacken fahren und insbesondere auch unten bestimmten Bedingungen in die Pakete schauen. Effektiv wird also die Verschlüsselung aufgehoben. Die Tor-Entwickler haben daher alle derartigen Schlüssel gesperrt und ein Server mit einem veralteten Schlüssel kann in Zukunft nicht mehr als Server agieren.

Weiterhin verteilen Verzeichnisserver die Informationen über Tor-Server an die Tor-Clients. Die neueste Protokollversion ist die V3. Wer dies nutzt, könnte ein Problem bekommen. Hier schafft die neueste Tor-Entwicklerversion 0.2.0.26-rc Abhilfe. Dort werden ausschließlich korrekte Schlüssel ausgeliefert und die schwachen sind gesperrt.

Peter Palfrader hat sehr schnell reagiert und eine neue Version des Debian-Paketes hochgeladen. Wenn du also Debian, Ubuntu oder ähnliches nutzt, solltest du schnellstens die aktuellste Version installieren, um dich vor den obigen Problemen zu schützen.

Ich hatte auf meinem Laptop seit einiger Zeit ein Ubuntu installiert und kürzlich war ich der Meinung, dass er mal eine andere Distribution benötigt. Zum einen war kürzlich grml in der Version 1.1 erschienen und wollte getestet werden, andererseits hatte ich früher Gentoo und damit war ich damals auch zufrieden.

grml bringt das Programm grml2hd mit. Damit lässt sich die Live-CD auf die Festplatte bringen. Die Installation selbst ist recht einfach. Es wird nach der Partition und dem Dateisystem gefragt, Nutzer angelegt etc. In kürzester Zeit war das System installiert und ich konnte es nutzen. Doch es dauerte nicht lange und ich bemerkte, dass der Rechner beim Runterladen großer Dateien langsam wurde. Ein Blick auf die DMA-Einstellungen bestätigte den Verdacht, dass kein DMA eingeschalten ist. Es liess sich nicht aktivieren und dmesg zeigte:

ata_piix 0000:00:1f.2: version 2.12
ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ]
PCI: Unable to reserve I/O region #1:8@1f0 for device 0000:00:1f.2
ata_piix 0000:00:1f.2: failed to request/iomap BARs for port 0 (errno=-16)
PCI: Unable to reserve I/O region #3:8@170 for device 0000:00:1f.2
ata_piix 0000:00:1f.2: failed to request/iomap BARs for port 1 (errno=-16)
ata_piix 0000:00:1f.2: no available native port

Spätere Tests ergaben, dass das ein “grml-Problem” ist. Ich konnte den Effekt bei keiner anderen Live-CD (Debian, Gentoo, Knoppix, Ubuntu) feststellen. Eine Idee war noch, einen anderen Kernel zu installieren. Gesagt, getan. Doch nach einem Reboot begrüsste mich die Meldung GRUB. Also wieder die Live-CD eingeworfen und mittels grub-install den Rechner wieder bootfähig gemacht. Mika gab mir noch einen Tip, einen Blick auf /etc/kernel-img.conf zu werfen. Doch selbst mit einer angepassten Konfiguration ging das schief.

Daneben gab es noch kleinere Probleme und ich entschied mich, mit Gentoo weiter zu machen. Gentoo bringt seit einiger einen grafischen Installer mit. So hoffte ich, den mal praktisch testen zu können. Aber der X-Server tat mir nicht den Gefallen zu starten. So versuchte ich den konsolenbasierten zu nutzen. Dieser stürzte jedoch undeterministisch ab. Ich schaffte es damit nur einmal in die Nähe einer Installation zu kommen. Ich hätte es zwar noch auf dem klassischen Weg probieren können. Dazu fehlte mir jedoch die Lust.

Bei Distrowatch schaute ich mich noch nach weiteren interessanten Distributionen um. Jedoch konnte ich nichts ansprechendes finden und unternahm deswegen einen letzten Versuch mit Debian. Zu meiner Überraschung war das eine komplett problemlose Angelegenheit. Die Installation lief problemlos durch. Danach habe ich ein paar Anpassungen gemacht, Software eingespielt und Konfigurationen ergänzt. Also läuft auf dem Rechner zunächst mal Debian. Zumindest bis es mir zu langweilig wird.

Ach ja, wer sich fragt, welchen exotischen Rechner ich denn habe: IBM Thinkpad R52

Ordentliche Kryptogrpahie scheint immer noch nicht so einfach zu sein. Heise Security fand eine Festplatte, die mit AES-Verschlüsselung wirbt. Ein genauer Blick auf die verschlüsselten Daten zeigte jedoch anderes.

Die untersuchte Festplatte ist eine Easy Nova Data Box PRO-25UE RFID. Nach Angaben des Herstellers funktioniert sie bei allen gängigen Betriebssystemen ohne zusätzliche Treiber. Die Analyse der Platte zeigte zum einen, dass es Bereiche gab, die mit Nullbytes beschrieben waren. Dadurch weiß ein Angreifer, wo er nach verschlüsselten Daten suchen muss. Optimalermeise sollte ein Angreifer nur zufällige Daten auf der kompletten Festplatte sehen. Die gängigen Festplattenverschlüssler machen das meines Wissens auch so.

Einen ersten Schreck bekamen die Forscher, als sie die Verteilung abdruckten. Anstatt annähernder Gleichverteilung sah man Muster und ein tieferer Blick in die verschlüsselten Daten eröffnete schockierendes. Von einer auch nur AES ähnelnden Verschlüsselung war nichts zu finden. Stattdessen waren die Daten mit XOR in 512 Byte-Blöcken “verschlüsselt”. Damit ist die Zurückgewinnung der Daten natürlich einfach.

Die Mitarbeiter von Heise setzten sich daraufhin mit dem Hersteller des Controller Chips, Innmax, in Verbindung und dieser bestätigte, dass er momentan einen “proprietären Algorithmus” einsetzt. Ein neuer, verbesserter Controller ist in Arbeit. Dieser soll wohl dann auch wirklich AES können.

Offensichtlich ist nicht überall, wo AES draufsteht auch AES drin. Das Beispiel zeigt auch mal wieder, die Wichtigkeit Freier Software. Denn die klassischen Verschlüssler, wie GnuPG, Truecrypt, dm-crypt und noch weitere haben den Quellcode offengelegt. Jeder kann sich diesen anschauen, verändern und bei eventuellen Fehlern laut aufschreien.

Wenn man untenstehendes im Syslog liest, ist es wohl Zeit, sich von der Festplatte zu verabschieden:

kernel: ide: failed opcode was: 0xb0
kernel: ide: failed opcode was: unknown
kernel: hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }

Wolltest du schon immer mal eine Festplatte knacken? Dafür gibt es Abhilfe. Ein findiger Mensch veranstaltet die The Great Zero Challenge. Du bekommst eine Festplatte zur Verfügung gestellt. Diese wurde mit Nullen überschrieben. Deine Aufgabe ist es, Datei- oder Verzeichnisnamen zu gewinnen.

Der Grund hierfür ist, dass einige große Firmen, die sich auf Datenrettung spezialisiert haben, die Annahme einer derartigen Platte verweigerten. Dabei wurde die ja nur mit dd if=/dev/zero of=/dev/hda überschrieben. Nach der allgemein gehörten Meinung können die Daten leicht wiedergewonnen werden. Aber die Aussage der Datenretter war anders:

According to our Unix team, there is less than a zero percent chance of data recovery after that dd command. The drive itself has been overwritten in a very fundamental manner.

Wer also Lust auf ein wenig Spass hat, kann sich an den Autor wenden.

via Isotopp

Anfang der Woche hatte ich endlich mal Zeit, diverse Hardwareprobleme zu lösen. Mein CPU-Lüfter war mir zu laut, eine Festplatte war deutlich am sterben und mehr RAM braucht mein Rechner auch. Als schraubte ich ihn auf, befreite ihn vom Staub der letzten Jahre, baute die Ersatzteile ein und spielte das Backup zurück. Nach einigen kleinen Anpassungen lief der Rechner recht schnell wieder. Gestern hielt ich einen Workshop zu Subversion und hatte einige Beispiele auch auf meinen Rechner zu Hause liegen. Beim Öffnen einer Datei schmettert mir dann mein Editor einen Lesefehler entgegen. Meine dunkle Ahnung bestätigte sich dann zu Hause. Auch die zweite Festplatte starb gerade einen langsamen Tod.

Anstatt mir nun wieder eine IDE-Platte in den Rechner zu hängen, beschloss ich, nun den kompletten Rechner umzubauen. Über den endgültigen Ausbau bin ich noch nicht sicher. Aber mit großen Wahrscheinlichkeit wird es ein AMD-Dual-Core mit entsprechendem Mainboard werden. Mal sehen, vielleicht bekomme ich auch die kürzlich gekaufte IDE-Platte in eine SATA-Platte getauscht. Gute Hinweise zu diversen Bauteilen nehme ich natürlich gern entgegen.