Ungefilterte HTML-Injection über die homeserver-kontrollierte Startseiten-URL

Beschreibung

// Replace '," and HTML encoded variants
let body = (await res.text()).replace(
    /_t\((?:['"]|(?:&#(?:34|27);))([\s\S]*?)(?:['"]|(?:&#(?:34|27);))\)/gm,
    (match, g1) => this.translate(g1),
);

if (this.props.replaceMap) {
    Object.keys(this.props.replaceMap).forEach((key) => {
        body = body.split(key).join(this.props.replaceMap![key]);
    });
}

this.setState({ page: body });

const content = <div className={`${className}_body`} dangerouslySetInnerHTML={{ __html: this.state.page }} />;

export function getHomePageUrl(appConfig: IConfigOptions, matrixClient: MatrixClient): string | undefined {
    const config = new SnakedObject(appConfig);

    const pagesConfig = config.get("embedded_pages");
    let pageUrl = pagesConfig ? new SnakedObject(pagesConfig).get("home_url") : null;

    if (!pageUrl) {
        pageUrl = getEmbeddedPagesWellKnown(matrixClient)?.home_url;
    }

    return pageUrl;
}

const EMBEDDED_PAGES_WK_PROPERTY = "io.element.embedded_pages";

export function getEmbeddedPagesWellKnown(matrixClient: MatrixClient | undefined): IEmbeddedPagesWellKnown | undefined {
    return embeddedPagesFromWellKnown(matrixClient?.getClientWellKnown());
}

export function embeddedPagesFromWellKnown(clientWellKnown?: IClientWellKnown): IEmbeddedPagesWellKnown {
    return clientWellKnown?.[EMBEDDED_PAGES_WK_PROPERTY];
}

Auswirkung

• Ein bösartiger Homeserver-Betreiber, oder wer einen Homeserver übernommen hat, kann angreiferkontrolliertes Markup auf der Startseite jedes Element-Web-Clients platzieren, der sich gegen diesen Server authentifiziert. Die Startseite ist die Standardansicht nach Anmeldung und Registrierung und bleibt über den Home-Button erreichbar. Der eingeschleuste Inhalt ist damit dauerhaft präsent und nicht auf einen einzelnen Moment beschränkt.
• Die Ausführung von JavaScript ist blockiert, Nachrichten, Access Token und Schlüsselmaterial bleiben unerreichbar. Was bleibt, ist Credential-Phishing. frame-src * erlaubt ein bildschirmfüllendes Iframe von beliebiger Origin, und ein Formular in diesem Iframe hat einen eigenen Browsing-Context, sodass form-action 'self' der Elternseite nicht bestimmt, wohin es sendet. Ein wie der umgebende Client gestalteter Dialog "Sitzung abgelaufen" nimmt das Passwort entgegen und sendet es an den Angreifer, innerhalb einer Anwendung, der die betroffene Person bereits vertraut. Wir haben das durchgängig gegen Element Web v1.11.96 bestätigt.
• img-src * erlaubt zusätzlich Tracking-Pixel, die melden, wann und wie oft eine bestimmte Person den Client öffnet, und style-src 'unsafe-inline' lässt das eingeschleuste Markup die Oberfläche ringsum umgestalten.

Abhilfe

Aktualisieren Sie Element Web oder Element Desktop auf 1.12.22 oder höher. Der Fix rendert die eingebettete Seite über den gemeinsamen Helper sanitizedHtmlNode, der genau die Tags entfernt, auf denen die Injection beruht. Deployments, die nicht sofort aktualisieren können, sollten embedded_pages.home_url explizit in der config.json setzen; der Resolver zieht den homeserver-kontrollierten well-known-Schlüssel dann gar nicht erst heran. Unabhängig von der Version entfernt eine Einschränkung von frame-src auf 'self' plus die tatsächlich genutzten Widget- und Call-Origins das Phishing-Primitive, und base-uri 'none' schließt eine Lücke in der Verteidigungstiefe, da base-uri nicht auf default-src zurückfällt. Für alle, die einen Client nutzen, den sie nicht selbst administrieren: Die Startseite hat keinen legitimen Grund, nach einem Passwort zu fragen. Behandeln Sie jede dort erscheinende Anmeldeaufforderung als verdächtig, bis der Client aktualisiert ist.

Checkliste für Betreiber

• Auf Element Web oder Element Desktop 1.12.22 oder höher aktualisieren.

  Jede frühere Version rendert die eingebettete Startseite ungefiltert. Der Fix liegt in Pull Request #33842.

• embedded_pages.home_url in der eigenen Konfiguration setzen.

  getHomePageUrl() zieht das well-known des Homeservers nur heran, wenn die Deployment-Konfiguration den Schlüssel offen lässt. Ihn in der config.json zu setzen nimmt den Homeserver in jeder Version aus dem Vertrauenspfad der Startseite. Prüfen Sie die config.json, die Sie tatsächlich ausliefern, nicht das Beispiel.

• Die CSP des Deployments verschärfen.

  frame-src * macht aus der Markup-Injection erst eine Phishing-Oberfläche, weil ein Formular in einem fremden Iframe nicht an form-action 'self' der Elternseite gebunden ist. Schränken Sie die Direktive auf 'self' plus die tatsächlich genutzten Widget- und Call-Origins ein und ergänzen Sie base-uri 'none', das nicht auf default-src zurückfällt.

• Forks und eigene Startseiten prüfen.

  Produkte auf Basis der Element-Web-Codebasis erben sowohl das ungefilterte Rendern als auch den well-known-Fallback. Wenn Sie einen Fork pflegen oder eine eigene Startseite ausliefern, prüfen Sie, ob der Fix übernommen ist und ob Ihr Deployment home_url fest setzt.

Bewertung im Detail

Referenzen

• GHSA-wrcp-5v3v-3j6v (Element)
• CVE-2026-55850 (NVD)
• Element Web v1.12.22 Release
• Element-Web-Pull-Request #33842 (Fix)
• matrix-react-sdk-Pull-Request #7790 (Ursprung des well-known-Fallbacks)
• Element-Web-Repository
• CVE-2024-42347 (NVD, Präzedenzfall für S:C)
• CVE-2023-30609 (NVD, Präzedenzfall für S:C)
• Verwandt: Absturz von Element X Android durch einen manipulierten OIDC-Redirect-Intent

So können wir helfen

• Security Architecture Review
• MDR-Penetrationstests