Schwachstellen in Dritthersteller-Komponenten sind das Thema dieses Standpunkt Sicherheit.

"Schwachstellen im Lieferumfang inbegriffen"

So oder so ähnlich müsste es bei vielen Programmen auf der Verpackung, bzw. in der Anleitung stehen - immer dann, wenn Komponenten von Drittherstellern mitgeliefert oder eingebunden, aber nicht regelmäßig aktualisiert werden. Anlass des heutigen Themas sind eine Beobachtung aus den vergangenen Wochen sowie ein Eintrag im Handler's Diary des ISC vom Samstag. Zuerst zu der Beobachtung: Da gab es z.B. Updates für die Windows-Versionen von OpenVPN und VooDoo cIRCle, durch die eine von der SSL/TLS-Renegotiation-Schwachstelle betroffene OpenSSL-Version ersetzt wurde, und eine Meldung zu einer nicht behobenen Schwachstelle im Spam Inspector, die durch die Verwendung einer angreifbaren Version des EasyMail SMTP Object ActiveX Control verursacht wird. Der Eintrag im Handler's Diary des ISC hat den Titel 'What is making you vulnerable?' Mark Hofman stellt darin fest, dass einige ältere Schwachstellen in VMware behoben wurden, die sich in Dritthersteller-Produkten befanden, und weist darauf hin, dass es noch viel mehr Programme gibt, die veraltete Komponenten beinhalten.

Wer hats verbockt?

Im Grunde genommen haben wir hier mehrere Konstellationen, die jeweils unterschiedliche Reaktionen der Hersteller erfordern:

Der einfachste Fall: Open-Source-Software unter Linux, die andere Open-Source-Software nutzt. Ein gutes Beispiel dafür ist z.B. OpenVPN mit OpenSSL. Schwachstellen im OpenSSL werden von den Linux-Distributionen behoben, OpenVPN findet immer eine aktuelle OpenSSL-Version vor. Theoretisch, praktisch kann es natürlich passieren, dass die Distribution beim Verteilen von Updates sehr langsam ist oder die Benutzer die Updates nicht installieren oder ... - aber im Prinzip sollte auf einem aktuell gehaltenen Linux-System keine veraltete Software vorhanden sein. Und im Notfall kann der Benutzer ja manuell eine fehlerfreie Version installieren.

Der nächste Fall wird schon etwas schwieriger: Open-Source-Software unter Windows, die mit anderer Open-Source-Software gebündelt wurde. Auch dafür ist OpenVPN mit OpenSSL ein gutes Beispiel: OpenVPN bringt eine eigene OpenSSL-Version mit, die dann auch von den OpenVPN-Entwicklern aktuell gehalten werden muss (was die auch sehr vorbildlich tun!). Frei nach dem Motto "Mitgegangen, mitgefangen, mitgehangen" ist jeder Hersteller dafür verantwortlich, dass nicht nur seine eigenen Programme, sondern auch dazu gepackte fremde Komponenten keine Schwachstellen enthalten. Allerdings hat der Benutzer im Fall von Open-Source-Software zumindest theoretisch die Möglichkeit, im Notfall selbst eine veraltete Komponente durch eine fehlerfreie Version auszutauschen.

Der dritte Fall ist schließlich der schlimmste: Closed-Source-Software, die fremde Komponenten nutzt. Und dabei ist es eigentlich egal, ob das nun Open-Source-Software oder ebenfalls Closed-Source-Software ist. Theoretisch könnte man zwar auch in diesem Fall Open-Source-Software durch fehlerfreie Versionen austauschen, praktisch wird das aber oft an speziellen Anpassungen etc. scheitern. Und bei eingebundener Closed-Source-Software hat man sowieso verloren. Ein gutes Beispiel für so einen Fall ist der Spam Inspector mit seinem angreifbaren ActiveX-Control, das der Hersteller längst aktualisiert hat: Die Aktualisierung hilft dem Nutzer des Spam Inspector nichts, da er das Control nicht selbst austauschen kann. Hinzu kommt, dass die Benutzer oft nicht einmal wissen, dass sie da ein manchmal riesengroßes Loch im System haben - wer weiß schon so genau, was wann von welchen Programm mal installiert und vielleicht nie aktualisiert oder beim Löschen des Hauptprogramms nicht deinstalliert wurde? Auch in diesem Fall gilt also wieder das "Mitgegangen, mitgefangen, mitgehangen".

Überblick verloren? Dann mal schnell einen verschaffen...

Während bei Linux-Systemen die jeweiligen Distributionen quasi automatisch dafür sorgen, dass keine veralteten Komponenten installiert sind (was nicht ausschließt, dass nicht doch mal ein Programm eine fest verlinkte Library mitbringt, die von alten oder auch neuen Schwachstellen betroffen ist), muss für Windows jeder Hersteller dafür sorgen, dass alle mit seinem Programm mitgelieferten Komponenten aktuell bleiben. Wenn der das nicht tut, hat man ein Problem. Ebenso, wenn der Hersteller einer Komponente dem Hersteller des Hauptprogramms im Ernstfall keine fehlerfreie Version liefern will oder kann. Trotzdem (oder gerade deshalb) ist der Rat von Mark Hofman im Handler's Diary des ISC wichtig: Verschaffen Sie sich einen Überblick über die installierten Dritthersteller-Komponenten und verlassen Sie sich nicht darauf, dass die Hersteller der Programme, die die mitgebracht haben, schon für ihre Aktualität sorgen werden. Zwar werden Sie in den meisten Fällen nicht in der Lage sein, veraltete Komponenten selbst auszutauschen, aber zumindest können Sie dann erst mal prüfen, ob überhaupt veraltete Komponenten vorhanden sind und/oder ob sie bekannte Schwachstellen enthalten. Und nur wenn Sie wissen, dass sie eine angreifbare Komponente auf den Rechner haben, können Sie die Gefährdung einschätzen, Workarounds in Betracht ziehen und/oder dem Hersteller, dem sie das Problem verdanken, nach einem Update zu fragen oder zur Beseitigung des Problems zu drängen.

Eigene Nase noch da?

Wenn Sie selbst fremde Komponenten mit eigenen Programmen ausliefern, stellen Sie sich mal die Frage, ob die wirklich immer aktuell sind und wie Sie im Ernstfall dafür sorgen, dass Ihre Kunden nicht das Opfer einer Schwachstelle in einer fremden Komponente werden. Denn nicht nur der eigene Code muss frei von Schwachstellen sein, sondern das gesamte ausgelieferte Paket. Schließlich ist auch eine Kette aus Programmen nur so stark wie ihr schwächstes Glied. Und egal ob ein Einbruch nun über Ihren Code erfolgt oder über von Ihnen mitgelieferten - für den Kunden sind Sie der Verantwortliche für die Schwachstelle, die ja nur deshalb auf seinen Rechner ist, weil er Ihr Programm installiert hat.