Software::Browser
Probleme mit der Sicherheit von WebKit
Gnome-Entwickler Michael Catanzaro berichtet in seinem Blog über den desaströsen Zustand der WebKit-Varianten unter Linux. Seit einigen Wochen laufen Initiativen, die Fehlerbehebungen endlich auch wieder in die Distributionen zu bringen. Ein massives Problem mit älteren Programmen bleibt jedoch.
webkit.org
Architektur von WebKit2
WebKit ist eine freie Webbrowser-Engine. Ihr Code entstammte ursprünglich einem Fork der Bibliotheken KHTML und KJS von KDE, aus dem Apple den Safari-Browser konstruierte. Der Kern von WebKit, der plattformunabhängig ist, und die Apple-spezifischen Erweiterungen werden von Apple gepflegt, wobei entdeckte Sicherheitslücken regelmäßig beseitigt werden. Ganz anders stellt sich die Situation jedoch bei den Portierungen von WebKit dar. Diese Portierungen waren lange Zeit in einem katastrophalen Zustand, was sich erst jüngst besserte. Wann die Korrekturen allerdings bei den Benutzern der Linux-Distributionen ankommen, ist wiederum sehr unterschiedlich.
Wie Gnome-Entwickler Michael Catanzaro erläutert, sind für Linux die Portierungen WebKitGTK+, WebKitEFL und QtWebKit relevant. Die beiden ersten gehören zu WebKit selbst, während für QtWebKit das Qt-Projekt verantwortlich ist.
Auf dem Desktop von untergeordneter Bedeutung ist WebKitEFL für die Enlightenment-Bibliotheken. Samsung ist der einzige Hersteller, der WebKitEFL in eingebetteten Geräten einsetzt, und hat bisher noch kein einziges Sicherheitsupdate herausgegeben. In der Zwischenzeit wurden im offiziellen WebKit weit über hundert Sicherheitslücken geschlossen.
QtWebKit war bis vor kurzem ebenfalls ein großes Problem. Es wird von zahlreichen KDE-Programmen eingesetzt. Qt selbst wechselte bereits 2013 zu QtWebEngine, die auf dem von Google initiierten WebKit-Fork Blink beruht. Der Code von QtWebKit ist aber weiterhin vorhanden, Sicherheitslücken wurden jedoch in dem veralteten Code fast komplett ignoriert. Das könnte sich bessern, wenn die Arbeiten an der Aktualisierung von QtWebKit ihren Weg in Qt finden, was aber anscheinend noch offen ist.
Sehr kompliziert ist die Situation bei WebKitGTK+, der Portierung für GTK+, die im Gnome-Browser Epiphany und vielen Gnome- und GTK+-Programmen verwendet wird. Korrekturen, die in WebKitGTK+ einflossen, wurden bisher meist nicht nach ihrer Wichtigkeit kategorisiert, so dass viele Distributionen wichtige Updates ausließen. Unter anderem verhinderten auch Schwierigkeiten in der Kommunikation mit Apple, dass Sicherheitsupdates mitgeteilt wurden. Erst Ende letzten Jahres verbesserte sich das wieder und das Projekt gab eine Notiz mit 130 behobenen Lücken heraus, von denen allerdings nur ein Teil für WebKitGTK+ relevant ist.
Diese Korrekturen in die Distributionen zu bringen, ist aber auch kein leichtes Unterfangen. Rolling Release-Distributionen wie Arch Linux liefern einfach die neueste Version und sind damit aus dem Schneider. Andere liefern nur Updates von einer stabilen Version auf die nächste aus; Fedora 22 und 23 beispielsweise werden in Kürze von Version 2.8.x auf 2.10 umstellen. Andere Distributionen versuchen ihre Versionen langfristig stabil zu halten, was eine Menge Arbeit beim Rückportieren der Korrekturen verursacht. Ubuntu macht sich diese Arbeit erst gar nicht, denn WebKitGTK+ gehört zum Universe-Repositorium, das von Ubuntu nicht unterstützt wird. Etwas besser macht es Debian, das Updates in den Repositorien »testing« und »unstable« bereitstellt und für die stabile Distribution ausdrücklich darauf hinweist, dass es WebKitGTK+ nicht unterstützen kann. Catanzaro zeigt ein gewisses Verständnis für diese Haltung, die aber zweifelsohne ein Problem darstellt, und regt die Gründung eines neuen stabilen Zweiges von WebKitGTK+ an, der nur Sicherheitsupdates erhält.
Zusätzlich zu diesen Problemen leidet WebKitGTK+ noch an der Umstellung der Schnittstelle (API) durch die Einführung von WebKit2. Dieses Problem war laut Catanzaro selbstverschuldet. Statt das API des originalen WebKit parallel zum WebKit2-API anzubieten, wurde es aus WebKitGTK+ 2.6 entfernt, was Probleme für alle Anwendungen bedeutete, die noch nicht umgestellt waren. Zwar hatten die Entwickler ein Jahr Zeit für die Umstellung, für größere Projekte war das jedoch nicht zu schaffen, da der Aufwand dafür immens ist. Das alte WebKitGTK+ 2.4, inklusive all seiner Sicherheitslücken, wird also weiter benötigt. Catanzaro schließt aus, dass die Lücken in WebKitGTK+ 2.4 korrigiert werden, da das zuviel Arbeit sei. Auch die Rückkehr des alten APIs in WebKitGTK+ scheint aus dem gleichen Grund ausgeschlossen. Es bleibt eigentlich nur, dass die Distributionen WebKitGTK+ 2.4 entfernen und dadurch viele gute Anwendungen dem Untergang weihen. Da aber Evolution und Empathy zu den betroffenen Anwendungen gehören, dürfte diese Option genauso auszuschließen sein.
){kind=small}
