Rust soll die „Versuchsphase“-Einstufung bei Linux ablegen und damit eine vollwertige Sprache zur Programmierung des Kernel werden. Das haben zentrale Linux-Entwickler inklusive Linus Torvalds gestern auf dem jährlichen Kernel Maintainers Summit beschlossen, wie über eine sehr knappe Meldung bei LWN.net bekannt wurde.

Rust-Support hat noch viel zu tun

Rust steigt damit praktisch neben Assembler und C zur drittwichtigsten Sprache bei der Entwicklung des Linux genannten Kernels auf. Das Ganze heißt aber keineswegs, dass Programmierer jetzt sofort beliebige Kernel-Treiber in Rust schreiben können: Vielen Subsystemen fehlt dazu noch Überbückungscode (Bindings). Der ist an vielen Stellen erforderlich, beispielsweise, damit ein in Rust geschriebener WLAN-Treiber die in C geschriebene Basis-Infrastruktur für WLAN-Treiber und PCIe-Geräte nutzen kann.

Ein paar Subsysteme haben solche Bindings aber schon, oder die Entwickler arbeiten bereits daran. Darunter jenes für Kernel-Grafiktreiber, wo mit Nova gerade ein in Rust geschriebener Treiber für moderne Nvidia-Grafikkerne entsteht, der mittelfristig vermutlich auf vielen PCs zum Einsatz kommen dürfte.

Dreijähriges Experiment erfolgreich abgeschlossen

Erste Teile des Rust-Support waren nach langen Vorarbeiten vor drei Jahren bei Linux 6.1 dazugestoßen. Die Entwickler erhoffen sich vom Rust-Support unter anderem, die Anzahl der Sicherheitslücken zu reduzieren – Rust-Features wie der Schutz vor Speicherzugriffsfehlern, Pufferüberläufen oder Problemen bei nebenläufigen Prozessen sei Dank. Ferner soll die moderne Sprache aber auch die Entwicklung erleichtern und Linux zugänglicher für jüngere Programmierer machen.

(dmk)

In der Netzwerk-Softwareverwaltungs-Lösung Endpoint Manager von Ivanti klaffen mehrere Sicherheitslücken. Eine davon gilt dem Hersteller sogar als kritisches Risiko. Updates schließen die Lecks.

In einer Sicherheitsmitteilung schreibt Ivanti, dass sich die Sicherheitslücken sowohl im Endpoint Manager Core als auch in den Remote-Konsolen finden. Von den vier Schwachstellen ist die gravierendste eine vom Typ „Stored Cross-Site-Scripting“ (Stored XSS), bei dem nicht authentifizierte Angreifer aus dem Netz auf verwundbaren Servern Javascript-Code einschleusen und speichern können, der im Kontext etwa einer Administrator-Sitzung zur Ausführung gelangt (CVE-2025-10573, CVSS 9.6, Risiko „kritisch“). Wie Attacken im Speziellen aussehen würden, erklärt Ivanti nicht. Der Hersteller erklärt jedoch, dass Ivanti EPM nicht dazu gedacht ist, aus dem Internet erreichbar zu sein; sofern Kunden das System nicht im öffentlichen Internet betreiben, sei das Risiko dieser Schwachstelle signifikant geringer.

Nicht angemeldete bösartige Akteure aus dem Netz können zudem beliebige Dateien auf Server schreiben und dadurch möglicherweise Schadcode einschleusen und ausführen. Das geht auf unzureichende Prüfungen von „dynamisch verwalteten Code-Ressourcen“ zurück (CVE-2025-13659, CVSS 8.8, Risiko „hoch“). Die Einstufung als kritische Bedrohung verpasst das Problem nur knapp. Ivanti erläutert, dass als Voraussetzung für einen Missbrauch Kunden zu einem nicht vertrauenswürdigen Core-Server verbinden müssten; gemäß der „Best-Practices“-Empfehlungen sollten Kunden ihr Ivanti EPM jedoch ausschließlich an vertrauenswürdige Server anbinden.

Weitere Sicherheitslücken

In der Patch-Management-Komponente führt eine unzureichende Prüfung kryptografischer Signaturen dazu, dass nicht angemeldete Angreifer aus dem Netz beliebigen Code ausführen können (CVE-2025-13662, CVSS 7.8, Risiko „hoch“). Außerdem können angemeldete Nutzer aufgrund einer Path-Traversal-Lücke beliebige Dateien außerhalb vorgesehener Verzeichnisse speichern (CVE-2025-13661, CVSS 7.1, Risiko „hoch“).

Wie Angriffe auf die Schwachstellen konkret aussehen können, führt Ivanti nicht aus, betont jedoch, dass für einen erfolgreichen Missbrauch bei allen Nutzerinteraktionen nötig sind. Bislang hat der Hersteller auch keine Kenntnisse darüber, dass die Schwachstellen bereits in freier Wildbahn missbraucht wurden. Daher könne Ivanti auch keine Indicators of Compromise (IOCs) nennen.

Die Aktualisierung auf Ivanti Endpoint Manager 2024 SU4 SR1 schließt alle genannten Sicherheitslecks. IT-Verantwortliche sollten es daher zügig installieren.

Auch im November dieses Jahres hatte Ivanti eine Sicherheitslücke im Endpoint Manager schließen müssen. Sie galt ebenfalls als hochriskant und ermöglichte Angreifern, Dateien auf Festplatten von Opfer-PCs zu schreiben.

(dmk)

Angreifer können verschiedene Fortinet-Produkte attackieren und sich unter anderem unbefugt Zugriff verschaffen. Sicherheitsupdates stehen zum Download bereit. Bislang sind keine Berichte zu laufenden Attacken bekannt. Admins sollten mit dem Patchen aber nicht zu lange warten.

Anmeldung kaputt

Als besonders gefährlich gelten zwei „kritische“ Lücken (CVE-2025-59718, CVE-2025-59719) in FortiOS, FortiProxy, FortiSwitchManager und FortiWeb. Unter bestimmten Bedingungen können Angreifer die Authentifizierung umgehen. In einer Warnmeldung führen die Entwickler aus, dass die Schwachstellen konkret den SSO-Login von FortiCloud betrifft. Dieses Feature ist standardmäßig nicht aktiv.

Die Entwickler weisen aber darauf hin, dass wenn Admins Geräte über die Bedienoberfläche des jeweiligen Gerätes bei FortiCare registrieren und dabei die Option „Allow administrative login using FortiCloud SSO“ nicht deaktivieren, FortiCloud SSO-Login aktiv ist. Ist das gegeben, können Angreifer mit präparierten SAML-Nachrichten an der Lücke ansetzen und sich so ohne korrekte Anmeldung Zugriff verschaffen.

Temporär können Admins Geräte durch die Deaktivierung dieses Anmeldeverfahrens schützen. Dauerhafte Abhilfe schafft aber nur die Installation von verfügbaren Sicherheitspatches. Deren Auflistung sprengt den Rahmen dieser Meldung. Informationen dazu finden Admins in der Warnmeldung.

Noch mehr Gefahren

Weiterhin sind noch unter anderem FortiAuthenticator, FortiExtender und FortiPortal verwundbar. Der Großteil der verbleibenden Sicherheitslücken ist mit dem Bedrohungsgrad „mittel“ eingestuft. Sind Attacken erfolgreich, können Angreifer etwa eigene Befehle ausführen oder auf eigentlich abgeschottete private Schlüssel zugreifen.

Im Sicherheitsbereich der Fortinet-Website finden sich weitere Details zu den Sicherheitsproblemen. Am vergangenen Patchday haben die Entwickler unter anderem bereits ausgenutzte Lücken in FortiWeb geschlossen.

(des)