Serie Zero Day – Teil 2

Zero Day Situationen sind nichts für schwache Nerven. Die Vorstellung einer bestimmten ungepatchten Verletzlichkeit scheint sich gut zum Hochkochen von Emotionen zu eignen. Statt sich täglich mit Qualitätssicherung herumzuplagen ist es natürlich einfacher, von Zeit zu Zeit etwas Aktivismus zu entfalten. Jedenfalls haben Zero Day Situationen in den letzten Jahren bei IT-Hobbyisten wie Profis unangemessen hohe Aufmerksamkeit genossen – auf Kosten wirklich relevanter Qualitätsverbesserungen. Warum? Hier einige Hintergründe.

Paranoia. Die Vorstellung einer vorerst „unheilbaren“ Verletzlichkeit im PC scheint mit schweren unheilbaren Krankheiten vergleichbare Vorstellungen zu aktivieren. Wie gross die reale Risikoerhöhung gegenüber dem ständigen Backgroundrisiko ist, interessiert kaum.

Bashing. Einem grossen Konzern einen nicht sofort behebbare Fehler nachzuweisen ist eine wunderbar emotionalisierte Anomalie. Solche Situationen sind bestens geeignet, um verdeckte Agendas zu verfolgen und sein eigenes Weltbild zu stabilisieren.

Publizistik. Nicht nur die Tagespresse sondern auch die Computerheftli wissen, dass viele ihrer LeserInnen lieber emotionalisiertes Kurzfutter lesen, als nüchterne Problemanalysen. Der Presse kann das nicht zum Vorwurf gemacht werden. Eine andere Frage ist, ob auch professionelle Milieus so ticken sollen.

Green IT. IT ist grün im Sinne einer unreifen, sich wild entwickelnden Technologie. Das macht diese Branche so spannend. Entsprechend grün wirkt dann halt in manchen Teilen auch die professionelle Kultur. Hier sind private Haltungen und diffuse Argumente in einem Ausmass präsent, wie dies in reiferen Bereichen wie etwa dem Maschinenbau kaum denkbar ist. So fehlt etwa ein fachlicher Konsens, wie für einen Maschinenpark Risiken zu bewerten und zu managen sind.

Impressionismus. Wo eine auch nur skizzenhafte Vorstellung von Risikomanagement fehlt, wird eine Umgebung anfällig für zufällige und publizistisch hochgekochte Einzelfälle.

Ressourcenmangel. In manchen Hochschulumgebungen ist das der zentrale Background. Die IT-Verantwortlichen werden gelegentlich derart knapp gehalten, dass an das Erarbeiten und Umsetzen einer konsistenten Strategie nicht zu denken ist. So wird eine reaktive Haltung geradezu erzwungen.

CERTismus. In der IT Security haben reaktive Muster aufgrund historischer Umstände weiterhin übermächtiges Gewicht. Die erste relevante Institutionalisierung ist in Form von Reaktionszentren erfolgt – Computer Emergency Respons Teams CERT. Das war aus dem Nichts ein grosser Fortschritt, entspricht aber nicht mehr den Anforderungen des Internet-Zeitalters. Nun geht es zentral um das proaktive Handhaben und Reduzieren von Risiken. Die Maschinen müssen widerstandfähig und die User risikobewusst werden.

Serie Zero Day – Teil 1

Eine Zero Day Situation entsteht, wenn zu einer momentan nicht patchbaren Verletzlichkeit Malware am Horizont erscheint. Wie ist die so entstehende Lage zu bewerten und einzuordnen?

Der Begriff Zero Day wird üblicherweise im Zusammenhang mit Exploit verwendet. Ein Exploit ist eine Arte Demoprogramm, das die Ausnutzbarkeit einer Verletzlichkeit dokumentiert.

Die so belegte Ausnutzbarkeit klärt einen Aspekt einer Verletzlichkeit. Das heisst, die Verletzlichkeit ist nicht nur theoretisch ein Problem, sondern technisch prinzipiell ausnutzbar. Die Relevanz einer Verletzlichkeit rutscht eine Stufe nach oben.

Allerdings klärt die Existenz eine Exploits noch nicht die Frage, ob eine in der realen Welt funktionierende Malware möglich ist und welche Verbreitungschancen sie hat. Die Abschätzung des Risikopotentials bleibt schwierig.

Teilmenge von ungepatcht

Aufgrund der Unsicherheit und des Mangels einer simplen Lösung sorgen Zero Day Situationen für Aufmerksamkeit. Ihre Bedeutung wird häufig überschätzt und muss darum im Kontext diskutiert werden. Zero Day Situationen sind nur eines von verschiedenen Szenarien der Kategorie „ungepatchte Verletzlichkeit“:

1) Unbekannt: Weder bekannt noch genutzt. Betriebssystem und Anwendungen enthalten Dutzende bis hunderte von Verletzlichkeiten, die zu einem bestimmten Zeitpunkt niemandem bekannt und von niemandem genutzt werden.
2) Selektiv: Nicht öffentlich bekannt, von diskreten Akteuren genutzt. Einzeltäter, organisiertes Verbrechen, Privatdetektive und staatliche Dienste versuchen, unbekannte Verletzlichkeiten zu finden und selektiv über Monate oder Jahre auszunutzen.
3) Zero Day: Öffentlich bekannte momentan patchlose Verletzlichkeit mit Zero Day Exploit oder Zero Day Malware. Zeitlich begrenzte Situation, wo eine Verletzlichkeit mangels Patch nur Workarounds begrenzt werden kann.
4) Ungepatcht: Ungepatcht trotz publiziertem Patch. Aufgrund mangelnder Systempflege dürften weltweit mehrere hundert Millionen Systeme in diesem Zustand am Netz operieren.
5) Veraltet: Ungepatcht weil nicht mehr patchbar. Verletzlichkeiten bleiben offen, weil veraltete Versionen von Betriebssystem und Applikationen verwendet werden, die gar nicht mehr mit Patches unterstützt werden.

Relevanz

Generell wird das Gewicht von Zero Day Situationen im Vergleich zu anderen Risiken überschätzt. Auf die Gründe werden wir in einem weiteren Beitrag eingehen. Ausgehend von den Erfahrungen an der ETH Zürich lässt sich die Bedeutung der verschiedenen Szenarien für Windows Kompromittierungen wie folgt zusammenfassen:

a) Für rund 95% der Vorfälle ist das Nicht-Installieren existierender Patches oder die Verwendung veralteter Software verantwortlich. Das hat nichts mit Zero Day zu tun.

b) Für etwa 5% der Vorfälle in den letzten Jahren sind Zero Day Situationen verantwortlich. Eine Ausnahmesituation herrschte im Frühsommer 2010, wo nicht patchbare Adobe Reader und Flash Verletzlichkeiten eine Menge Kompromittierungen zur Folge hatten.

Völlig zu Recht weisen secunia und Publikationen wie heise online darauf hin, dass ungepatchte Applikationen zum Hauptrisiko geworden sind. Adobe rückt aufgrund der zahlreichen Lücken und der weiten Verbreitung der Produkte ins Zentrum der Aufmerksamkeit. Auf einem aktuellen Windows PC bilden Flash und Adobe Reader die Hauptpforte für den Eintritt von Malware beim Besuch verseuchter Websites.

Firmen wie Adobe verdienen die Aufmerksamkeit und Unterstützung der IT-Community. Sie bilden wichtige Bollwerke gegen eine völlige Monopolisierung von Applikationen und Content durch die nimmersatten Trampeltiere Apple, Google und Microsoft. Allerdings ist jede Rücksichtnahme kontraproduktiv, wenn sich etwa Adobe in Sachen Security suboptimal verhält: Bereits heute ist der Trend feststellbar, dass verunsicherte User und Admins sich unter den Schirm eines grossen Imperiums flüchten und möglichst alles aus einer Hand beziehen wollen, nachdem sie sich mit unsicheren Produkten von Drittanwendern und Open Source Communities die Finger verbrannt haben. Dieser Trend spielt momentan zu Gunsten von Apple, in einigen professionellen Umgebungen aber auch zugunsten von Microsoft.

Adobe leistet sich verschiedene Suboptimalitäten in Sachen IT-Security.

Inzwischen ist die Notwendigkeit einer Life Cycle Pflege der Produkte bei Adobe erkannt und es wurde ein Schema etabliert, das aber nicht angemessen ist. Ein reguläres Patching nur alle drei Monate vorzusehen, ist problematisch bei den vielen Verletzlichkeiten. Folgerichtig musste jüngst Adobe bereits das Schema brechen und wichtige Verletzlichkeiten kurz vor dem regulären Termin schliessen.

Wenig bekannt und begeisternd ist, dass Adobe dem User zwangsweise weitere Applikationen installiert, wenn dieser bloss Adobe Reader und ein Flash Plugin haben möchte. Der aufmerksame Windows User findet folgendes in seiner Programmverwaltung:

Adobe AIR ist ein eigentliche Anwendungsumgebung wie Java oder .NET. Damit schafft Adobe eine Infrastruktur für das browserlose Laufenlassen von Adobe Apps. Adobe.com – ein unsäglich verwechslungsträchtiger Name – scheint ein Konferenzprogramm zu sein. Beides mögen nette Dinge sein – für den Durchschnittsuser sind sie einfach unerwünschte neue Risiken.

Es fehlt ein Adobe Security Center, das auf einen Blick die vorhandenen Komponenten und ihren Security Status zeigt und verwaltet. Adobe würde es aber auch gut anstehen, die Initiative zu einer „Application Patching Platform“ zu ergreifen, in welche App Lieferanten ihre Patches einspeisen könnten.

Auf der Testseite für Flash Plugins muss der User „von Hand“ die detektierte Version mit einer Liste vergleichen, statt dass gleich eine Warnung und die Möglichkeit zum Update gezeigt wird.

Adobe wäre gut beraten, in Sachen Security mehr Dampf aufzusetzen, wenn es in sich in fünf Jahren nicht in einer marginalen Nische wiederfinden will.

Seit etwa 2007 verbreiten sich Varianten von Gozi auf Windows Rechnern und sammeln dort Account Informationen. Der professionell designte Trojaner zielt auf Bankkunden, taucht aber in den letzten Wochen auch häufiger an Hochschulen auf.

Gozi kann vor allem den Anwendern und Admins richtig wehtun. Den Usern können eBanking- und andere Konten ausser Kontrolle geraten. Admins sind mit einer Malware auf dem Stand der Technik konfrontiert, die auf dem System schwierig zu anaylsieren und unter Kontrolle zu bekommen ist.

Gozi kann verschieden Versionen von Windows befallen. Unter XP betrieben unter Admin-Rechten installiert er sich auf Ebene des Systems. Unter Windows7  wo der User out of the Box mit Standarduserrechten arbeitet, im Userkontext respektive Userprofil, ohne dass der Kern des Systems kompromittiert wird. Diese und weitere Infos sind rein indikativ, solange keine konsistente technische Analyse der Malware inklusive Versionshistory greifbar ist!

Ansehen…

Um eine Befallshypothese zu prüfen, kann unter XP etwa der folgende Registry-Eintrag angesehen werden, der auf ein Gozi DLL zeigt – zumindest bei einzelnen momentan aktuellen Varianten: Ein Fehlen dieses Eintrags bedeutet nicht dass ein System Gozi-frei ist!
HKLM\System\CurrentControlSet\Control\SessionManager\AppCertDlls

Unter Vista/W7 kann der der Autostart-Pfad lauten:
HKU\{UserSID}\Software\Microsoft\Windows\CurrentVersion\Run\lsasasrv:
“rundll32″C:\Users\{UserName}\AppData\Local\Temp\fontnatt.dll”,DllEntryPoint”

Detektion mit AV: Auch führende Produkte wie Avira von der Rescue CD erkennen aktuelle Mitglieder der Gozi-Familie nicht (immer). 

… und Aufräumen

Eine befallene Box sauber zu bekommen heisst: Neuinstallation. Ausnahmen können sich nur qualifizierte Profis genehmigen – unter ein paar Bedingungen:

• Es sind tiefe Systemkenntnisse verfügbar, um versteckte Systemmechanismen detektieren
• Es ist klar, welche Malwareversion vorliegt, sodass entsprechende Removal-Tips wirklich zutreffen
• Es kann analysiert werden, dass keine weitere Malware auf dem System existiert

Kurz und gut: Weder ein Virenscan noch das Abarbeiten eines Removal Tips garantieren ein porentief reines System.

Prävention

Mögen die Wege von Gozi in das System noch so raffiniert sein – sie nützen Verletzlichkeiten aus. Waren das in früheren Jahren solche des Internet Explorer, sind das nun zB ungepatchte Löcher des Adobe Readers: „We witnessed a number of Gozi Trojans distributed via malicious PDF versions.“ Stellt eine Analyse der TrustDefender Labs fest.

Gozi Prävention heisst wie immer: Nicht nur Windows, sondern auch Anwendungen und Plugins ständig auf die neueste Version upgraden und alle Patches einspielen.

Ein Virenschutz mit aktuellen Definitionen ist hilfreich, kann aber Patchen nicht ersetzen. Gerade Gozi Varianten bleibt durch die Verwendung neuer Techniken häufig wochenlang durch verschiedene Virenscanner unentdeckt. Das gilt auch für HiEnd Produkte von Symantec oder Avira, welche eine neuere Version unter dem Label TR/Spy.Banker.Germ.A führt.

Informationen

Einen guten neueren Überblick bietet Gozi – a perfect example of an “older” trojan re-inventing itself der bereits erwähnten TrustDefender Labs.

Historische Analyse von SecureWorks  2007.

Beispiel für die Beschreibung einer bestimmten Instanz durch eine AV-Firma ist TR/Spy.Banker.Germ.A – Trojan von Avira. Etwas müde Sophos, letzte Update im Januar – hier heisst der Trojaner Troj/Gozi-Gen und es werden Aliases aufgeführt: Trojan.Win32.Agent.cbr und Generic PWS.o .

Mit der wachsenden Beliebtheit von USB-Sticks und mobilen Harddisks sind diese Medien zu immer wichtigeren Verbreitungsmitteln für Malware geworden. In bester Erinnerung ist Conficker, der unter anderem auf diese Verbreitungsmöglichkeit hin ausgelegt war.

Bekannt ist, dass ursprünglich mit Hilfe von autorun.inf auf dem Stick nach dem Einstecken direkt eine Software gestartet werden konnte – wenn die Systemkonfiguration es zuliess. Weniger bekannt ist, dass auch der Userdialog gestaltet werden konnte. Das geht auf ein traditionelles Feature zurück, das ein komfortables Startmenu etwa auf Installations-CDs erlaubt. So konnte auch vom Stick im öffnenden Dialogfenster zB ein Menupunkt „Open Folder to view files“ mit Icon eingeblendet werden, der wie vom System geschaffen aussah. Ein Klick darauf öffnete nicht den Folder, sondern startete direkt die Malware.

Diese Möglichkeit ist bei Windows 7 für USB-Sticks eliminiert worden. Der Dialog stammt ausschliesslich vom System – gefälschte Einträge sind ausgeschlossen. Das verhindert natürlich nicht, dass User auf dem Stick browsen und per Maulklick und Bestätigung eine Malware starten. Ein Blog-Eintrag erläutert das.

Für Windows Vista und XP wird diese Beschränkung mit dem Patch kb 971029 installiert.

Info zum Feature AutoRun-Enabled Application. KB 967715 liefert Information zum Wegschalten und Konfigurieren von Autorun. Das für Vista dokumentierte gilt auch für Windows 7. Die mit gpedit.msc setzbaren Parameter werden auch direkt in der Konsole dokumentiert.   

Patchen ist schon für die privaten Hüter eines Windows-PCs eine Herausforderung – und auch Mac-User sammeln da ja inzwischen Erfahrungen. Ganz andere Dimensionen nimmt Patchen an, wenn es um hunderte oder tausende von Arbeitsplatzrechnern geht.

Während die Lieferanten von Betriebssystem etwas breitere Lösungen für ihren Lieferumfang bieten, kochen die andern Softwarelieferanten ihre eigenen Süppchen. Es gibt keine Standards und schon gar keine gemeinsame Patchingplattform, über die alle Applikationen up to date gehalten werden könnten.

Während sich Oracle, Microsoft und Adobe immerhin zu einem zeitlich strukturierten Vorgehen durchgerungen haben, lassen alle andern zu jeder beliebigen Tages- und Nachtzeit neue Patches und Updates auf die IT-Kundschaft los.

Project Quant: Suche nach einem Framework

Bei grossen Unternehmen und Institutionen ist in den letzten Jahren immer klarer geworden, dass Patching nicht mit ein paar Quick&Dirty Vorgehensweisen in den Griff zu bekommen ist. Darum haben sich mehrere grösser Player zu einem Projekt Quant zusammengefunden, um ein konzeptuelles Framework fürs Patchen zu erarbeiten. Wer in dem Papier “Measuring and Optimizing Patch Management: an Open Model” blättert sieht bald, wie anspruchsvoll und komplex die Herausforderung ist. Wer mit dem Patchen von grösseren Horden von Maschinen befasst ist, sollte vielleicht einen Blick auf dieses Projekt werfen.

Microsofts Patching Strategie

Im Windows Imperium hat sich Microsoft vor ein paar Jahren unter erheblichen Mühen neu ausgerichtet und konsistente Positionen zum Thema Sicherheit, Verletzlichkeiten und Patching erarbeitet. In seinem Papier “The Microsoft Security Update Guide” werden Begriffe, Klassierungskriterien, Benachrichtigungskanäle, Updatemechanismen und andere Elemente erläutert. Nichts sensationelles, aber ein geordneter Überblick für alle IT-Profis, die mit Windows und also auch mit Security zu tun haben.

Adobe hat in den letzten Monaten Schritte in Richtung von mehr Code Quality und periodischem Patching gemacht. Die Ansätze des Konzerns bleiben aber ziemlich unübersichtlich.

Es beginnt bei den Produkteinstanzen. Auch manchen Profis dürfte kaum klar sein, wie sich bei Flash das Plugin zum Player verhält. Erst ein gründliches Studium des Dokuments “Adobe® Flash® Player 10 Administration Guide” klärt diese und weitere Fragen. Der Flash Player wird “normalerweise” (Adobe) als Plugin installiert. Dieses gibt es in zwei Formen – als Browserplugin für Firefox und Verwandte sowie als ActiveX für den Internet Explorer. Es gibt den Flash Player auch als standalone Produkt, der ist aber eher für Entwickler gedacht. Weil bei Adobe Dokumenten immer von Flash Player die Rede ist, bleibt häufig offen, was nun genau gemeint ist.

Der Flash Player ist das wohl wichtigste Plugin für Multimedia-Content auf dem Web. Die entsprechenden Verletzlichkeiten sind aufgrund der weiten Verbreitung ziemlich relevant und sollten leicht zu patchen sein.

Updaten periodisch…

Der Flash Player hat eine periodische Versionsprüfung installiert, die beim Installieren auf 30 Tage gesetzt ist. Dieser Default ist wenig tauglich, weil User bei grassierenden Exploits wochenlang nichtsahnend mit einem veralteten Plugin weitersurfen.

Sucht der User unter Programmen oder unter Plugins ein Interface für die Konfiguration des Flash Player, läuft er ins Leere. Wer unter der Hilfe des Acrobat Readers via Updates zu den ‘ Adobe Updater Preferences’ vorstösst, findet keine Spur von Flash.

Für Flash hat sich Adobe einen Weg über den Webserver ausgedacht. Auf der Seite Flash Player Help finden sich die Links zum Settings Manager und dessen einzelnen Reitern. Unter Global Notification Settings lässt sich dann zumindest die Prüf-Periode von 30 auf 7 Tage reduzieren.

Lokale Settings via einen Konzernwebsite verstellen, das ist in Sachen Sicherheit wie Usability einigermassen fragewürdig. Adobe sieht sich denn auch genötigt, die User-Verwirrung mit folgender Bild… sorry: Toolunterschrift zu klären: “Note: The Settings Manager that you see above is not an image; it is the actual Settings Manager.”

Weitere Parameter sind unter Windows nicht etwa in der Registry – sondern in einer proprietären Location qua File mit dem Namen mms.cfg abgelegt. Hier kann Autoupdate beschränkt und konfiguriert werden. Dazu mehr im bereits erwähnten “Administration Guide”. Das Hantieren mit Parameterfiles ist, wie der Titel des Guides sagt, nichts für EndanwenderInnen.

…oder von Hand

Aufgrund der mangelhaft implementierten Automatismen wählen updatewillige User wohl oder übel erst mal den Weg zum Versions-Check mit dem Titel “Version test for Adobe Flash Player”. StudentInnen der Web-Usability können sich hier den Kopf darüber zerbrechen, warum ein Weltkonzern hier dem Anwender das manuelle Nachschlagen überlässt, ob die identifizierte Version auch die neueste ist. Stand der Technik wäre hier eine Diskrepanzmeldung mit dem Angebot zum Download. Immerhin ist im Text ein Link zum Adobe Flash Player Download Center eingebettet.

Während Microsoft die grösste Patchingbaustelle mit einem ziemlich konsistenten Modell bewirtschaftet, kann auf dem zweitgrössten Bauplatz bei Adobe davon keine Rede sein. Die Firma konstatiert mit berechtigtem Stolz: “Flash Player is installed on 98% percent of the world’s desktop computers”. Wie viele davon sind wohl auf dem neusten Stand?

LINKS:

Adobe Flash Player 10 Administration Guide:
http://www.adobe.com/devnet/flashplayer/articles/flash_player_admin_guide.html

Versionscheck
http://kb2.adobe.com/cps/155/tn_15507.html

Installieren / Updaten:
http://get.adobe.com/flashplayer/

Settings Manager:
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager.html

Die kürzlich bekannt gewordene Zeros Day Verletzlichkeit der Video ActiveX Komponente kann beim Browsen unter XP gefährlich werden, wenn der Internet Explorer auf entsprechend präparierte Seiten zugreift. Vista ist nicht betroffen. Obwohl Exploits in manipulierten Websites erscheinen, ist für die User in gepflegten Umgebungen vorläufig nur von einer mässigen Risikoerhöhung auszugehen. Microsoft hat einen Workaraound zum Wegschalten der verletzlichen Komponente publiziert, der für exponierte Umgebungen geprüft werden sollte.

Die Wogen auf dem IT-Boulevard gehen diesmal etwas weniger hoch als bei der letzten prominenten Internet Explorer Verletzlichkeit Ende letzten Jahres. Von der ernstzunehmenden Verletzlichkeit mit Exploits wurde allzu direkt auf eine angebliche Infektionswelle geschlossen. Aber nichts passierte.

Nun wie damals ist die Verletzlichkeit äusserst relevant uns sollte beim Erscheinen des Patches umgehend geschlossen werden. Um zu entscheiden, ob ausserordentliche Aktionen nötig sind, müssen verschiedene Szenarien unterschieden werden:

1. Notallmässige Reaktion in Minuten bis Stunden: Wenn vom Internet direkt zugreifbare Services betroffen sind und Exploits zirkulieren, müssen umgehend risikomindernde Massnahmen getroffen werden. Beispielsweise bei einem Webserver.

2. Rasche Reaktion in Stunden bis wenigen Tagen: Wenn netzrelevante Komponenten wie der Webbrowser betroffen sind und zugleich eine hohe Wahrscheinlichkeit des Kontakts mit infizierten Websites anzunehmen ist, sollten risikomindernde Massnahmen getroffen werden. Das gilt insbesondere für Systeme, auf denen die grundlegenden Sicherheitsmassnahmen nicht lückenlos implementiert sind.

3. Rasche Implementierung des Patches nach Publikation: Auf gepflegten Systemen kann bei nur sporadischer Verbreitung der Malware die Publikation des Patches abgewartet werden. Auf einem sachgemäss betriebenen System sind mehrere Sicherheitselemente aktiv, welche auch bei Kontakt mit der Malware die Wahrscheinlichkeit einer Kompromittierung verkleinern. Gerade bei den stark beachteten Verletzlichkeiten sind etwa die Topprodukte der Virenschützer gut vorbereitet.

Ein Blick auf hunderte von Incidents an der ETH zeigt: Es sind die ganz normalen Qualitätsmängel, welche zum Befall mit Malware führen – nicht spektakuläre einzelne Verletzlichkeiten.

Letzte Nacht hat Adobe einen Patch zu einer wichtigen Verletzlichkeit veröffentlicht, die seit einigen Wochen offen ist. Problematisch ist, dass einen halben Tag nach der Publikation der Reader 9.0.0 unter Umständen meldet: “no updates available” (Help / Check for Updates). Möglicherweise ist das Wegschalten gewisser Adobe-Komponenten dafür verantwortlich. In einem Advisory rät Adobe zum Update auf Version 9.1 und zwar manuell durch Besuchen des Links http://get.adobe.com/reader/

UPDATE 19. März: Adobe publiziert die Updates für die älteren Adobe Reader.  “Adobe recommends Adobe Reader users update to Adobe Reader 9.1… Users with Adobe Reader 7.0 through 8.1.3, who can’t update to Adobe Reader 9.1, should update to Adobe Reader 8.1.4 or Adobe Reader 7.1.1″ (Advisory vom 18.3.09).

Wer sich mit Adobe beschäftigt, kann gleich auch noch nachsehen, ob die neueste Flash Player Version installiert ist (LINK).

Microsoft hat letzte Nacht wichtige Patches publiziert. Dass Adobe einen Tag früher als angkündigt eine neue Version des Readers publiziert, ist auch auf Kritik gestossen: “… releasing it on the same day as Microsoft’s planned March patch spells disaster for enterprise resource planning, and it still leaves Adobe with a black eye for lack of communication”. In der Tat. Die ewige Patcherei ist schon schlimm genug. Hau Ruck Methoden machen es noch schlimmer.