Fire Scrolling – als selbst Scrollen zur Sicherheitslücke wurde

Im Jahr 2005 machte mit Firescrolling eine besonders ungewöhnliche Sicherheitslücke in Firefox Schlagzeilen. Anders als klassische Angriffe nutzte sie keine fehlerhaften Passwörter oder manipulierte Downloads, sondern eine alltägliche Handlung: das Bewegen der Scrollleiste.

Ein einfacher Scrollvorgang konnte ausreichen, um fremden Code im Browser auszuführen. Unter bestimmten Umständen sogar mit Zugriff auf sensible Systemfunktionen.

Was war Firescrolling?

Firescrolling war keine einzelne Schwachstelle, sondern eine Kombination mehrerer Sicherheitsprobleme in frühen Firefox-Versionen. Dabei wurden mehrere Techniken miteinander verknüpft:

Der Angriff funktionierte, indem der Browser eine eigentlich geschützte interne Benutzeroberfläche (eine sogenannte privilegierte XUL-Datei) öffnete und anschließend durch Benutzerinteraktion unbeabsichtigt ausführte.

Wie der Angriff funktionierte

Scrollen statt Klicken

Der Angreifer brachte den Nutzer dazu, die Scrollleiste einer Webseite zu bewegen – nicht einmal, sondern zweimal.

Dabei geschah im Hintergrund Folgendes:

1. Ein Plugin lud eine interne Firefox-Datei (z. B. chrome://...) in einen unsichtbaren Bereich.
2. Das Scroll-Ereignis wurde technisch „umgeleitet“.
3. Der Browser öffnete eine privilegierte XUL-Datei.
4. Enthielt diese Datei ein eingebettetes Skript, wurde es automatisch ausgeführt.

Ein bekanntes Beispiel war:

chrome://global/content/alerts/alert.xul

Diese Datei erzeugte eine Benachrichtigung – harmlos wirkend, aber technisch bereits mit Systemrechten ausgestattet.

Warum das gefährlich war

Der Code lief mit besonderen Rechten

XUL-Dateien gehörten zum inneren Aufbau von Firefox. Sie liefen nicht mit den eingeschränkten Rechten normaler Webseiten, sondern konnten:

Der ursprüngliche Bericht von mikx beschrieb das so sinngemäß:

Wenn ein solches XUL-Skript Funktionen wie eval() oder setTimeout() verwendet, kann daraus eine vollständige Code-Ausführung entstehen.

Besonders kritisch waren Update-Routinen, Deinstallationsskripte, Konfigurationsdialoge und Erweiterungen mit unsauberem Code.

Viele Entwickler rechneten damals nicht damit, dass ihre internen XUL-Dateien direkt von außen geöffnet werden könnten.

Die erste und zweite Variante von Firescrolling

Fire Scrolling – die ursprüngliche Angriffskette

Die erste Version von Firescrolling erschien Anfang 2005 und basierte nicht auf einer einzelnen Sicherheitslücke, sondern auf einer Kombination mehrerer bereits bekannter Probleme in Firefox. Dazu gehörten unter anderem Fireflashing, Firetabbing, unzureichend isolierte Plugins sowie manipulierte Drag-and-Drop-Ereignisse.

In dieser Konstellation genügte es, den Nutzer dazu zu bringen, die Scrollleiste einer Webseite zweimal zu bewegen. Dabei wurde im Hintergrund eine privilegierte XUL-Datei geladen, deren eingebetteter Code automatisch ausgeführt werden konnte. Je nach Zielseite konnte dies bereits dazu führen, dass Dateien heruntergeladen oder weitere Aktionen im Browser ausgelöst wurden, ohne dass der Nutzer etwas davon bemerkte.

Betroffen waren Firefox 1.0 sowie die Mozilla Suite unter Windows und Linux. Das CVE-Projekt führte diese Variante später unter der Kennung CAN-2005-0527.

Firescrolling 2 – die verbliebene Schwachstelle

Mit Firefox 1.0.1 wurden zwar einige der beteiligten Fehler behoben, ein zentrales Problem blieb jedoch bestehen: Plugins konnten weiterhin interne XUL-Dateien in versteckten Frames öffnen.

Auf dieser Grundlage entstand Firescrolling 2. Auch hier wurde zunächst unauffällig eine privilegierte XUL-Datei geladen, deren eingebettetes Skript beim nächsten Scroll- oder Drag-and-Drop-Vorgang ausgeführt werden konnte. Die veröffentlichte Demonstration zeigte lediglich eine harmlose Benachrichtigung, machte aber deutlich, dass sich derselbe Mechanismus auch für wesentlich kritischere Angriffe missbrauchen ließ, etwa gegen Update-Funktionen, Erweiterungen oder Konfigurationsbereiche des Browsers.

Diese zweite Variante wurde schließlich im März 2005 mit Firefox 1.0.2 geschlossen und erhielt die CVE-Kennung CAN-2005-0401.

Betroffene Systeme:

• Firefox 1.0
• Firefox 1.0.1
• Mozilla Suite 1.7.x

Nicht betroffen: Firefox ab Version 1.0.2

Warum Fire Scrolling als Warnsignal galt und welche Lehren daraus gezogen wurden

Firescrolling machte deutlich, dass Sicherheitsprobleme nicht nur in fehlerhaftem Programmcode entstehen, sondern auch im Zusammenspiel von Benutzeroberfläche, Plugins und internen Browserfunktionen.

Bis dahin galten Aktionen wie Scrollen oder Ziehen mit der Maus als technisch unkritisch. Es zeigte jedoch, dass selbst solche alltäglichen Bewegungen missbraucht werden konnten, um sicherheitsrelevante Abläufe auszulösen.

Der Vorfall führte dazu, dass Browserhersteller begannen, auch scheinbar harmlose Benutzerinteraktionen als möglichen Angriffspunkt zu betrachten. Komfortfunktionen mussten fortan nicht nur benutzerfreundlich, sondern auch streng isoliert und abgesichert gestaltet werden.

Das Entdecken von Fire Scrolling trug dazu bei, das Sicherheitsdesign moderner Browser grundlegend zu verändern. Die Trennung zwischen Webseiten, Plugins und internen Browserkomponenten wurde danach deutlich verschärft.

Warum Firescrolling heute kein Problem mehr ist

Eine völlig andere Browser-Architektur

Dass Firescrolling heute keine praktische Rolle mehr spielt, liegt nicht an einem einzelnen Sicherheitsupdate, sondern an tiefgreifenden Änderungen in der Architektur moderner Browser.

In den frühen Firefox-Versionen waren Webseiten, Plugins und interne Browserkomponenten technisch noch eng miteinander verbunden. Interne XUL-Dateien konnten geladen werden, Plugins verfügten über weitreichende Rechte, und Benutzeraktionen wie Scrollen oder Drag-and-Drop wurden nicht strikt von sicherheitskritischen Funktionen getrennt. Genau diese Kombination machte es möglich, dass scheinbar harmlose Interaktionen missbraucht werden konnten, um privilegierten Code auszuführen.

Heute ist diese Struktur grundlegend anders aufgebaut. Webseiten laufen in isolierten Prozessen, getrennt von der Browseroberfläche und vom Betriebssystem. Interne Benutzeroberflächen werden in geschützten Komponenten dargestellt, die von normalen Webseiten nicht direkt angesprochen werden können.

Wegfall von Plugins und strengere Ereignisverarbeitung

Hinzu kommt, dass klassische Plugin-Systeme wie Flash praktisch vollständig verschwunden sind. Die Möglichkeit, über Plugins privilegierte Inhalte in versteckte Frames zu laden, existiert in dieser Form nicht mehr.

Auch die Verarbeitung von Mausbewegungen, Scroll-Ereignissen und Drag-and-Drop-Aktionen erfolgt heute deutlich restriktiver. Solche Ereignisse werden nicht mehr ungeprüft an andere Browserkomponenten weitergereicht, sondern innerhalb klar definierter Sicherheitsgrenzen verarbeitet.

Zusätzliche Schutzmechanismen wie Sandbox-Modelle, Site Isolation und eine fein abgestufte Rechteverwaltung sorgen dafür, dass selbst bei logischen Fehlern keine direkten Systemzugriffe mehr möglich sind.