VicOne findet 28 Zero-Day-Probleme in weniger als zwei Tagen in Physical-AI-Tooling

VicOne hat durch KI-gestützte Forschung in weniger als zwei Tagen einen ersten Satz von 28 Zero-Day-Befunden in Software und Tools identifiziert, die das Physical-AI-Ökosystem unterstützen. Zu den Befunden gehören nach Angaben des Unternehmens unter anderem Projekte, die von Google, NVIDIA und Meta entwickelt oder gepflegt werden.

Basierend auf der ersten Validierung stufte VicOne alle 28 Befunde als Zero-Day-Schwachstellen ein. Das Unternehmen gab zu bedenken, dass sich die Zahl nach Prüfung durch Hersteller und Schwachstellenbehörden ändern könne und dass einige Befunde noch keine CVE-Tracking-Nummern hätten. Ein Zero-Day ist eine zuvor unbekannte Schwachstelle ohne verfügbaren Fix; VicOne erklärte, schnellere Entdeckung bedeute nicht zwangsläufig, dass ein Angriff stattgefunden habe, aber Teams müssten dennoch feststellen, ob sie die betroffene Software nutzen und worauf ein Angreifer zugreifen oder was er ändern könnte.

Viele der betroffenen Tools werden verwendet, um Roboter zu trainieren, zu simulieren, zu testen und zu betreiben. VicOne erklärte, Schwächen darin könnten die Modelle beeinflussen, die Teams erstellen, die Testergebnisse, denen sie vertrauen, und die Anweisungen, die an Roboter gesendet werden. Daraus ergeben sich zwei Anforderungen für Robotikteams: zu reagieren, während KI hilft, Schwächen schneller aufzudecken, und zu bewerten, wie sich jeder Befund auf Robotersicherheit und Betrieb auswirken könnte.

VicOne erklärte, KI könne Teile der Schwachstellenentdeckung beschleunigen, darunter die Prüfung von Code, die Nachverfolgung von Systemkommunikation und das Testen, ob eine vermutete Schwäche ausgenutzt werden kann. Angreifer könnten ähnliche Fähigkeiten nutzen. Wenn eine Schwäche ein Zero-Day ist, kann schnellere Entdeckung Teams wenig Zeit zur Reaktion lassen.

Die Befunde erstrecken sich über drei Phasen des Robotiklebenszyklus: Entwicklung und Training, Simulation und Validierung sowie Bereitstellung und Laufzeit. VicOne beschrieb mögliche Szenarien für jede Phase und merkte an, dass es sich um potenzielle Folgen und nicht um nachgewiesene Ergebnisse für jeden Befund handelt. Die tatsächlichen Auswirkungen hängen vom Zugriff des Angreifers, vom Design des Systems und davon ab, ob andere Schutzmaßnahmen verhindern, dass Änderungen physisches Verhalten erreichen.

In Entwicklung und Training könnte ein Team ein vortrainiertes Modell herunterladen, um es für seinen Roboter anzupassen. Das Laden einer bösartigen Datei könnte einem Angreifer Zugriff auf das Trainingssystem verschaffen und Änderungen an Trainingsdaten oder am Modell selbst ermöglichen. Ein manipuliertes Modell könnte sich während routinemäßiger Tests normal verhalten, aber nach der Bereitstellung auf ein bestimmtes Objekt, eine Szene oder einen Befehl falsch reagieren. Das Risiko kann über ein Tool eindringen, dem das Team vertraut, bevor jemand den Roboter direkt angreift.

In Simulation und Validierung könnte der Import einer kompromittierten Szene oder eines Robotermodells einem Angreifer Zugriff auf die Simulationsumgebung verschaffen. Mit ausreichender Kontrolle könnte der Angreifer simulierte Sensorwerte, physikalische Bedingungen oder Testergebnisse ändern. Ein Roboter könnte dann Tests zu bestehen scheinen, die unsicheres Verhalten hätten aufdecken müssen, sodass ein Team ihn auf irreführender Grundlage für den Realwelt-Einsatz freigibt.

In Bereitstellung und Laufzeit könnte ein Angreifer Schwächen ausnutzen, um Dateien zu ändern, die die Bewegungsplanung beeinflussen, oder bösartige Kartendaten senden, die die Überwachungsanzeige eines Bedieners zum Absturz bringen. Die Kompromittierung eines Fernbedienungscomputers könnte auch die an einen Roboter gesendeten Anweisungen gefährden. Je nach System und seinen Schutzmaßnahmen könnten diese Schwächen nach Angaben von VicOne die Roboterbewegung verändern oder Bediener daran hindern, zu sehen, was geschieht, und rechtzeitig zu reagieren.

VicOne beschrieb außerdem eine separate Demonstration, in der seine Forscher eine Schwachstelle ausnutzten, um zu verhindern, dass der Fernstopp-Befehl eines Roboters funktioniert. Der Fall zeigt nach Angaben des Unternehmens, warum Teams testen müssen, ob Schutzmaßnahmen wirksam bleiben, wenn die sie unterstützende Software kompromittiert ist.

Das Unternehmen erklärte, ein veröffentlichter Patch müsse noch als sicher bewiesen werden. Selbst nachdem ein Software-Maintainer einen Patch veröffentlicht hat, müssen Robotikteams betroffene Systeme identifizieren, die Kompatibilität prüfen und verifizieren, dass das Update das beabsichtigte Verhalten beibehält. Ein früherer erfolgreicher Test bleibt nützlicher Beleg, aber eine neu entdeckte Schwäche kann Bedingungen offenlegen, die der Test nie untersucht hat.

VicOne schlug drei Fragen für Teams vor, die auf die Befunde reagieren: Wo verwenden wir die betroffene Software, einschließlich Trainingscomputern, Simulationsumgebungen und eingesetzten Robotern? Was könnte die Schwäche ändern, sei es Modelle, Testergebnisse, Sichtbarkeit für Bediener oder Roboterverhalten? Wie verifizieren wir den Schutz, indem wir bestätigen, dass der Fix die Schwäche adressiert und dass das aktualisierte System weiterhin wie beabsichtigt funktioniert? Wenn eine sofortige Aktualisierung nicht praktikabel ist, benötigen Teams möglicherweise vorübergehende Schutzmaßnahmen, etwa die Einschränkung des Zugriffs auf einen betroffenen Dienst, während ein validierter Fix vorbereitet wird.

Während Details zu den 28 Befunden durch koordinierte Offenlegung verfügbar werden, sei der nächste Schritt für Robotikhersteller nach Angaben von VicOne, jeden Befund mit seiner potenziellen Auswirkung auf Entwicklung, Bereitstellung und Roboterverhalten zu verknüpfen. Diese Arbeit erfordere auch zu verstehen, wie Bedrohungen das Roboterverhalten beeinflussen könnten und wie bereits im Betrieb befindliche Systeme geschützt werden können. VicOne erklärte, sein Angebot Radeis helfe Teams, potenzielle Zero-Day-Schwachstellen zu identifizieren, die Sicherheit von KI-Modellen und Systemen zu bewerten und Simulationen zu nutzen, um zu evaluieren, wie sich Risiken vor der Bereitstellung auf Roboterverhalten auswirken könnten, während sein Angebot Rthena die Bedrohungserkennung und -reaktion innerhalb genehmigter Richtlinien während des Betriebs unterstütze.

VicOne erklärte, schnellere Schwachstellenentdeckung sei wichtig, wenn Teams Befunde in Maßnahmen umsetzen können: identifizieren, was Aufmerksamkeit erfordert, verifizieren, dass Schutzmaßnahmen weiterhin gelten, und bestätigen, dass ein Fix keine neuen Risiken einführt.

Quellen: The Robot Report.