Nvidias KI- und Netzwerktechnik BlueField, ConnectX, Cumulus Linux, DGX, DOCA, HGX und Mellanox DPDK sind verwundbar. Nach erfolgreichen Attacken können sich Angreifer in den meisten Fällen höhere Nutzerrechte erschleichen. Bislang gibt es noch keine Berichte zu laufenden Attacken. Sicherheitspatches sind verfügbar.

Die Gefahren

Wie aus einer Warnmeldung hervorgeht, gilt eine Lücke (CVE-2025-23256, Risiko „hoch„) in BlueField am gefährlichsten. Hier können Angreifer unter anderem Daten manipulieren. Dafür müssen sie aber lokalen Zugriff auf das Managementinterface haben. Ist das gegeben, können sie an einer kaputten Authentifizierung ansetzen und sich so unbefugt Zugriff verschaffen, um die Konfiguration des Systems zu manipulieren. Wie solche Angriffe konkret ablaufen könnten, ist bislang unklar.

Über die Schwachstellen in DOCA (CVE-2025-23257 „hoch„, CVE-2025-23258 „hoch„) können sich Angreifer höhere Nutzerrechte verschaffen. Damit das klappt, müssen sie aber bereits über niedrige Rechte verfügen. Auf Mellanox DPDK, ConnectX und Cumulus Linux sind unter anderem DoS-Attacken möglich. Klappt ein solcher Angriff, stürzen Dienste oder Services ab. Außerdem können Angreifer auf eigentlich abgeschottete Daten zugreifen. Im Kontext von DGX und HGX sind ebenfalls für DoS-Angriffe anfällig.

Updates installieren

Die Nennung aller Sicherheitspatches sprengt den Rahmen dieser Meldung. Nvidia hat sie in ihren Warnmeldungen aufgelistet. Um mögliche Attacken vorzubeugen, sollten Admins sicherstellen, dass ihre Systeme auf dem aktuellen Stand sind.

Erst kürzlich haben die Entwickler von Nvidia mehrere Sicherheitslücken in KI-Software wie Apex und Megatron LM geschlossen.

(des)

Eine Zertifizierungsstelle (CA) aus Kroatien hat mehrere Zertifikate für die IP-Adresse 1.1.1.1 ausgestellt, ohne die notwendige Genehmigung dafür eingeholt zu haben. Die Adresse gehört zu Cloudflares frei nutzbarem DNS-Server, der auch Anfragen per verschlüsselter HTTP-Verbindung entgegennimmt. Publik wurde der Lapsus eher zufällig, die CA leistete sich jedoch noch mehr Schnitzer.

Digitale Zertifikate sind essenziell für die sichere Kommunikation im Web, daher ist ihre Vergabe an strenge Richtlinien gebunden. Die kroatische CA Fina hielt sich an diese Richtlinien offenbar nicht immer – und das, obwohl sie zumindest in Microsoft-Browsern und der EU-Infrastruktur für qualifizierte Webseiten-Zertifikate (QWAC) als vertrauenswürdig gilt.

Ein Nutzer des Forums Hacker News fand ein von Fina ausgestelltes Zertifikat, das ihm seltsam vorkam und mit dem er eine weitreichende Untersuchung in Gang setzte. Es war für die IP-Adresse 1.1.1.1 ausgestellt, die das US-Unternehmen Cloudflare seit 2018 für einen freien DNS- und VPN-Dienst verwendet. Dieser unterstützt auch DNS over HTTPS (DoH) und braucht dafür ein gültiges Zertifikat. Das stammt jedoch nicht von Fina, sondern von DigiCert – die kroatische CA hatte die IP-Adresse offenbar nur für Testzwecke verwendet.

Unerlaubte Test-Zertifikate für Cloudflare-IP

Das hätte sie aber nicht gedurft. Denn: Um ein digitales Zertifikat zu erhalten, muss der Antragsteller seine Berechtigung am Subjekt des Zertifikats – üblicherweise eines vollqualifizierten Domainnamens (FQDN) oder einer IP-Adresse – nachweisen. Das gilt auch, wenn die CA selber ein Zertifikat ausstellt, etwa zu Testzwecken. Und so landete der Vorgang rasch auf der zuständigen Mailingliste des Browserherstellers Mozilla und rief die Experten auf den Plan.

Die stellten fest, dass es beileibe nicht beim Einzelfall geblieben war – neben einem halben Dutzend Zertifikaten für 1.1.1.1 hatte Fina auch eines für die von Oracle verwaltete IP-Adresse 2.2.2.2 ausgestellt, einige für private IP-Adressen aus dem Netz 10.0.0.0/8 – und bisweilen hatten die Kroaten erstaunliche Kreativität beim Umgang mit Hostnamen bewiesen. Und das nicht seit gestern: Die Historie der 1.1.1.1-Testzertifikate beginnt im Februar 2024, mithin vor anderthalb Jahren.

Cloudflare zürnt, CA wiegelt ab

Der US-Konzern ist wenig amüsiert und findet in einem ausführlichen Blogeintrag deutliche Worte für den Fauxpas: Es handele sich um einen „inakzeptablen Sicherheitsverstoß der Fina CA“. Wer ihr weiter vertraue, solle unmittelbar handeln, um diese Entscheidung zu überprüfen – offenbar ein Wink mit dem digitalen Zaunpfahl gen Redmond. Zudem führte Cloudflare eine Untersuchung durch, die weitere Sicherheitsverstöße ans Licht bringen sollte, etwa durch „Man in the Middle“-Angriffe oder BGP-Hijacks der IP-Adresse 1.1.1.1.

Cloudflare lobte zudem das Programm der „Certificate Transparency“, das seit Jahren CAs verpflichtet, jedes ausgestellte Zertifikat in ein „Ewiges Logfile“ zu schreiben, das über Dienste wie Censys oder crt.sh einsehbar ist. Doch auch deutliche Selbstkritik erspart der Internetkonzern sich nicht: Man habe das fälschlich ausgestellte Zertifikat zu spät bemerkt und werde nun zusätzliche Maßnahmen ergreifen, um künftig schneller von derlei Problemen zu erfahren.

Die betroffene CA hatte sich zunächst gegenüber Cloudflare gerechtfertigt, tat dies später aber auch öffentlich im Mozilla-Bugtracker. Man habe die IP-Adresse versehentlich zu Testzertifikaten hinzugefügt, die jedoch nie außerhalb der Fina-eigenen Testumgebung in Gebrauch gewesen seien. Alle Zertifikate seien mittlerweile zurückgezogen („revoked“) und werde interne Prozeduren und Dokumentation verbessern.

Auswirkungen: für Nutzer gering, Verursacher muss zittern

Ob dieses Versprechen den gestrengen Hütern der Web-PKI genügt, darf man getrost bezweifeln. Die im CA/Browser Forum (CAB) organisierten Hersteller von Webbrowsern und Vergabestellen digitaler Vertrauensnachweise nehmen Verstöße wie diesen nie auf die leichte Schulter. Microsoft bekommt dies derzeit zu spüren und muss wegen eines Tippfehlers bis November Millionen Zertifikate zurückziehen, anderen CAs entzogen CAB-Mitglieder kurzerhand das Vertrauen komplett.

Für die kroatische CA steht immerhin die Verankerung in Microsofts und Adobes Produkten auf dem Spiel und auch die Betreiber der EU-Infrastruktur für qualifizierte Webzertifikate (QWAC) dürften sich den Vorgang sehr genau anschauen. Nutzer des DNS-Dienstes 1.1.1.1 hingegen dürfen aufatmen: Dass ihnen Gefahr drohte, etwa durch abgefangene DNS-Abfragen, ist höchst unwahrscheinlich.

(cku)

Google hat Best Practices für Entwicklerinnen und Entwickler vorgestellt, die die User ihrer Apps zu Passkeys migrieren möchten. Passkeys werden zunehmend beliebter, da sie sicherer sind als Passwörter – zum Beispiel vor Phishing-Angriffen schützen – und dabei eine hohe Benutzerfreundlichkeit aufweisen. Bei der Anwendung von Passkeys kann der Sign-in zu Apps und Websites mittels biometrischem Sensor – etwa per Fingerabdruck oder Gesichtserkennung –, PIN oder Muster erfolgen.

Für Android-Developer steht die Jetpack-API Credential Manager bereit, um Usern die Passkey-Anwendung zu ermöglichen, während sie gleichzeitig traditionelle Sign-in-Methoden wie Passwörter unterstützt.

Um die Nutzerinnen und Nutzer ihrer Anwendungen zum Passkey-Einsatz zu ermutigen, präsentiert Google auf dem Android Developers Blog Gelegenheiten für Developer in unterschiedlichen UX-Flows. So kann bereits bei der Account-Erstellung ein Prompt zur Erstellung eines Passkeys nützlich sein, oder beim Sign-in per OTP, Passwort oder anderen Sign-in-Methoden. Weitere gute Gelegenheiten bieten sich bei der Account-Wiederherstellung sowie beim Zurücksetzen eines Passworts – gerade in letzterem Fall seien User empfänglicher für die Einfachheit und Sicherheit von Passkeys.

Best Practices: User von Passkeys überzeugen

Google empfiehlt Android-Entwicklern, ihren App-Usern die Passkey-Verwendung mittels einiger Best Practices schmackhaft zu machen. Zum Beispiel sei es wichtig, den Anwendern auf einfache Weise die folgenden Vorteile zu nennen: Sie erhalten eine verbesserte Sicherheit wie den Schutz vor Phishing, müssen kein Passwort mehr eingeben, können den gleichen Passkey über verschiedene Plattformen hinweg verwenden und erhalten eine konsistente Authentifizierungserfahrung.

Das kann beispielsweise so aussehen:

Eine weitere Empfehlung von Google ist das Bieten einer nahtlosen Nutzererfahrung mithilfe des vereinheitlichten User Interface (UI) durch den Credential Manager. Auch sollen User innerhalb der App Klarheit über ihre Authentifizierungsoptionen erhalten und weiterführende Erklärungen zu Passkeys erhalten, etwa durch entsprechende Links. Zudem ist laut Google vor der breiteren Anwendung von Passkeys zunächst ein phasenweiser Rollout an eine kleinere Gruppe von Usern sinnvoll, um Feedback einzuholen und die Nutzererfahrung zu verbessern.

In den UX Guidelines finden Entwicklerinnen und Entwickler weitere, detaillierte Hilfestellungen.

(mai)