Wie ginge ein Sicherheitsexperte vor, wenn ihn das Bundeskriminalamt darum bitten würde, einen Linux-fähigen Bundestrojaner zu projektieren? Wer meint, das Unterfangen wäre schwer und Linux per se sicher, möge die folgenden zehn Punkte studieren. Wer etwas gegen Schäuble- und Malware tun will, auch.
“Die Bedrohung heiligt die Mittel”, so lautet offenbar die aktuelle Arbeitshypothese im Bundesinnenministerium und im Bundeskriminalamt. Deren Ankündigung, Online-Durchsuchungen zu legalisieren [1], sorgt für Aufregung auch außerhalb von IT-Kreisen (siehe Kasten “Der Bundestrojaner”). Nicht nur Datenschützer meinen, Minister Schäuble (Abbildung 1) nutze und schüre sogar die Angst der Bevölkerung vor Terror und organisierter Kriminalität, um Bürgerrechte und Privatsphäre zugunsten der inneren Sicherheit zu opfern.
|
Der Bundestrojaner |
|---|
|
Das Innenministerium unter Minister Wolfgang Schäuble plant gegenwärtig das “Gesetz zur Abwehr von Gefahren des Internationalen Terrorismus durch das Bundeskriminalamt” [1]. Es soll dem BKA eine gesetzliche Grundlage verschaffen, um unerkannt Inhalte von “informationstechnischen Systemen” zu durchsuchen. Während eine herkömmliche Wohnungs- und Hausdurchsuchung eine einmalige Aktion ist, bei der zudem der Beschuldigte oder sein Vertreter anwesend sind, soll die Online-Durchsuchung im Verborgenen stattfinden und über einen längeren Zeitraum dauern. Damit trägt die sie Züge einer Abhöraktion. Das Innenministerium selbst grenzt die Online-Durchsuchung deutlich von einer Telekommunikationsüberwachung ab, für die bereits eine gesetzliche Verordnung (TKÜV) besteht. Auf Nachfrage des Justizministeriums gibt es an, dass die neuen Pläne auf Systeme zielen, die “sich nicht im direkten physikalischen Zugriff der Sicherheitsbehörden befinden, aber über Kommunikationsnetze erreichbar sind” [3]. Fernforensik im Dienste des BKAUm das zu erreichen, will das BKA eine so genannte Remote Forensic Software (RFS) auf jedem überwachten System installieren. Diese sucht nach Dateien, Passwörtern oder Systeminformationen, lagert sie zwischen und verschickt sie verschlüsselt an die Ermittlungsbehörden, sobald eine Internetverbindung besteht. Damit auch sporadisch bestehende Netzanbindungen mit geringer Bandbreite genügen, sollen die Suchkriterien eng gefasst sein. Da zur Wohnraumüberwachung bereits eine gesetzliche Grundlage besteht, darf die RFS keine Peripheriegeräte (Mikrofone, Webcams) nutzen. Gegner der Online-Durchsuchung bezweifeln die Abgrenzung von der akustischen Wohnraumüberwachung und haben daher Verfassungsbeschwerde beim Bundesverfassungsgericht eingelegt. Diese wendet sich allerdings nicht gegen das Gesetzesvorhaben aus Berlin, sondern gegen ein ähnliches Landesgesetz in Nordrhein-Westfalen. Den Urteilsspruch des Anfang Oktober beginnenden Verfahrens wollen die politischen Entscheidungsträger offenbar noch abwarten, bevor sie das BKA-Gesetz ins Parlament einbringen. |

Abbildung 1: Bundesinnenminister Schäuble will dem BKA erlauben in verdächtige Computer einzudringen und sie aus der Ferne zu untersuchen.
Fachleute irritiert zudem die Tatsache, dass die Behörden technische Details zu einer Computer-Razzia nicht oder wenn, dann mit Widersprüchen spezifizieren [2]. Das bildet einen idealen Humus für Spekulationen. Eine davon – gern von Linux-Anwendern vorgebracht – ist, dass ein Bundestrojaner auf ihrem Betriebssystem nicht funktionieren könne.
Der Auftrag
Was käme wohl heraus, wenn BKA und Innenministerium einen Linux-Sicherheitsexperten anheuerten, ein Dossier über die Machbarkeit eines Linux- und Open-Source-Software-fähigen Bundestrojaners niederzuschreiben? Mit einiger Wahrscheinlichkeit ungefähr das folgende Zehn-Punkte-Programm.
Das Gedankenspiel beginnt bei den Angriffstechniken, die ein BKA-Entwickler vermutlich aus der Windows-Welt bestens kennt. Doch es geht kreativer: Würmer, Backdoors, E-Mails, Sourcecode fälschen und so ziemlich jede vorhandene PC-Komponente angreifen.
Und was kann ein Benutzer dagegen tun? In einem der zehn Fälle nichts. Für die anderen weiß es dieser Artikel.
Angriff 1: Viren und Würmer
Ein Virus nach klassischer Bauart (Abbildung 2) befällt vorhandene Files, modifiziert sie und breitet sich via Filesystem weiter aus. Eine ähnliche Form von Malware heißt Wurm, wenn sie selbstständig läuft (ohne Wirtsprogramm) und sich über Netzwerkfunktionen verbreitet. Beiden gemein sind zwei grundsätzliche Komponenten: Replikation und Schadfunktion. Mit der ersten infizieren sie weitere Ziele, die zweite löscht etwa die Festplatte, Passwörter und Liebesbriefe oder spioniert den Plan für den nächsten Selbstmordanschlag aus.

Abbildung 2: Ganz wie dieser biologische Virus infizieren auch Computerviren einen Träger, mit dessen Hilfe sie sich verbreiten und Schaden anrichten.
Für Linux sind zwar etliche Würmer bekannt, aber kaum klassische Viren. Gegen Linux-Viren spricht, dass es einem nicht-privilegierten Prozess kaum möglich ist, fremde Programme und Systemdateien zu überschreiben. Linux-Software ist in aller Regel legal und frei verfügbar, daher ist auch das Windows-Phänomen der virenverseuchten Raubkopien hier unbekannt. Bleiben Makroviren. Die könnte es sehr wohl unter Linux geben, in freier Wildbahn wurden bislang aber kaum welche gesichtet.

Abbildung 3: Um sich vor den Gefahren durch behördliche Überwachung zu schützen, darf ein System keine Schwachstellen aufweisen.
Erfolgsaussicht
Würmer zu schreiben verspricht mehr Erfolg. Sie sind nicht auf Wirtsprogramme beschränkt und greifen über das Netzwerk auch ferne Rechner an. Seit die meisten Distributionen per Default kaum noch Netzwerkdienste starten, ist dieser Angriffsweg aber erschwert.
Beide Formen klassischer Malware sind durchaus unter Linux denkbar, sie ließen sich im Normalfall jedoch relativ einfach entdecken. Der Daseinszweck von Virenscannern ist es schließlich, solche Störenfriede ausfindig zu machen und zu entfernen. Aus technischer Sicht ist nicht einzusehen, warum ein Virenscanner ausgerechnet einen Bundestrojaner übersehen sollte, sobald sein Auftreten erstmalig publik wird. Denkbar wäre zwar, dass die Bundesbehörden für jedes Überwachungsziel eine individuell Malware schreiben, allerdings wären der Entwicklungsaufwand und die damit verbundenen Kosten immens.
Nebenwirkung
Da Viren und Würmer je nach Replikationsmechanismus die Gefahr bergen, dass sie sich unkontrolliert vermehren und so auch kritische Infrastrukturen in Mitleidenschaft ziehen, erscheint es wenig wahrscheinlich, dass der Bundestrojaner diesen Weg einschlägt. In ähnlicher Form äußert sich auch das Innenministerium in einer Stellungnahme an das Justizministerium [3].
Vor einem Angriff schützt sich ein Administrator am besten durch ein System mit aktuellem Patchstand, durch restriktive Rechtevergabe und ein Prüfsummensystem wie Aide [4] oder die freie Version von Tripwire [5], die kryptographische Prüfsummen von allen Dateien anlegen und damit unerwünschte Modifikationen erkennen.
Angriff 2: Vorhandene Schwachstellen nutzen
Egal ob Virus, Wurm oder simple Backdoor: Irgendwie müssen sie ihren Weg ins zu überwachende System finden, also einen Angriffsvektor. Hier bietet es sich an, Schwachstellen in der verwendeten Software auszunutzen. Sicherheitskritische Fehler sind keine Seltenheit. Die amerikanische Organisation Mitre katalogisiert bekannt gewordene Schwachstellen [6]; allein in der ersten Jahreshälfte 2007 listete sie über 3000 Lücken in allen Betriebssystemen und Anwendungen. Dass dort auch Linux auftaucht, verwundert nicht – auch angesichts der InSecurity-News im Linux-Magazin.
Der augenfälligste Unterschied zwischen Linux und proprietären Produkten ist die Verfügbarkeit des Quelltextes, von der sowohl die Angreifer profitieren als auch die Verteidiger. Wer Schwachstellen sucht, findet sie leichter, wenn er den Quelltext hat, egal wozu er seine Erkenntnisse nutzt. Die Sicherheitsexperten streiten, ob Vor- oder Nachteile überwiegen, also ob es mehr Kriminelle gibt, die eine Lücke ausnutzen, als Sicherheitsexperten, die Fehler beheben. Im Allgemeinen hat sich aber die Überzeugung durchgesetzt, dass nicht bekannte oder verheimlichte Schwachstellen problematischer sind als wegen ihres Bekanntwerdens behobene Fehler.
In der Regel funktioniert die so genannte Security by Obscurity nicht, sprich: das Geheimhalten einer Schwachstelle schützt nicht davor, dass es doch jemanden gibt, der sie findet und ausnutzt. Geradezu absurd scheint der Versuch, die Suche nach Sicherheitslücken per Lizenz zu verbieten. Wichtig ist dagegen, bekannt gewordene Schwachstellen schnell zu beheben. In Open-Source-Software klappt das erfahrungsgemäß innerhalb von Stunden oder wenigen Tagen. Bei proprietärer Software dauert es oft deutlich länger, da Produktmanagement, Releasezyklen oder Marketingaussagen der schnellen Veröffentlichung von Patches entgegenstehen.
Schwachstellen sind für jedes System ein bedrohlicher Angriffsvektor, den ein Administrator jedoch minimieren kann, wenn er regelmäßig Updates einspielt. Die meisten populären Distributionen bieten Patches zeitnah an und helfen dabei, sie auf einfache Weise einzuspielen. Für Ermittlungsbehörden bliebe jeweils nur ein kleines Zeitfenster, um Schwachstellen auszunutzen, und sie müssten einen recht effizienten Expertenstab vorhalten, der aus einer Schwachstelle schnell einen Exploit entwickelt.
Viel einfacher einzusetzen wäre diese Technik mit Hilfe fertiger Zero-Day-Exploits, die es im Online-Untergrund zu kaufen gibt. Allerdings wäre das BKA dann direkt abhängig von den Machenschaften krimineller Gruppen, die es bekämpft – bleibt zu hoffen, dass sich die Behörde nicht diese Blöße gibt.
Angriff 3: Backdoor in proprietärer Software
Viel eher wird sie ein klassisches Trojanisches Pferd zimmern (siehe Kasten “Malware-Überblick”). Dessen Schöpfer versteckt seine Schadfunktion in harmlos wirkender Software, die das unwissende Opfer freimütig installiert. Ermittlungsbehörden schleusen also eigenen Code in eine populäre Anwendung ein.
Um unentdeckt zu bleiben, empfiehlt sich die Wahl einer Applikation, für die es keinen Sourcecode gibt. Das kann vom Mediaplayer-Plugin für Webbrowser über eine VoIP-Anwendung bis zum unverdächtigen Druckertreiber reichen [7]. Das Trojanische Pferd erhält damit alle Rechte, die sein ausführender Benutzer hat. Im besten Fall, aus Sicht der Eindringlinge, ist das Root.
Für Ermittlungsbehörden ist es relativ aufwändig, sich in bestehende Entwicklungsprozesse von vornehmlich privatwirtschaftlichen Unternehmen einzuklinken. Bei Offenlegung droht zudem eine hohe öffentliche Entrüstung und ein immenser Vertrauensverlust in diese Produkte, sodass sich Unternehmen nur in Sonderfällen auf solche Vereinbarungen einlassen werden.

Abbildung 5: Egal wie geschützt ein Rechner ist – eine offen stehende Hintertür genügt. Diese Backdoor könnten durchaus die Ermittler selbst eingerichtet haben.
Angriff 4: Tarnkappe im Quellcode
Backdoors oder Trojaner-Funktionen in Open-Source-Software einzubringen ist ungleich schwieriger als bei proprietären Applikationen, da hier durch öffentliche Peer-Reviews ein solches Unterfangen viel schneller offenbar würde. Neben Entwicklern, Testern und freien Security-Experten suchen beispielsweise Linux-Distributoren gezielt nach solch verborgenen Funktionen, um ihre Anwender zu schützen.
Wie gut die Review-Arbeit in der Praxis funktioniert, hängt von vielen Faktoren ab. Klar ist, dass Menge und Komplexität des Quelltextes eine wichtige Rolle spielen, dazu kommen aber auch Beliebtheit und Wichtigkeit der Programme sowie der potenzielle Schaden. Ein harmlos aussehendes, kaum bekanntes Tool, das ohne Sonderrechte auskommt, lockt auch viel weniger Reviewer an als der Linux-Kernel. Während am Kernel Hunderte von Entwicklern arbeiten, die zudem einen mehrstufigen Freigabeprozess verwenden, könnte ein wenig prominentes Projekt eher auf ein riesiges Patch reinfallen, das primär nützliche Funktionen implementiert.
Ermittlungsbehörden müssten sich intensiv mit den projektspezifischen Eigenheiten der jeweiligen Entwicklungsprozesse auseinandersetzen, um diesen Angriff erfolgreich durchzuführen. Gelänge er einmal unbemerkt, wären allerdings die Auswirkungen umso weitreichender.
Angriff 5: Angriff auf Repositorys
Mehr Erfolg als Angriff 4 verspricht es, den normalen Entwicklungsprozess eines Projekts zu umgehen und direkt sein Source-Code-Repository zu manipulieren. Sollten die Änderungen keine Auswirkungen auf die eigentliche Funktionalität der Anwendung haben, können sie durchaus eine gewisse Zeit unentdeckt bleiben, da Anwender und Entwickler die Integrität von bestehendem Sourcecode oft einfach annehmen. Dennoch laufen auch diese Manipulationen Gefahr, dass die Peer-Review eines interessierten Entwicklers sie entdeckt. Dass dieser Angriffspfad nicht nur hypothetisch existiert, zeigt zum Beispiel ein Vorfall bei Sendmail [8].
Besonders lohnende und damit gefährdete Angriffsziele sind zentrale Entwicklerplattformen und Repositorys wie Sourceforge oder Berlios. Einmal eingedrungen könnten die Entwickler eines Bundestrojaners aus dem reichen Angebot von Programmen wählen, in der Hoffnung, eines zu erwischen, das ein Überwachungsopfer auch installiert.
Erfolgreiche Angriffe nach diesem Muster sind bislang noch nicht publik geworden. Für rechtsstaatliche Strafermittlungsbehörden ergibt sich hier ganz besonders die Frage, ob dieses Angriffsmuster überhaupt in einen legalen Rahmen zu bringen ist, da neben dem Ziel der Online-Überwachung in sehr direkter Weise auch unbeteiligte Dritte, womöglich im Ausland, betroffen wären.
Angriff 6: Virtualisierung
Die modernen Virtualisierungstechnologien funktionieren so gut, dass ein Anwender in einem Gastsystem Schwierigkeiten hat zu erkennen, ob er sich in einem virtualisierten Gast oder auf dem tatsächlichen System befindet. Diese Frage müsste er aber klären, wenn er vermutet, dass das BKA eine Virtualisierungsschicht eingezogen hat und Überwachungswerkzeuge im umgebenden Hostsystem betreibt. Allein die Tatsache, dass Virtualisierung aktiviert wurde, ist schwer zu erkennen und als Blue-Pill-Problem [9] bekannt geworden.
Mehrere Projekte haben diesen Ansatz bereits als Proof-of-Concept umgesetzt [10]. Einmal von Strafermittlungsbehörden eingebracht, ist diese Schicht kaum mehr zu entdecken. Praktischerweise ist die Software sogar unabhängig vom Betriebssystem realisierbar. Das BKA könnte in Ruhe die Schnüffelschicht einrichten und aus der Ferne analysieren, welches System und welche Software ihr Überwachungsziel gerade verwendet. Angepasste Module könnten die Ermittler nachinstallieren. Das überwachte System würde davon nichts bemerken, da alle Dateien in der Virtualisierungsumgebung unangetastet bleiben.
Virtualisierungstechniken stehen in diesem Zusammenhang noch am Anfang und sind sicherlich ein interessantes Feld für künftige Entwicklungen. Ein Problem bleibt den Ermittlern aber: Sie müssen ihre Software auf dem überwachten System installieren. Ob sie dazu einen der bereits genannten Angriffsvektoren nutzen oder schlichtweg in die Wohnung eindringen und dort manuell installieren, bleibt der Phantasie überlassen.
Angriff 7: Hardware-Überwachung
Einen Schritt weiter gehen Überwachungsmaßnahmen, die direkt in Hardware umgesetzt sind (Abbildung 6). Das könnte ein simpler Keylogger sein, den ein Beamter zwischen Tastatur und Desktop-PC einstöpselt. Solche Geräte sind leicht anzuschließen, erfordern aber den physischen Zugang zum überwachten Gerät und sie laufen Gefahr, dass ein technisch versierter Benutzer die zusätzliche Hardware bemerkt.

Abbildung 6: Auch in Hardware lassen sich Überwachungsfunktionen einbauen. Um sie zu installieren, brauchen die Ermittler zwar physischen Zugang zum Rechner. Dafür hat es dessen Besitzer später jedoch schwer, die kontaminierte Komponente zu erkennen.
Darüber hinaus sind etliche weitere Abhörmechanismen in Hardware denkbar. Das Mainboard-Bios ist heute üblicherweise flashbar. Möglich wäre damit etwa ein Mini-Hypervisor im Bios, der die Maßnahmen für Angriff 6 vorbereitet. Ganz ähnlich könnten Festplattencontroller, die Firmware in Netzwerk- oder Grafikkarten oder ein Trusted Platform Module (TPM) vor dem Benutzer verborgene Aktionen ausführen.
Sogar manipulierte CPUs sind eine Überlegung wert. In begrenztem Maß ist es möglich, eine zentrale Recheneinheit kostengünstig per FPGAs nachzubauen. Das klappt zwar nicht mit aktuellen Hochleistungs-CPUs, aber bei etwas älteren Prozessoren oder im Embedded-Bereich ist dies machbar.
So ein Trojanischer Chip wäre in der Lage, nach bestimmten Daten zu suchen oder zumindest einen externen Kanal zu öffnen, über den er weitere Software nachlädt. Ist eine solche CPU kompetent eingebaut, vermag ein argloser Anwender die Änderung unmöglich zu erkennen. Die größte Hürde für Ermittlungsbehörden ist, dass das Anbringen solcher Abhörgeräte den räumlichen Zugang zum Gerät erfordert.
Angriff 8: Staatsmacht
Ein konzeptionell völlig anderer Ansatz wäre, Überwachungsschnittstellen nicht heimlich einzubauen, sondern diese gesetzlich zu fordern. Effektiv ist dies in einigen Bereichen bereits geltendes Recht, beispielsweise bei der Telekommunikationsüberwachung, festgelegt in der TKÜV: Jeder Provider muss eine Infrastruktur vorhalten, die das Nachverfolgen gewisser Datensätze erlaubt, etwa die Zuordnung von IP-Adressen oder E-Mails zu Personen.
In eine ähnliche Richtung gehen Versuche, den Einsatz von effektiver Kryptographie entweder ganz zu verbieten oder so zu reglementieren, dass Ermittlungsbehörden die Möglichkeit haben, Nachrichten zu dechiffrieren. Beim Key-Escrow-Verfahren werden beispielsweise Schlüssel und Zertifikate bei einer staatlichen Organisation hinterlegt.
Regulierte Überwachungsschnittstellen sind für Strafermittlungsbehörden aber nur dann effektiv, wenn sie flächendeckend zum Einsatz kommen. Das ist bei einigen Hundert Internet Service Providern noch möglich, übersteigt bei mehreren Millionen PCs aber alle Grenzen. Es wären weitreichende Änderungen an der kompletten IT-Infrastruktur vom PC-Design bis hin zu Kommunikationsanschlüssen notwendig. Dass so etwas lange Zeit braucht, zeigt die Einführung des TPM-Chips.
Ähnlich Erfolg versprechend wäre, die Schnittstellen oder Überwachungsfunktionen in strategisch günstigen Softwareprodukten einzubauen, etwa in Virenscanner oder Betriebssysteme. Im Zuge der Online-Überwachung haben zwar bereits mehrere Hersteller von Antivirensoftware öffentlich erklärt, dass sie einen Bundestrojaner wie jeden anderen Schädling behandeln werden, sobald sie einen finden. Ob sie auch direkt gegen Gesetze verstoßen würden, um ihre Benutzer zu schützen, bleibt fraglich.
Fraglich auch, ob Hersteller proprietärer Softwareprodukte standhaft bleiben, wenn der Staat ihnen Großaufträge in Aussicht stellt. Bei überwiegend international organisierten Open-Source-Projekten ist ein so tief gehender juristischer oder monetärer Einfluss hingegen schwer vorstellbar.
Angriff 9: E-Mail vom Staat
Einer der wenigen konkreten Vorschläge in der Diskussion um die Online-Untersuchung war, E-Mails von Behörden als Angriffsvektor zu nutzen. In deren Anhängen wären dann ausführbare Programmteile oder Makroviren enthalten. Im Vertrauen auf die Behörden soll der Empfänger die Mails und Attachments öffnen und ausführen; der weitere Verlauf wäre dann identisch mit den bereits beschriebenen Angriffen.
Dieser Vorschlag erscheint reichlich naiv. Es ist gegenwärtig noch nicht abzusehen, welchen Schaden allein die Diskussion um E-Government-Bemühungen öffentlicher Einrichtungen haben wird. Neben dem Vertrauensverlust gegenüber öffentlicher Mail lässt die vergleichsweise gute technische Unterstützung vieler Mailreader zur Spam- und Virenerkennung daran zweifeln, ob dieses Verfahren jemals effektiv sein kann.
Angriff 10: Social Engineering
Auch das Innenministerium hat erkannt, dass nicht nur technische Mittel allein zum Ziel führen. Der Begriff Social Engineering fasst Maßnahmen zusammen, die es einem Angreifer explizit ohne technische Maßnahmen erlauben, auf Daten im Zielsystem zuzugreifen. Einfache Beispiele umfassen das optische Ablesen der Tastatureingabe bei einem Passwort oder das Erraten von Zugangskennungen auf Grundlage persönlicher Umstände des Überwachten (Geburtsdaten oder Namen von Familienmitgliedern, Vereine oder Slogans).
Eine aufwändigere Form des Social Engineering ist, das Vertrauen der Zielperson oder eines Angehörigen zu erlangen. So könnten die Strafermittlungsbehörden beispielsweise Informationen gewinnen, die sie bei der weiteren Abstimmung der technischen Maßnahmen benötigen, also vor allem Angaben zur Systemkonfiguration. Oder sie könnten ihre Zielperson dazu bewegen, arglos trojanisierte Software zu installieren.
Patt-Situation
Der Blick auf Tabelle 1 lässt erkennen, wie sehr sich die Ansätze der Online-Überwachungen unterscheiden. Sie reichen von rein technischen bis zu organisatorischen und sozialen Maßnahmen. Gegen die meisten Varianten kann sich der mündige Anwender durchaus wehren. Er muss es sogar, um nicht das Opfer krimineller Angreifer zu werden, die genau die gleichen Techniken einsetzen. Das weiß auch der vom BKA angeheuerte Sicherheitsexperte.
|
Tabelle 1: |
|---|
Nun haben die Politiker wieder das Wort – hoffentlich verfallen sie nicht der Idee, dieses störrische Linux gleich ganz zu verbieten [12]. (fjl)
|
Infos |
|---|
|
[1] Entwurf des BKA-Gesetzes: [https://www.ccc.de/lobbying/papers/terrorlaws/20070711-BKATERROR.pdf] [2] Wikipedia, “Bundestrojaner”: [http://de.wikipedia.org/wiki/Bundestrojaner] [3] Fragenkatalog des Bundesministeriums der Justiz: [http://netzpolitik.org/wp-upload/fragen-onlinedurchsuchung-BMJ.pdf] [4] Thorsten Scherf, “Aide – Hilfe bei der Spurensuche”: Linux-Magazin-Sonderheft 01/05, S. 54 [5] Open Source Tripwire: [http://sourceforge.net/projects/tripwire/] [6] Mitre, “Common Vulnerabilities and Exposures List”: [http://cve.mitre.org/cve/] [7] Nils Magnus, “Druckerschwärze – Sicherheitsschwachstellen bei der Installation von proprietärer Software finden”: Linux-Magazin 09/07, S. 88 [8] Cert-Advisory “Trojan Horse Sendmail Distribution”: [http://www.cert.org/advisories/CA-2002-28.html] [9] Christoph Wegener, “Computer-Camouflage – Sicherheit von Virtualisierungslösungen”: Linux Technical Review 01, S. 74 [10] Bluepill: [http://bluepillproject.org] [11] “Die Zeit” online, “Gegenangriff auf Schäuble”: [http://www.zeit.de/online/2007/35/bundestrojaner-reaktionen] [12] Eitel Dignatz, “Glosse: Linux-Verbot dringend erforderlich – Linux versus Bundestrojaner”: Linux-Magazin 04/07, S. 90 |







