Das war doch endlich einmal ein Urteil mit Menschenverstand.
Gestern kippte das Bundesverfassungsgericht den in NRW im Eilverfahren gefassten Beschluss zu, nennen wir es mal: “unbürokratisch” geregelten Online-Durchsuchungen.
Die Karlsruher Richter erklärten die NRW-Entscheidungen für nichtig und lassen heimliche Online-Durchsuchungen nur noch zu, wenn
- Gefahr für Leib und Leben,
- Gefahr für die Freiheit von Personen oder
- eine andere “konkrete Gefahr für ein überragend wichtiges Rechtsgut”
besteht.
Außerdem ist ein richterlicher Beschluss zwingend erforderlich, um eine Online-Durchsuchung durchführen zu dürfen.
Hoffentlich ist damit Herrn Schäuble ein Zeichen gesetzt, den Datenschutz nicht weiter so maßlos mit Füßen zu treten.
Manchmal ist man echt ein wenig benagelt.
Für die mobile Visite möchten wir Notebooks testen, die, auf Ubuntu basierend, über WLAN eine Citrix-Anwendung auf den Bildschirm bringen sollen.
Und gerade, nachdem ich ein Notebook mit der amd64-Variante von Ubuntu Gutsy Gibbon (7.10) bestückt, matchbox als Window-Manager eingerichtet und auch per WPA den Netzwerkkontakt fertigkonfiguriert hatte, fiel mir ein, dass Citrix ja gar keinen 64-Bit-Client für Linux anbietet.
Doch man will sich ja nicht unterkriegen lassen. Und außerdem gibt es ja noch die 32bit-Libraries aus dem Paket “ia32-libs”.
So konnte der Installationslauf des Citrix-Client nach der Installation von ia32-libs, libmotif3 und libxaw6 mit dem Aufruf von “setupwfc” erfolgreich abgeschlossen werden.
Nur der Aufruf des wfcmgr schlug fehl:
/usr/lib/ICAClient/wfcmgr: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory
Und auch nachdem ich dem ICA-Client mitgeteilt hatte, wo er denn die libXm.so.3 zu suchen habe, verlief der Programmstart nicht wirklich erfolgreicher:
/usr/lib/ICAClient/wfcmgr: error while loading shared libraries: libXm.so.3: wrong ELF class: ELFCLASS64
Also war wohl auch die 32-Bit-Variante von libmotif3 vonnöten.
Die kann man wie folgt in sein System integrieren:
Zunächst muss die aktuelle 32bit-libmotif3 von: http://packages.ubuntu.com/gutsy/libs/libmotif3 heruntergeladen werden.
Dann geht es so weiter:
$ dpkg-deb -X libmotif3_2.2.3-2_i386.deb libmotif3
$ sudo cp libmotif3/usr/lib/libXm.so.3.0.2 /usr/lib32/
$ sudo ln -s /usr/lib32/libXm.so.3.0.2 /usr/lib32/libXm.so.3
Der nächste Start des Citrix Presentation Server Client funktionierte bei mir nun fehlerfrei.
Da wollte sich die Grundig-Webseite wohl nicht wirklich damit zufrieden geben, dass mein Iceweasel ihre Popup-Fenster nicht anzeigen möchte:
Startet da etwa ein neuer Browserkrieg? Jetzt in der Form: Webseite gegen Browser. 
Heute morgen kam ein Bekannter, ziemlich aufgeregt, zu mir. Er hatte versehentlich alle Bilder von seiner Micro-SD-Karte des Mobiltelefons gelöscht, ohne diese vorher zu sichern. (Glücklicherweise hatte er sich selbst noch nicht an einer Datenrettung versucht, ich hatte also noch Chancen. )
Nach dem Einlegen der Karte in den Kartenleser meines Lenny-Boliden, zeigte mir ein “fdisk -l”, wen sollte es verwundern, einen VFAT-formatierten Datenträger.
Nun folgte nur noch der wenig aufregende, forensische Teil der Datenrettung:
$ mkdir -p ~/rescue/daten
$ dd if=/dev/sdb1 of=~/rescue/sdcard.img
$ foremost -v -i ~/rescue/sdcard.img -o ~/rescue/daten/
Foremost (aus dem gleichnamigen Debian-Paket) beschreibt sich selbst mit: “Recover files using their headers, footers, and data structures”, und versucht Daten anhand ihrer Header-Daten im Input-File (oder Input-Datenträger) wiederherzustellen. Und da das Programm sich v.a. auf Multimedia-Daten (jpg, gif, avi, wmv, mov, …) versteht, war es in meinem Fall genau die richtige Wahl:
Foremost version 1.5.3 by Jesse Kornblum, Kris Kendall, and Nick Mikus
Audit FileForemost started at Thu Feb 14 7:35:17 2008
Invocation: foremost -v -i sdcard.img -o daten
Output directory: /home/stefan/rescue/daten
Configuration file: /etc/foremost.conf
Processing: sdcard.img
|- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -
File: scard.img
Start: Thu Feb 14 7:35:17 2008
Length: 982 MB (1030101504 bytes)Num Name (bs=512) Size File Offset Comment
0: 00001293.jpg 347 KB 662016
1: 00001997.jpg 218 KB 1022464
2: 00002445.jpg 308 KB 1251840
[...]
291: 00613197.jpg 307 KB 313956864
292: 00462189.gif 31 KB 236640768 (183 x 244)
293: 00506253.mov 1 MB 259201564
********|
Finish: Thu Feb 14 7:36:06 2008294 FILES EXTRACTED
jpg:= 286
gif:= 7
mov:= 1
- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -Foremost finished at Thu Feb 14 7:36:06 2008
Saubere Leistung.
Mit einem Image des eigentlich betroffenen Datenträgers sollte man arbeiten, da so die Gefahr eines Verlustes der Originaldaten minimiert wird.
… die gibt’s zwar öfter, aber diese ist doch recht heftig:
Ein Fehler in der Funktion vmsplice_to_user ermöglicht es, mit einem einfachen Exploit lesend und schreibend auf den Hauptspeicher zuzugreifen, und als lokaler Angreifer beispielsweise eine root-Shell zu öffnen.
Betroffen sind alle 2.6er-Kernel ab 2.16.17, erfolgreich ausgenutzt sieht das dann so aus:
stefan@server:~/exploit$ ./exploit
-----------------------------------
Linux vmsplice Local Root Exploit
By qaaz
-----------------------------------
[+] mmap: 0×0 .. 0×1000
[+] page: 0×0
[+] page: 0×20
[+] mmap: 0×4000 .. 0×5000
[+] page: 0×4000
[+] page: 0×4020
[+] mmap: 0×1000 .. 0×2000
[+] page: 0×1000
[+] mmap: 0xb7df1000 .. 0xb7e23000
[+] root
root@server:~/exploit#
Der Fehler ist (in Debian Etch) bereits gefixed, und steht über das Security-Repository zum Installieren bereit. Auch die Linux-Kernel-Version 2.6.24.2 enthält den Fehler nicht mehr.
Nach dem Kernel-Update sollte der Exploit-Versuch dann so enden:
stefan@server:~/exploit$ ./exploit
-----------------------------------
Linux vmsplice Local Root Exploit
By qaaz
-----------------------------------
[+] mmap: 0×0 .. 0×1000
[+] page: 0×0
[+] page: 0×20
[+] mmap: 0×4000 .. 0×5000
[+] page: 0×4000
[+] page: 0×4020
[+] mmap: 0×1000 .. 0×2000
[+] page: 0×1000
[+] mmap: 0xb7e6a000 .. 0xb7e9c000
[-] vmsplice: Bad address
stefan@server:~/exploit$
Ich bin auf jeden Fall mit der Patcherei durch
Danke an Pascal, der mich auf den Fehler aufmerksam gemacht hat.
Wir verwalten die DNS-Einträge für unsere Firmen-Domains auf einem eigenen DNS-Server, der als Master konfiguriert ist. Der Provider stellt die Slave-Server.
Auch für die Reverse-Lookups lief bislang der Master bei uns, da wir jedoch kein ganzes Subnet verwalten, war das Ganze vom Provider classless an uns deligiert.
Bemerkbar macht sich der Reverse-Lookup auf eine IP eines Classless-Subnets eigentlich nur durch eine erweiterte Rückgabe beim Auflösen der IP. Vor dem eigentlichen Pointer wird noch eine Cname-Zeile zurückgegeben, z.B. in der Art:
# host 240.241.242.243
243.242.241.240.in-addr.arpa is an alias for 243.240/29.29.242.241.240.in-addr.arpa.
243.240/29.29.242.241.240.in-addr.arpa. domain name pointer mail.meinedomain.de.
Das ist sogar RFC-konform.
Wegen des rasant steigenden Aufkommens von Spam-Mails ziehen immer mehr Mailserverbetreiber nun die Daumenschrauben für eingehende eMails an und lassen nur noch eMails von IPs/Domains durch, die sich sowohl vorwärts als auch rückwärts richtig auflösen lassen. Da habe ich auch vollstes Verständnis dafür, wir selbst nutzen auch viele technische Möglichkeiten, den Werbemüll vor unserer Mailserver-Haustür zu blocken.
Aber einige Freemail-Anbieter (bei uns ist das bei web.de und freenet.de aufgefallen) schießen seit einiger Zeit doch über ihr Ziel hinaus. Auf einmal häuften sich Einträge in der Mail-Queue:
666C03000542 7475 Sat Jan 26 07:51:14 MAILER-DAEMON
(host mx-ha02.web.de[217.72.192.188] refused to talk to me: 554 Transaction failed. For explanation visit http://freemail.web.de/reject/?ip=240.241.242.243)
emailadresse@web.de
Eine Rückfrage an Web.de über das entsprechende Webformular brachte folgende Antwort des Service-Mitarbeiters:
Leider mussten wir feststellen, dass für die angegebene(n) IP-Adresse(n)
kein gültiger Reverse Lookup (RDNS) Eintrag existiert.
Unser Provider nahm nun testweise die IP unseres Mailservers wieder aus dem ans uns deligierten Subnet heraus und löste die IP wieder direkt auf.
Und siehe da: es herrscht wieder gähnende Leere in der Mail-Warteschlange.
Ich denke, da ist eine Nachbesserung der Mailserverkonfiguration bei einigen eMail-Diensten angesagt.
Ich nutze als einziges Addon für Icedove schon seit langem Enigmail zur Signierung und Verschlüsselung meiner Mails. Nach einem der letzten System-Updates versagte die Erweiterung dann plötzlich ohne Vorwarnung ihren Dienst. Die installierte Version 0.94 sei inkompatibel zur aktuellen Icedove-Version.
Eigentlich ist das kein großes Problem, eine neuere Version 0.95.6 der Erweiterung war ja auch mozdev.org schon verfügbar.
Nach dem Download der entsprechenden Datei verweigerte diese jedoch meine Installationsbitte:
“Enigmail” konnte nicht installiert werden, da es nicht mit dem Icedove-Build-Typ (linux-gnu_x86-gcc3) kompatibel ist”
Als nächste Möglichkeit fiel mir das Sid-Repository als Installationsquelle ein. Und dort gibt es tatsächlich eine aktuelle Version des Plugins als Paket. Ich vermische allerdings ungerne verschiedene Debian-Versionen untereinander, deswegen bemühte ich nicht meinen Editor, um die Sid-Quellen in meine sources.list aufzunehmen, sondern lud das Paket direkt bei debian.org herunter.
Die auf der Informationsseite des Paketes genannten Abhängigkeiten versprachen eine problemlose Integration des unstabilen Paketes. Trotzdem stellte sich das Paket quer, erstens störte es sich an einer angeblich nicht passenden Thunderbird-Version, zweitens tauchte es dann nach dem ersten, angeblich fehlerfrei verlaufenen Installationsversuch nicht in der Liste der installierten Erweiterungen auf.
Ersterem Fehler kann man durch die Deinstallation des Paketes “thunderbird” begegnen. Dieses ist sowieso nur noch “transitional” und ist ein Rest der Namensänderung von Thunderbird zu Icedove.
Und um die Erweiterung nach der Installation auch in Thunderbird zur Verfügung stehen zu haben, muss die vorhandene Lenny-Version vorher komplett aus dem System entfernt (also “gepurged”) werden.
In Einzelschritten sieht das also so aus:
# aptitude remove thunderbird
# aptitude purge enigmail
# dpkg -i enigmail_0.95.0+1-3_i386.deb
Der Name des Enigmail-Paketes hängt dabei natürlich von der eingesetzten Systemarchitektur ab.
