Qbi's Weblog

Vor kurzem wurde mir ein Umfragebogen präsentiert. Darin enthalten war u.a. diese Frage:

Haben Sie zu Hause einen Computer?

Ja
Nein
Weiß nicht

Wer die letzte Antwort ankreuzt, sollte vielleicht in einer ruhigen Minute mal wieder in Ruhe durch seine Wohnung laufen.

Als Jesse McPherson nach einem Ausflug nach Hause kam, traute er seinen Augen nicht. In seine Wohnung war eingebrochen worden. Es fehlten Computer, XBox und Fernsehgerät. Er meldete den Diebstahl bei der Polizei und beschloß auf eigene Faust zu suchen. Unter anderen suchte er per Google Maps nach Läden. Dort rief er an und erkundigte sich, ob jemand seine Sachen verkaufen wollte. In der Tat hatte er bei einem Shop Glück. Offensichtlich wollte dort jemand ein Powerbook zum Ankauf geben, welches seinem entsprach. Der Shop hatte eine Überwachungskamera und händigte Jesse auch die Aufnahmen aus. Mit diesem Angaben füllte er unter anderem sein Blog. Des Weiteren besass der Dieb die Dreistigkeit, ihn anzurufen und die alte XBox zu Rückkauf anzubieten. Jesse bekam die Accountinformationen raus. Diese schienen identisch zu sein. Der Rest ergab sich von selbst. Sein Blogeintrag landete bei Digg auf den ersten Seiten. Der Dieb bekam das mit und gab die Sachen zurück.

Der gesamte Vorgang konnte natürlich so schnell aufgeklärt werden, weil sich der Dieb recht dumm anstellte. Aber eben die vielfältigen Möglichkeiten von Google & Co. haben eindeutig geholfen, sich über die Identität des Diebes klar zu werden. Schnell wurde eine Seite ins Leben gerufen, die Details über den Dieb preisgibt. Also auch wenn ihr nichts stehlen wollt, solltet ihr euch immer im Klaren darüber sein was ihr schreibt und wieviel Informationen ihr preisgebt.

Wer sich fragt, was ein Hacker ist: Derjenige, der so eine Etch-A-Sketch-Uhr baut, kommt schon nahe an die Definition ran. Respekt.

Habt ihr schonmal E-Mails mit der Reply-To-Adresse blablabla@donotreply.com bekommen? Nach den Worten von Securityfix scheint das bei amerikanischen Unternehmen üblich zu sein. Ein Unternehmen sendet eine E-Mail raus und möchte keine Antwort bekommen. Also nutzen sie halt als Returnadresse meinunternehmen@donotreply.com. Aber wie das nun mal mit Domainnamen so ist, gehört diese einer anderen Person. Chet Faliszek, der Eigentümer von donotreply.com, postet in seinem Blog They Told You Not To Reply einige interessante E-Mails, die er erhielt. In einigen Fällen versucht er auch die Unternehmen zu warnen, nicht derartige Reply-To-Adressen zu verwenden und erhält merkwürdige Reaktionen:

I've had people yell at me, saying these e-mails are marked private and that I shouldn't read them

Vielleicht sollten die Unternehmen lieber über ihre eigenen Methoden nachdenken.

Im nächsten Monat werde ich zusammen mit Johannes Lichdi, MdL im sächsischen Landtag eine Veranstaltungsreihe in Sachsen unternehmen. Angesichts der ausufernden Überwachungsmaßnahmen diskutieren wir mit dem anwesenden Publikum die vorhandenen oder geplanten Maßnahmen. Bei einigen Veranstaltungen wird auch der Film "A scanner darkly" gezeigt werden. Falls du Zeit und Lust hast, komm doch mit vorbei. Folgende Termine sind derzeit geplant:

• 8. April um 19:30 Uhr in Torgau
• 9. April in Freiberg
• 10. April um 19:00 Uhr in Dresden
• 12. April um 20:30 Uhr in Görlitz
• 21. April um 19:30 Uhr in Glauchau
• 23. April um 19:00 Uhr in Plauen

Weitere Details, insbesondere zu den Orten, findest du bei der Ankündigung der Veranstaltung.

Das werden heute wohl die Nachrichten des Tages werden:

Der Antrag der Beschwerdeführer, §§ 113a, 113b TKG im Wege der einstweiligen Anordnung bis zur Entscheidung über die Verfassungsbeschwerde außer Kraft zu setzen, hatte teilweise Erfolg.

Zu gut deutsch: Die Vorratsdatenspeicherung wurde zu großen Teilen auf Eis gelegt. Damit hat der AK Vorrat einen wichtigen Teilerfolg erzielt und ich hoffe, dass demnächst auch das komplette Gesetz gekippt wird.

Bei dem untenstehenden Bild dürfte Otto-Durchschnitts-Geek zu multiplen Orgasmen fähig sein.

Gestern abend hat Google die teilnehmenden Projekte am Summer of Code bekannt gegeben. Auf der Liste stehen viele bekannte Organisationen und auf deren Seiten finden sich auch recht interessante Projekte. Unter anderem ist das Tor-Projekt diesmal wieder dabei. Es gibt einiges an Vidalia zu verbessern und auch einige nette Applikationen um Tor herum sind auf der Seite erwähnt. Falls du also Lust hast, etwas Zeit mit Programmieren zu verbringen, schau die GSoC-Seite mal an. Es findet sich dort wahrscheinlich für jeden etwas.

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

Kürzlich erhielt ich den Auftrag, einige Subversion-Repositorys auf einen neuen Server umzuziehen. Dazu sollte noch ein Trac (Bug-/Issuetracker) auf den Rechner sowie WebDAV angepasst werden. Alles in allem keine große Sache. Es sollte innerhalb eines Arbeitstages gegessen sein. Sollte ...

Nach einigen Vorbereitungsarbeiten warf ich im ersten Repository ein beherztes svnadmin dump $REPO > $REPODUMP an und wartete. Kurz vor Ende brach der Prozess ab und meldete svnadmin: Found malformed header in revision file. Eine Websuche ergab, dass die Datenbank wahrscheinlich korrupt ist. Die Fehlerquelle liegt wahrscheinlich im Zusammenspiel von mod_dav und Subversion. Gleiches kann auch mit svnserve auftreten. Soweit ich las, ist der Fehler nicht genau reproduzierbar. Daher existieren auch keine Fixe. Eine zweite mögliche Fehlerquelle liegt in der Hardware. Auf dem Server gab es wohl in dem Zeitraum Probleme mit dem RAID. Eventuell kommt das Problem auch daher. Die Mailingliste von Subversion ergab hier nur einen Hinweis auf das Pythonskript fsfsverify von John Szakmeister. Im Verzeichnis $REPO/db/revs liegen die bisherigen Revisionen und man übergibt dem Skript einfach die fehlerhafte Datei. (Wobei das nur für das Format FSFS gilt.) Aber das einzige, was das Skript dabei ausspuckte, war:

File "/foo/bar/fsfsverify/fsfsverify.py", line 661, in __init__
  (field, value) = line.split(':', 1)

Was tun?, sprach Zeus. Ich entschied mich, einen genaueren Blick in die Struktur von FSFS zu werfen und auch den Autor des Programms um Rat zu fragen. FSFS hat den Vorteil, dass es pro Datei immer nur einen binären Diff mit Metainformationen speichert. Somit könnte man praktisch die Informationen wieder zurückgewinnen, denn das Format des Diffs ist ebenfalls offengelegt. Jedoch ist bei dem Repository ein durchschnittlicher Diff 1,5MB (sic!) groß. Da will man nichts händisch zusammenbasteln. John antwortete mir glücklicherweise und bot seine Hilfe an. Nach einigem Mailaustausch schafften wir es, die Datenbank zu reparieren. Der dabei entstandene Diff entspricht zwar nicht dem Originaldiff. Aber er kommt nahe dran.

So kann ich jetzt mit einer Woche Verzögerung das Projekt beenden. Trotz der Verzögerung sind alle glücklich.

So langsam gehen die Arbeiten für die neue Version von Tor in die Endrunde. Roger Dingledine hat heute den Kandidaten freigegeben. Es sieht so aus, als ob es keine größeren Fehler mehr gibt. Falls ihr also mal die Version testen wollt, ladet sie herunter und berichtet Fehler, wenn es doch welche geben sollte.

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.

Momentan bin ich etwas in Leselaune und verbringe noch dazu einige Zeit im Zug. Also versuche ich einige der im Schrank stehenden, ungelesenen Bücher anzuschauen oder komplett zu lesen. Vor kurzem fiel meine Wahl auf das Buch "Die Musik der Primzahlen. Auf den Spuren des größten Rätsels der Mathematik" von Marcus de Sautoy.

Wie der Name des Buches schon sagt, geht es im weiteren Sinne um Primzahlen. Der Autor geht zum Großteil auf die Untersuchung der Riemannschen Hypothese ein und erklärt, wer bisher daran gescheitert ist. Es ist ein interessanter historischer Abriss. Der Leser lernt eine Vielzahl groß(artig)er Mathematiker kennen. Falls jemand Angst hat, zuviel Mathematik zu finden, den kann ich beruhigen. Der Autor scheut aus meiner Sicht die Erwähnung mathematischer Details wie der Teufel das Weihwasser. Selbst recht einfache Sachverhalte wie die Modulorechnung werden anhand umständlicher Beispiele erklärt. Das ist gleichwohl einer der Punkten, die mir bei dem Buch nicht gefallen haben. Denn aus meiner Sicht kann man dem Leser schon mathematische Grundlagen zumuten.

Die erste Hälfte des Buches deckt die Geschichte bis etwa zu Beginn des 20. Jahrhunderts ab. Dies lässt sich angenehm und flüssig lesen. Zu Beginn der zweiten Hälfte des Buches fragte ich mich schon, was der Autor denn noch schreiben will. Tatsächlich wird dann hier vieles in die Länge gezogen bzw. es werden noch unnötige Details erklärt. Hier hätte ich es besser gefunden, wenn der Autor den Schreibstil der ersten Hälfte beibehalten hätte. Das Resultat wäre ein Buch mit vielleicht 50--100 Seiten weniger. Aber dann wäre der Gesamteindruck auf mich noch besser gewesen.

Letztlich sind die obigen Kritikpunkte jedoch Feinheiten. Insgesamt hat mir das Buch sehr gut gefallen, wenngleich ich etwas mehr Mathematik erwartet hätte. Solltet Ihr an der Geschichte dieser Wissenschaft interessiert sein, dann schaut es euch unbedingt mal an.