scaryBITS

Die letzten Monate sehen unspektakulär aus, wenn man durch die PC-Prospekte blättert. Trotzdem stellen sich auf dem Marktplatz spannende Fragen.

1. Tablet versus PC – drängen die Tablets zurück? Die Zuwachsraten sind spektakulär. Allerdings nur bedingt auf Kosten der PCs. Computergestütztes Arbeiten dürfte sich auch in Zukunft auf tastaturbewehrten Maschinen abspielen. Die Verbreitung der Tablets in betrieblichen Kontexten ist entsprechend bescheiden geblieben. Im Bereich Medienkonsum ist aber abzusehen, dass sich Tablets einen dauerhaften Platz erobern. 2011 sollen rund 70 Mio. Tablets abgesetzt werden – verglichen mit etwa 350 Mio. PCs. In vielen Haushalten wird sich halt der ganze Gerätepark breitmachen – vom internetfähigen TV über PC und Tablet bis zum Smartphone.

2. Minimargen. Die Schlenker von HP um die Frage, ob sich der Konzern aus dem PC-Geschäft zurückziehen soll, werfen ein Schlaglicht auf die äusserst knappen Margen im Geschäft mit Standard-PCs. Den Kunden kann es recht sein. Die meisten Konzerne lassen in Sachen Design und Profil der Produktelinien die nötige Konsequenz vermissen. Beides macht Apple besser und kann darum saftige Margen kassieren. Das ist ein mehr als netter Trost, wenn man nach Stückzahlen nicht zu den 5 grössten gehört. Allerdings steigt der globale Marktanteil langsam, sodass Apple in den nächsten Quartalen unter den Top 5 erscheinen könnte.

3. Volkseigene PCs. Lenovo gehört unter den Mainstream-Produzenten zu den Aufsteigern. Die Staatsmanager haben sich bisher keine grossen Patzer geleistet, wenn es um den Erhalt des ebenso langweiligen wie seriösen Images der IBM-Thinkpad- Linie ging. Die ermunternde Hand der chinesischen Staatsführung dürfte bei der Erschliessung des riesig gewordenen chinesischen Binnenmarktes hilfreich sein. Lenovo fordert die US-Konzerne heraus, wie das Diagramm mit den globalen Marktanteilen zeigt.

Avira Antivir beeinträchtigt unter bestimmten Umständen die Suche unter Windows, indem die Indexierung von Fileinhalten gestört wird. Beobachtet wurde die Störung zuerst unter Windows 7 32Bit mit Office 2010 und Avira Antivir Premium. Bestätigt unter Windows 7 64 Bit und Antivir Professional.

Entdeckt wurde das Problem erstmals bei der Untersuchung eines andern Indexierungsproblems, das nach der Installation von Adobe Reader 10 auftritt (hier dokumentiert). Generell für den User sichtbar wird die Problematik, indem etwa bei installiertem Office nicht mehr alle DOC und DOCX Files in einer Suche aufgelistet werden, obwohl das Suchstichwort im Text enthalten und die Option der Inhaltsindexierung aktiv ist.

Es tritt also nicht ein Vollausfall der Suche ein. Weil der Index kumulativ wächst, werden früher indexierte Files korrekt angezeigt. Richtig massiv werden die Lüken erst, wenn die Indexierung neu gestartet wird. Weiterhin vollständig gefunden werden Files, bei denen der Suchbegriff im Filenamen, Pfade oder Attributen vorkommt – und auch Objekte in Mailbox werden korrekt behandelt.

Der Verdacht ist aus zwei Gründen auf Antivir gefallen. Einmal haben schon andere User von ähnlichen Indexierungsproblemen mit McAfee berichtet. Generell ist AV immer eine gute Hypothese. Neben Malware greift nichts so tief ins System ein und klinkt sich in jeden Filezugriff ein. Zweitens zeigte sich eine Ungleichbehandlung von identischen Dokumenten in der Mailbox (zB als Attachment) und im Filesystem. Die Mailbox Inhalte wurden völlig korrekt indexiert. Es kann kaum eine fundamentale Störung des Indexierungsmechanismus vorliegen; auch die für Word Dokumente nötigen iFilter scheinen korrekt zu arbeiten.

Minitests

In einem kleinen Test 1 (W7 32 Bit) wird zuerst ein nicht gefundenes Dokument identifiziert, die Suche mit dem entsprechenden Stichwort aktiviert - kein Ergebnis. Dann wird Antivir in der Konsole disabled (AntiVir Guard). Dann wird das Dokument geöffnet, ein paar Leerschläge zugefügt und wieder gespeichert, um die Aktualisierung des Indexes anzustossen. Siehe da: Ohne weiteres Zutun erscheint nun das gesuchte Dokument im offenen Suchfenster.

Auf einem andern System (W7 64 Bit mit Avira Antivir Professional, MyDocuments auf Laufwerk D: verschoben) wird ein weiterer Test mit einem seit Monaten ohne Rebuild gewachsenen Index auf den Folder MyDocuments gefahren. Normale Suche zu häufigem Stichwort nach dem Muster mit expliziter Spezifikation im Suchfeld „content:Stichwort fileextension:=.docx“ ergibt 4 Items. Dann Avira disablen, Index neu aufbauen, Erneuerungsfeld auf der Suche anklicken: Sofort werden 78 Items gelistet. Nun den Virenschutz wieder einschalten, den Index wieder neu aufbauen, Erneuerungsfeld auf dem unveränderten Suchfenster mit den 78 Items anklicken – schwupp fast alles weg: gefunden wird nur noch 1 Dokument – dasjenige in dem soeben der Text dieses Beitrags verfasst wurde.

 Workaround?

Falls sich das Ganze als allgemeiner Bug bestätigt, liegt wahrscheinlich ein Implementierungsproblem von Antivir vor. Es könnte aber auch ein Bug von Windows sein, der nur in dieser Konstellation relevant wird. Leider gibt es keinen eleganten Workaround. Zumutbar ist weder ein jeweiliges Wegschalten des Virenschutzes beim Kopieren oder Speichern von Dokumenten noch ein periodischer Neuaufbau des Idexes bei ausgeschaltetem Virenschutz. Wir hoffen, dass das Problem bald identifiziert und behoben werden kann.

ANMERKUNG: Wer Tests mit Neuaufbau von Indexes auf einem produktiven Rechner fahren möchte, kann den Mailclient schliessen – die Tausenden von Mails werden dann vorerst nicht indexiert und der Test geht viel schneller vor sich.

ERGÄNZUNG 24.2.11: Testsetup

Um die gefundene Hypothese zu testen, muss die Frage geklärt werden: Indexiert der Windows Indexin Service bei laufendem wie weggeschalteten Antivir identisch? Ein ideales Testsetup müsste folgendermassen aussehen:

1. Eine W7 Maschine mit Office 2010 aufsetzen, MyDocuments auf Partition D: verschieben, eine Dokumentemenge von einigen Tausend Dokumenten hineinkopieren.
2. Die automatische einsetzten Indexierung abwarten (beobachtbar mit “Indexing Options”), dann ein paar Suchafragen mit teilweise häufigen Begriffen starten, Zahl der gefundenen Dokumente notieren.
3. Avira Antivir installieren, aktualisieren. Dann unter “Indexing Options /Advanced / Rebuild” den Index neu aufbauen. Dann die identischen Suchabfragen laufen lassen und sehen, ob mit dem unter Avira Antivir erzeugten Index das gleiche gefunden wird.

Ob das Verschieben von MyDocuments auf Partition D: relevant ist, bleibt völlig offen. Der oben erwähnte zweite Test kommt dem Idealszenario nur bedingt nach, weil er auf einer Produktionsmaschine mit weiteren Programmen und historisch gewachsenen Settings abgewickelt wurde.

ERGÄNZUNG 25.2.11: Test unter Labor-Bedingungen bestätigt Störung

Ein Test auf einer blanken Virtuellen Maschine (Windows 7 SP1 32 Bit) bestätigt die Hypothese, das Avira die Indexierung und damit die Suche massiv stört. Spalte 2 zeigt die Anzahl Suchergebnisse, die auf dem Index der blanken Maschine beruhen, Spalte 3 Suchergebnisse, die auf dem bei laufendem Avira Antivir Professional mit „Rebuild“ neu aufgebauten Index beruhen. Mit einem bestimmten Suchausdruck gefundene Anzahl Dokumente:

 Auf die Testmaschine wurde einzig das Office 2010 Filter Pack 32 Bit installiert, um realistische Bedingungen für die Inhalts-Indexierung von Word-Dokumenten zu schaffen. Total wurde mit rund 3000 RealWorld Dokumenten gearbeitet, darunter auch PDFs, die in diesem Setting inhaltlich nicht indexiert werden können.

Wer auf einer Windows 7 32Bit Maschine Adobe Reader 10 installiert, erlebt eine böse Überraschung. Im Gegensatz zu Reader 9 sind nun PDF-Dokumente nicht mehr mit der Windows Search Funktion durchsuchbar. Ein eleganter Ausweg ist momentan nicht in Sicht.

Aus Sicherheitsgründen ist ein Reader Update auf Version 10 dringend erwünscht.  Warum Adobe nun keine Lösung für das Durchsuchen von Dokumenten anbietet, bleibt nebulös.

Filter nötig

Windows 7 kommt mit einer gegenüber XP massiv verbesserten Indiexier- und Suchfunktion daher. Eine Indexierung ist für schnelle Suche unabdingbar und findet üblicherweise im Hintergrund statt. Genau wie bei den Servern ist auch bei Windows 7 Indexierung modular implementiert. Auf den Basismechanismu setzen sogenannte iFilter auf. Diese Filter enthalten Mechanismen, die für das Entziffern bestimmter Codierungen nötig sind. An Bord hat Windows plus Office eine Reihe von Filtern etwa für normalen Text, für HTML oder Office Dokumente.

Drittanbieter mit proprietären Codierungen sind eingeladen, den Kunden iFilter anzubieten, damit die entsprechenden Objekte unter Windows durchsucht werden können. Bestimmte PDF sind in Ausnahmefällen mit dem Windows Textfilter durchsuchbar, nämlich dann, wenn sie Klartext enthalten. Das ist normalerweise nur bei gescannten Dokumenten der Fall. Da fügt manchmal eine OCR-Komponente den Text als Klartext mit  ins Dokument ein. Normale PDF Files sind aber proprietär codiert und erfordern einen iFilter, um auf Ebene Windows durchsuchbar zu sein.

In Rohform können die codierten PDF schon auch ohne iFilter indexiert werden, wenn das Durchsuchen des Inhalts eingestellt wird (auf „Index Properties an File Contents“). Nun können diese PDFs in Suchen erscheinen, wenn nur ein einzelner Buchstabe eingegeben wird. Aber bereits bei Eingabe eines weit verbreiteten Artikels wie “the” oder “das” bringt kein einziges normales PDF-Dokument als Suchergebnis.

Noch beim Adobe Reader 9 hat Adobe auf 32Bit Systemen einen iFilter mitgeliefert und im Hintergrund gleich installiert. Mit Version zehn liefert Adobe keinen Filter mit, ohne dem User den Funktionsverlust bei Suchen klar zu machen. Einzig in einem FAQ findet sich ein wenig klärender Beleg: „The iFilter shell extension has a limitation with Microsoft Desktop Search and is not installed with Reader X“.

Adobe Ausweg nur für 64Bit Windows

Für 64Bit Systeme kann auf den entsprechenden Filter zurückgegriffen werden, den Adobe in Version 9 anbietet. Eine Installation auf zwei Testystemen verlief reibungslos. Der Installer setzt auch gleich die Option des Filetyps PDF auf das Indexieren auch von Content („Index Properties and File Contents“). Nach dem erforderlichen Neuaufbau des Indexes zeigt die Windows 7 Suche perfekt auch die Ergebnisse nach Stichworten aus dem Innern on PDF Dokumenten an (Indexing Options / Advanced / Rebuild). Der Indexierservice schafft pro Stunde einige zehntausend Dokumente und Mails, sofern er ungestört werkeln kann. Bei Userinteraktion schaltet er auf ressourcenschonenden Minimalbetrieb, da kann sich der Neuaufbau des Indexes über Stunden hinziehen. Am besten vor der Mittagspause starten.

Für 32Bit System bietet Adobe weder eine Lösung noch eine Erklärung an. Das wirkt einigermassen befremdlich angesichts des Bedeutung, welche das Suchen nicht nur im Internet, sondern auch im eigenen Dokumentenbestand hat. Eine Testinstallation des veralteten iFilter Version 6 von Adobe hat das Problem nicht gelöst – andere haben die gleiche Erfahrung gemacht. Microsoft zeigt in einem W7 Artikel zwar auf diese alte Version 6 von Adobe. Wie das auf W7 zum Laufen gebracht werden kann, ist offen. Adobe selbst nennt in der entsprechenden Doku weder Vista noch W7 als untersützte OS. Eine allfällige Lösung bietet die Firma PDFlib mit PDFlib TET PDF IFilter auf die in einem Geschwindigkeitstest von einem MSDN Blog verwiesen wird. Eine Komponente von kaum einschätzbarer Qualität ins Betriebssystem einzupflanzen, ist aber nicht jedermanns Sache.

Es ist der Münchner Firma hoch aber anzurechnen, dass sie eine kostenlose Lösung anbietet, die funktioniert. Beim Test auf einem virtuellen Windows 7 32 Bit zeigt die Suche nach Installation des  PDFlib TET PDF IFilter umgehend indexierte PDFs an, auch wenn kein PDF-Viewer installiert ist. In der geeigneten Preview wird auch gleich Text aus dem Inhalt angezeigt, welchen der iFilter ja ohnehin dekodieren muss, um ihn dem Indexing Service von Windows darzubieten:

Wenn nun Adobe Reader 10 installiert wird, lässt er immerhin den installierten iFilter der Konkurrenz unbehelligt. Adobe legt voerst den Indexing Service lahm, sodass das unbeschwerte Suchen und Anschauen erst nach einem Neulogin (oder Reboot) möglich ist. Natürlich muss immer der Aufbau des Indexes abgewartet werden.

ANHANG: Technische Details zu Index, Suche, iFilters

Out oft the Box (und nach Installation von Office) läuft Indexieren und Suchen in einer robusten Default Konfiguration.

Unter Windows 7 können mit „Indexing Options“ verschiedene Einstellungen vogenommen werden: welche Folderst sollen indexitert werden; nur Attribute oder auch Inhalt; Neuaufbau des Indexes.

Ein Blick auf Windows 7 64 Bit nach erfolgreicher Installation von iFilter Version 9:

1) Wie werden PDF Files bei der Indexierung gehandhabt?
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.pdf\PersistentHandler
darin der default
{F6594A6D-D57F-4EFD-B2C3-DCD9779E382E}

2) Jetzt suchen wir nach ID F6594A6D-D57F-4EFD-B2C3-DCD9779E382E und finden
HKEY_CLASSES_ROOT\CLSID\{F6594A6D-D57F-4EFD-B2C3-DCD9779E382E}
darin registriert als Persistent Addin
\PersistentAddinsRegistered\{89BCB740-6119-101A-BCB7-00DD010655AF}
mit dem Wert default
{E8978DA6-047F-4E3D-9C78-CDBE46041603}

3) HKEY_CLASSES_ROOT\CLSID\{E8978DA6-047F-4E3D-9C78-CDBE46041603}\InprocServer32
darin der default, zeigt auf die iFilter DLL:
C:\Program Files\Adobe\Adobe PDF iFilter 9 for 64-bit platforms\bin\PDFFilter.dll

Wenn unter Punkt 1) der Persistent Handler auf {5e941d80-bf96-11cd-b579-08002b30bfeb}
zeigt, ist das der default Handler für .txt und andere Klartextfiles. PDF Dateien werden dann nur nach Klartextteilen indexiert: gescannte PDFs mit OCR Klartexteinschüben werden erschlossen, normale PDF nicht.

ANHANG Links

• Kurze Beschreibung zu iFiltern auf Servern von Adobe.
• MS Übersicht über Windows Search in W7 und Server 2008
• MS Übersicht Indexing Process
• Technisches Konzept der iFilter
• Microsoft Blog zu Filters
• Filterregistrierung Doku und älterer Artikel

Ein nicht enden wollender Strome von Verletzlichkeiten wird Tag für Tag publiziert. Das zeigt ein Blick auf die entsprechende Page von secunia, wo täglich zehn bis zwanzig aufgelistet werden. Wie sieht der Lebenslauf einer Verletzlichkeit aus?

Wir betrachten hier nur Verletzlichkeiten in Design und Implementierung von Betriebssystem und Programmen. Verletzlichkeiten werden beim Schreiben von Software in den Code eingebracht – im Normalfall ohne Absicht. Es ist durchaus möglich, mit einem LifeCycle Management die Zahl der Fehler pro Million Codezeilen substantiell zu reduzieren. Vollständig eliminieren lassen sich Fehler nicht. Nicht alle Verletzlichkeiten erleben die gleiche Geschichte.  Wir können vier Szenarien unterscheiden.

Latent. Eine Verletzlichkeit existiert – aber niemand weiss davon. In jedem der gängigen Betriebssysteme sind hunderte bis tausende von unbekannten Verletzlichkeiten versteckt. Für eine Sicherheitsstrategie sind sie trotzdem relevant. Sie können innerhalb von Stunden den Status ändern – sie können entdeckt und ausgenutzt werden.

Referenz. Im Normalfall wird eine Verletzlichkeit von einem wohlmeinenden Dritten entdeckt  und gemeldet, oder der Hersteller entdeckt die Verletzlichkeit gleich selbst. Sie bleibt vorerst der Malwareszene verborgen, der Hersteller entwickelt und publiziert einen Patch. Erst jetzt erscheint bei relevanten Verletzlichkeiten innerhalb kurzer Zeit Malware – durch Reverse Engineering konnte aufgrund des Patches die Verletzlichkeit identifiziert werden. Kritisch ist in diesem Szenario die Zeit von der Publikation zum Aufspielen des Patches. Bei hunderten von Millionen Maschinen auf der Welt ist diese Zeit in vielen Fällen unendlich lang, etwa bei vielen gecrackten XP Installationen in Emerging Markets.

Zero Day. Eine Malware erscheint, bevor der Hersteller einen Patch bereit hat. Aufgrund der Unberechenbarkeit der Situation und der misslichen Lage des Herstellers ist das Problem leicht emotionalisierbar, womit Publikationen und Publikum gerne spielen. Das Risikopotential wird häufig überschätzt für die Fälle, wo dämpfende Mechanismen auf den Maschinen intakt sind. Semispontane epidemische Verbreitungsmuster sind heutzutage nicht mehr möglich, wo Standardrechner eine Firewall hochgefahren haben. Bei Servern sieht das anders aus, Admins müssen sich sorgfältig um Verletzlichkeiten kümmern, die einen öffentlich zugänglichen Service betreffen. Es geht um Webserver, ftp-Server, Loginmechanismen und Vergleichbares.

Opak. Dabei wird eine Verletzlichkeit von BadGuys entdeckt und ausgenutzt – ohne dass Hersteller und Öffentlichkeit davon erfahren. Es darf angenommen werden, dass eine grössere Anzahl (mehrheitlich staatlich angestellte) SpezialistInnen an diesem Thema arbeiten. Für entsprechende stille Attacken rücken Umgebungen und exponierte Personen ins Zentrum, völlig unabhängig vom Betriebssystem. Hilfreich gegen solche Angriffe ist immer ein von Technologie und Konfiguration her maximal resilientes System in Kombination mit zurückhaltenden Verhaltensweisen.

Für Private und Kleinbetriebe ist eindeutig das Referenzszenario das wichtigste. Nicht oder nicht rechtzeitig eingespielte Patches ist für die grosse Mehrheit der Kompromittierungen verantwortlich. Zero Day Situation spielen in weit weniger als zehn Prozent der Zwischenfälle eine Rolle. Das Motto heisst patchen und überwachen. Das Betriebssystem automatisch patchen lassen – die Anwendungen überwachen, auf Windows Maschinen etwa mit Secunia PSI.

DIAGRAMM: Lebenslauf-Szenarien von Verletzlichkeiten:

Der Mainstream PC-Markt entwickelt wenig spektakulär. Dynamisch ist die Entwicklung am mobilen Rand.

2010 haben die Verkäufe von Media Tablets insbesondere dank der iPads ein sprunghaftes Wachstum verzeichnet: Es wurden rund 17 Mio. Stück verkauft, dieses Jahr sollen es gemäss IDC 45 Mio. Stück werden. Das Wachstum ist spektakulär, die Marktanteile vorläufig noch nicht. Verglichen mit den 346 Million PCs und Laptops macht das 2010 rund 5% und dürfte 2011 auf über 10% steigen. Wo wird sich das in fünf Jahren einpendeln?

Tablets werden ihren Platz finden, allerdings nicht in der ersten Reihe. Da bleiben einerseits für produktive Arbeiten Arbeitsplatzrechner und Laptops. Den mobilen Pol andererseits dürften Smartphones dominieren, die ja eher als Computerkategorie denn als Telefon gelten dürfen.

Tablets dürften aufgrund der massvollen Preise und spezifischer Nutzungsmöglichkeiten in der Freizeit erhebliche Stückzahlen erreichen, aber eher spezialisierte Nischen füllen. Für produktive Arbeit einerseits zu wenig ergonomisch, für unterwegs nicht so mobil und robust wie ein Smartphone, zum Lesen und Surfen unter freiem Himmel aufgrund der Displaytechnologie vorderhand ungeeignet: Seine Stärken können sich eher als gehobener Medienplayer und Surfstation zuhause, im öV oder Hotel zeigen.

Klar sind Tablets Computer. Ob sie bei Marktbetrachtungen mit PCs und Laptops in einer Gruppe betrachtet werden sollen, kann mit guten Gründen postuliert werden. IDC verfolgt die verschiedenen Kategorien separat. Wenn schon Enduser-Computer aggregiert betrachtet werden sollen, müssten logischerweise auch Smartphones dazu genommen werden. Das sind aber doch funktional und kommerziell verschiedene – wenn auch überlappende – Segmente.

Am PC-Markt bewegt sich nichts fundamentales – HP hat offenbar ein gutes Weihnachtsgeschäft erlebt:

Seit Monaten wird in der Fachcommunity eine neue Möglichkeit diskutiert, Schadsoftware auf einem modernen Betriebssystem zu platzieren: JIT Spraying. Beispielsweise kann mit dem Just In Time Compiler von Flash aus einem entsprechenden ActiveScript heraus Malware in den Speicher eingebracht werden. Ob sich „das Blatt wieder zu Gunsten der Angreifer“ wendet, wie heise.de voraussagt?

Auf aktuellen Windows Systemen scheitern konventionelle Versuche, etwa mit Buffer Overflows Malware zu starten. Das wird durch Markierung von Speicher als „nicht ausführbar“ (Data Execution Prevention DEP) und die zufällige Platzierung von Modulen (Address Space Layout Randomisation ASLR) bewirkt.

Auf der Suche nach Speicherplatz, der beschrieben und ausgeführt werden kann, fällt der Blick auf Scriptinterpreter wie Active Script. Um die Ausführungsgeschwindigkeit zu beschleunigen, werden Scripts on the run erst kompiliert und dann ausgeführt. Mit geeigneter Manipulation des Scriptcodes können so auch spezielle Muster erzeugt werden: Malwarestücke.

Teilautonom

Das Risiko entsteht nicht darum, weil DEP ausgetrickst wird, denn DEP funktioniert auf der Basiseben des Systems und seiner Prozesse konsistent. Das Problem entsteht, weil hier auf dem System relativ entkoppelte Teilsysteme – eigentlich Codefabriken – existieren. Es ist keine Lücke, sondern eine Funktion dieser Codefabriken, Lauffähigen Code zu erzeugen. Verschiedene Aspekte sind problematisch:

• Es gelangt unsignierter Programmcode auf das System, zB Scripts von einer Website.
• Die Scripts werden in reproduzierbarer Weise in direkt lauffähigen Code gewandelt.
• Der Compiler ist vom Betriebssystem entkoppelt, die entsprechenden Mechanismen greifen nicht.

Es grundsätzlich problematisch, lauffähigen Code auf einem System zuzulassen. Gegenüber dem Herunterladen und Laufenlassen beliebiger *.exe Files hat sich in den letzten Jahren eine angemessen kritische Haltung auch bei vielen Usern verbreitet. Gegenüber Scripts hat sich eine gewisse Sorglosigkeit gehalten, auch im professionellen Umfeld. Einerseits vertraut man auf die Zuverlässigkeit von Interpretern in einer Browser-Sandbox. Andererseits wird gar nicht kritisch diskutiert, weil die serverseitige Entwicklung zu immer mehr Scripts hin ging. Der Webserver versendet Objekte und Scripts – die Page wird dann durch den Browser beim User zusammengebaut. Viel sicherer wäre natürlich, dem User nur Objekte darzubieten.

Die massive Verbreitung von Scripts hat nun die Browser-Programmierer unter Druck gesetzt, aus Performancegründen zu kompilieren. Google war mit Chrome und beeindruckenden Performance-Vorteilen Vorreiter dieser Entwicklung.

Riskioabschätzung

Das Teilproblem, Malwarescripts zu erzeugen, die kompiliert lauffähige Malwareelemente ergeben, darf als gelöst angesehen werden. Auf einem aktuellen Windows-System müssen aber eine Reihe von weiteren Hürden überwunden werden, bis eine Kompromittierung des User-Kontexts gelingt. Härtung des Compilers: Die Browserproduzenten dürften einzelne Härtungsmechanismen einbauen, wenn das Problem praktisch relevant werden sollte. Sandboxing: Ein Malwarefragment im Browserkontext kann nur selektiv auf Funktionen des Systems zugreifen. Integrity Level: Ein Malwarefragment im Browserkontext kann keine höher eingestuften Prozesse ansprechen oder kreieren.

Leider schweigen sich die vorliegenden Publikationen darüber aus, wie das Potential in Bezug auf ein aktuelles System und in der realen Welt zu bewerten ist. Vorläufig ist noch nichts über lebensfähige Implementierungen im realen Ökosystem bekannt. Auf ein halbes Jahr hinaus betrachtet dürfte die praktische Relevanz äusserst bescheiden sein. Das mittelfristige Potential ist vorhanden, das Ausmass bleibt offen und hängt auch von den Gegenmassnahmen der Compilerbauer ab.

Für Maschinen mit Top Security Maschinen muss diskutiert werden, ob nicht ein absolutes Whitelisting angesagt ist, das auch Scripts umfasst. Unter 64 Bit Windows können die Nebenfolgen in der 64Bit Instanz von Internet Explorer schon mal getestet werden: Flash gibt da schon gar nicht, Java Script und Active Script kann im Browser weggeschaltet werde.

Wenige Meinungsverschiedenheiten gibt es über folgende These: Der Webbrowser gehört zur Topkategorie von Applikationen, wenn es um Sicherheit geht. Wie aber ist die Sicherheit der einzelnen Produkte zu bewerten? Gibt es ein besonders empfehlenswertes Produkt?

Leider gibt es weder wissenschaftliche Modelle noch technische Guidelines, welche die zentrale Frage seriös beantworten: Welches Risiko geht ein User in Realworld Szenarien mit verschiedenen Browsern ein? Es bleibt nur eine zurückhaltende Interpretation einzelner Indizien.

Verletzlichkeiten

Für Aufsehen hat kürzlich eine von Bit9 veröffentlichte “Dirty Dozen” Apps List gesorgt. Die Daten stammen aus der Datenbank des U.S. National Institute of Standards and Technology (NIST). Webbrowser sind in der Hitparade prominent platziert:

1. Google Chrome (76 reported vulnerabilities)
2. Apple Safari (60)
5. Mozilla Firefox (51)
8. Microsoft Internet Explorer (32)

Um eine Vergleichsmöglichkeiten zu gewinnen, habe ich die Verletzlichkeiten der 2009 aktuellen Browserversionen bei Secunia nachgeschlagen. Das ergibt für die drei am weitesten verbreiteten Produkte folgende Zahlen für die relevanten Verletzlichkeiten (moderately, highly und extremely critical):

Google Chrome (5.x 6.x 7.x):   12
Firefox 3.6:   9
IE 8.x:    8

Die publizierten Verletzlichkeiten bilden ein relevantes Indiz. Sie verweisen auf Probleme mit der Codequalität. Vermutlich ist bei Microsoft die Codequalität etwas höher, als die Zahlen auf den ersten Blick vermuten lassen, denn die Aufdeckungsrate von Verletzlichkeiten dürfte beim Marktführer erheblich höher sein. Google hat aus guten Gründen Security bei Features und Produktion von Anfang an hoch gewichtet, in der Praxis scheint aber die Qualität unter der hastigen Entwicklungspace zu leiden. Sollte sich der Aufwärtstrend fortsetzten und Chrome auch mal wie Firefox auf 20% Marktanteil kommen, entfällt der momentane Nischenschutz: Der Angriffsdruck dürfte die Rate der aufgedeckten Verletzlichkeiten steigen lassen.

Die Secunia Zahlen müssen mit Vorsicht interpretiert werden. Sie repräsentieren nicht einzelne Verletzlichkeiten, sondern jeweils ganze Bündel davon.

Patching und Security Features

Verschiedene Browser repräsentieren unterschiedliche Patchingphilosophien: Internet Explorer mit berechenbarem Monatsrhythmus, Firefox mit Hochfrequenz, Google verdeckt. Ganz generell kann nicht von der Überlegenheit eines Modells gesprochen werden. Das hängt vom Anwendungsfall ab. Generell kann den Herstellern attestiert werden, dass sie das Problem ernst nehmen und besser im Griff haben, als beispielsweise Adobe mit seinen Produkten.

Hier kann keine ausführliche Analyse der Security Features geleistet werden. Der Trend geht in die richtige Richtung. Die Infrastruktur des Betriebssystems wird besser genutzt (DEP, ASLR, Integrity Levels, Prozess per Tab). Der Browser wird vom System durch Sandboxing entkoppelt.
Zudem bringen die Browser Mechanismen mit, um üble Sites zu identifizieren, Downloads zu sichern und CrossSiteScripting zu erschweren.

Zusammenfassend

… lässt sich feststellen:

1. Das Qualitätsniveau der führenden Browser ist nicht befriedigend (aber noch problematischer sind einzelne Plugins und die Qualität zahlreicher Websites).

2. Alle drei führenden Produkte bewegen sich in der gleichen Security-Bandbreite.

3. Security ist bei den Browserentwicklern momentan etwas an den Rand gerückt – alles dreht sich um Speed und HTML 5 Kompatibilität.

Das heisst nicht, dass Internet Explorer 9 oder Firefox 4 weniger sicher als die Vorgängerversionen sein werden. Es besteht aber das Risiko, dass die weiten neu codierten Teile (GPU Acceleration etc.) erneut von unangenehm vielen Verletzlichkeiten gespickt sein könnten. 2011 zu beobachten.

Im dritten Quartal hat sich wenig weltbewegendes getan. Der Neuigkeitsbonus der Netbooks ist definitiv verschwunden, sie sind ein Teil des Laptop Marktes geworden. Diskutiert wird berechtigterweise die Frage, ob Tablets in Zukunft auch als normale Mitglieder der PC- und Laptop Familie erscheinen sollen. Das würde die Chancen für Apple verbessern, in den nächsten Jahren unter die Top 5 nach Stückzahlen vorzustossen. Hier die Marktanteile der einzelnen Mitspieler – IDC führt leider nur die top 5 respektive 6 auf.

Softwareverletzlichkeiten wurden erfunden, um Professionalität und Nervenstärke der IT-Branche jahrzehntelang auf die Probe zu stellen. Das Leiden bei Profis und Amateuren dauert. Secunia tritt an, einen Ausweg auf dem Patching Fegefeuer zu markieren. Der neue Personal Software Inspector (PSI) 2.0 Beta soll über das Aufdecken von Lücken hinaus auch einen Teil derselben automatisch patchen können. Ein kurzer Test.

Wir ziehen einen Windows 7 Laptop aus dem Schrank, der dort einige Wochen gedöst hat. Die Installation geht flink voran, der Inspector 2.0 Beta kann gestartet werden. Auf dem schlank gehaltenen Laptop dauert es etwa zwei Minuten, bis die Anwendungen in bekannt zuverlässiger Art analysiert sind. Die meisten sind Up-to-date und interessieren nicht weiter. Bei den patchbedürftigen Apps treten nun ganz verschiedene Szenarien auf:

1. Running update. Da detektiert der Inspector richtigerweise, dass (hier für Adobe Reader) ein Updateprozess am Laufen ist und kein zusätzlicher Handlungsbedarf besteht.

2. Install Solution. Am vorliegenden Beispiel in fünf von sieben Fällen sieht der Inspector keine Möglichkeit, das Patching direkt zu erledigen und verweist auf die Webpage des Herstellers. Möglicherweise betrifft das alle Fälle, wo die Installation einer neuen Version fällig wird oder Windows Update involviert ist.

3. Kein Kommentar. Im Fall des Cisco VNP Client 5.0.04 stellt der Inspector zu Recht Handlungsbedarf fest – liefert aber keinen Patching Hinweis.

4. Automatic. Im vorliegenden Fall nicht aufgetreten, dem Vernehmen nach gibt es aber entsprechende Apps, wo PSI automatisches Patchen anbietet.

Fazit: Mit der nötigen Vorsicht geht PSI 2.0 Beta in Richtung eines eleganten Patchings. Vorläufig bleibt das Ziel aber noch in weiter Ferne und es besteht für EndanwenderInnen kein Grund, auf diese Beta zu wechseln. Profis in Windows-Umgebungen sollten die Entwicklung aufmerksam verfolgen und sich eine Testinstallation ansehen.

Was secunia vor Monaten angekündigt hat, wird nun schrittweise umgesetzt: Der Personal Software Inspector 2 kann Patchingbedarf nicht nur identifizieren, sondern auch Patches installieren.

Die soeben veröffentlichte Betaversion patcht vorerst nur eine Minderheit der analysierten Programme. Trotzdem zeichnet sich hier für Private User und Kleinbetriebe eine Möglichkeit ab, rationeller einen akzeptablen Patching Stand zu erreichen.

Der Zeitpunkt könnte nicht günstiger sein. Die aktuellen DLL Loading Risiken sind bei zahlreichen Applikationen identifiziert worden. In den nächsten Wochen und Monaten dürfte sich ein Schwall von Patches und Updates über die User ergiessen. Für die Betreiber von standalone PCs lohnt es sich, das neue Produkt genauer anzusehen.