Mehrere Sicherheitslücken in der Angular Language Service-Erweiterung ermöglichen Remote-Code-Execution-Angriffe

Sicherheitslücken in Angular-Erweiterungen Ein zentraler Angriffsvektor betrifft die JSDoc-basierte Command-Injection beim Hover. Die Erweiterung konfiguriert ihren Markdown-Rendering-Engine mit der Einstellung „isTrusted: true", was die Ausführung eingebetteter Command-URIs innerhalb des gerenderten Inhalts ermöglicht.

Der Angular-Sprachserver sanitisiert jedoch JSDoc-Kommentaren nicht ordnungsgemäß, bevor er sie an den Renderer übergeben. Daher kann ein Angreifer einen bösartigen JSDoc-Kommentar erstellen, der einen Befehlslink innerhalb einer TypeScript- oder JavaScript-Datei enthält.

Wenn ein Entwickler über das betroffene Symbol fährt und auf den Link klickt, wird der eingebettete Befehl direkt auf dem Host-Rechner ausgeführt. Ein zweites kritisches Problem betrifft die unsichere Handlung der Konfiguration des TypeScript-SDK (tsdk).

Einordnung fuer Autofahrer

Die Erweiterung liest tsdk-bezogene Einstellungen direkt aus der.vscode/settings.json-Datei des Arbeitsbereichs aus, ohne den Arbeitsbereichsvertrauen zu überprüfen oder die Zustimmung des Benutzers einzufordern.

Anschließend wird dieser Pfad an den Hintergrund-Sprachserver weitergegeben, der die Datei tsserverlibrary.js dynamisch mittels Node.js require() lädt. Ein Angreifer kann dieses Verhalten ausnutzen, indem er eine bösartige tsserverlibrary.js-Datei in einem Projektverzeichnis platziert und diese über die Arbeitsbereichskonfiguration referenziert.

Wenn der Entwickler das Projekt öffnet, führt die Erweiterung den bösartigen Code während der Initialisierung stumm aus, ohne dass eine Benutzerinteraktion erforderlich ist. Diese Schwachstellen umgehen effektiv das Workspace-Trust-Modell, das entwickelt wurde, um die Ausführung ürdigen Code zu verhindern.

Sicherheitslage und Risiko

Der auf tsdk basierende Angriff läuft automatisch ab, sobald ein Projekt geöffnet wird. Im Gegensatz dazu erfordert der auf JSDoc basierende Angriff nur minimale Benutzerinteraktion, wodurch beide Angriffswege für reale Ausbeutungsszenarien hochpraktisch sind.

Erfolgreiche Angriffe können zu einer vollständigen Kompromittierung des Systems führen, einschließlich unbefugter Befehlsausführung, Datenzugriffs und Persistenz.

Beispielsweise könnte ein Entwickler, der ein scheinbar legitimes Repository kloniert, den Exploit unbewusst auslösen, indem er das Projekt einfach in VS Code öffnet; dadurch erhält der Angreifer sofortige Kontrolle über eine bösartige Konfigurationsdatei.

Sicherheitslage und Risiko

Die unter dem GitHub Advisory GHSA-ccq4-xmxr-8hcq offengelegten Probleme betreffen alle Versionen vor 21.2.4 und wurden in der neuesten gepatchten Version behoben. Die Schwachstellen werden unter CVSS v4 als hochkritig eingestuft, weisen eine geringe Angriffscomplexität auf und erfordern keine Berechtigungen.

Sie sind mit mehreren Schwachstellen verbunden, darunter Cross-Site-Scripting, Code-Injection, unkontrollierte Suchpfad-Elemente und die Ausführung nicht verifizierter Code. Entwickler werden dringend aufgefordert, unverzüglich auf Version 21.2.4 oder eine neuere Version zu aktualisieren.

Darüber hinaus ist es entscheidend, nicht vertrauenswürdige Repositories nicht zu öffnen, Arbeitsbereichskonfigurationsdateien sorgfältig zu überprüfen und sichere Entwicklungspraktiken bei der Arbeit mit Drittanbieter-Code einzuhalten. Abi ist Security Editor und Reporterin bei