[English]Kurze Warnung an Leute aus der Blog-Leserschaft, die das Tool iVentoy zur Verteilung von Betriebssystem-Images über ein Netzwerk und einen PXE-Server einsetzen. Es gibt aktuell eine Diskussion, dass das Tool (aktuell Version 1.0.2) einen unsicheren Kernel-Driver sowie ein obskures Zertifikat unter Windows installiert. Solange dieser Punkt nicht sauber geklärt ist, kann ich nur raten, die "Finger von diesem Tool zu lassen". Hier einige Informationen, was bisher bekannt ist. Ergänzung: Der Entwickler hat bereits reagiert und Version 1.0.21 herausgebracht.
Anzeige
Was ist iVentoy?
Bei iVentoy (nicht zu verwechseln mit dem Tool Ventoy, welches USB-Boot-Sticks zur Betriebssysteminstallation erstellen kann), handelt es sich um ein Tool, um Betriebssystemabbilder per Netzwerk zu verteilen.
Auf der Webseite des Projekts heißt es, dass iVentoy eine erweiterte Version des PXE-Servers sei, mit der sich Betriebssysteme auf mehreren Rechnern gleichzeitig über das Netzwerk booten und installieren lassen.
iVentoy sei extrem einfach, ohne komplizierte Konfiguration, zu bedienen. Der Administrator legt einfach die ISO-Datei mit dem Installationsabbild in den angegebenen Speicherort und wählt PXE-Boot in der Client-Maschine. Dann wird das Betriebssystemabbild (bzw. Installationsabbild) über das Netzwerk von PXE-Boot auf dem Client geladen und ausgeführt.
Anzeige
iVentoy unterstützt x86 Legacy BIOS, IA32 UEFI, x86_64 UEFI und ARM64 UEFI-Modus zur gleichen Zeit. iVentoy unterstützt laut Webseite mehr als 110 gängige Varianten von Betriebssystemen (Windows/WinPE/Linux/VMware).
Hintergrund-Information: Der Hauptentwickler und Maintainer des Ventoy-Projekts ist Hailong Sun, auch bekannt als longpanda. Longpanda ist andererseits auch der Entwickler von iVentoy.
Diskussion über Sicherheitsprobleme
Benedikt hat mich per E-Mail kontaktiert (danke) und wies mich auf den reddit.com-Beitrag iVentoy tool injects malicious certificate and driver during Win install (vulnerability found today) vom 6. Mai 2025 hin. Der Thread-Starter schreibt, dass er gerade über einen Bericht über eine Sicherheitslücke in iVentoy stoßen sei. Ventoy sei bekannt für sein sehr nützliches Tool zur Erstellung von bootfähigen USB-Geräten.
Sicherheitproblem in iVentoy gefunden
Auf GitHub gibt es den aktuellen Eintrag iVentoy installing unsafe Windows Kernel drivers #106, der sich mit dem Problem beschäftig. Dort heißt es, dass iVentoy 1.0.2 von der GitHub-Seite über folgende Archive
iventoy-1.0.20-linux-free.tar.gz, iventoy-1.0.20-win32-free.zip, iventoy-1.0.20-win64-free.zipunsichere Windows-Kernel-Treiber installiert. Alle diese Archivdateien enthalten den Eintrag \data\iventoy.dat. Die .dat-Datei wird zur Ausführungszeit von der iVentoy-App im RAM in \data\iventoy.dat.xz entschlüsselt. Der Ersteller des GitHub-Eintrags #106 hat ein Python-Script geschrieben, um das entschlüsselte Ergebnis zu analysieren und kam zu keinem positiven Ergebnis.
VirusTotal und Defender schlagen Alarm
Wenn die entschlüsselte iventoy.dat.xz mit 7zip geöffnet werde, fänden sich einige der extrahierten Dateien, die mit positive Ergebnisse bei Virustotal.com und Windows Defender gelistet werden. Die Datei iventoy.dat.xz\iventoy.dat.\win\wintool.tar.xz enthält wohl ein obskures Zertifikat, welches von Virustotal als "schädlich" ausgewiesen wird.
Weiterhin heißt es, dass die Analyse von "iventoy.dat.xz\iventoy.dat.\win\vtoypxe64.exe" zeigt, dass sie ein selbstsigniertes Zertifikat mit dem Namen "EV"-Zertifikat "JemmyLoveJenny EV Root CA0" bei offset=0x0002C840 length=0x70E enthält. Und es heißt, dass iVentoy unsichere Windows-Kernel-Treiber installiert.
Eine Warnung von Talos
Bei diesem Zertifikat läuten alle Alarmglocken, denn 2023 hat Talos-Security den Beitrag Old certificate, new signature: Open-source tools forge signature timestamps on Windows drivers mit einer Warnung gebracht.
Cisco Talos hat beobachtet, dass Bedrohungsakteure eine Windows-Richtlinienlücke ausnutzen, die das Signieren und Laden von nicht signierten Kernel-Modus-Treibern mit einem Signatur-Zeitstempel vor dem 29. Juli 2015 erlaubt. Laut Talos nutzen die Akteure mehrere Open-Source-Tools, die das Signierdatum von Kernel-Mode-Treibern ändern. Ziel ist es, bösartige und ungeprüfte Treiber, die mit abgelaufenen Zertifikaten signiert sind, in Windows zu laden.
Cisco Talos Sicherheitsforscher haben mehr als ein Dutzend Code-Signatur-Zertifikate mit Schlüsseln und Passwörtern in einer PFX-Datei beobachtet, die auf GitHub gehostet wird und in Verbindung mit diesen Open-Source-Tools verwendet wird. Im Beitrag wird auch das obige Zertifikat erwähnt.
Die meisten Treiber, die Talos identifizieren konnte, enthielten einen Sprachcode Simplified Chinese in ihren Metadaten. Das deutet auf chinesische Muttersprachler als Urheber hin. Cisco Talos schrieb 2023, dass man außerdem einen Fall identifiziert habe, in dem eines dieser Open-Source-Tools verwendet wurde, um geknackte Treiber neu zu signieren und so die digitale Rechteverwaltung (DRM) zu umgehen.
Cisco Talos hatte einen zweiten Blog-Beitrag veröffentlicht, der den realen Missbrauch dieser Lücke durch einen undokumentierten bösartigen Treiber namens RedDriver zeigt. Ich hatte im Juli 2023 im Beitrag Windows: Weiterhin Malware in Kernel-Treibern ladbar (RedDriver-Angriff) über das Szenario berichtet.
Finger weg – auch bei Ventoy – bis zur Klärung
An dieser Stelle würde ich für "Finger weg von iVentoy" plädieren, bis der gesamte Sachverhalt geklärt ist. Das triggert natürlich sofort die Frage, ob die nach der Sicherheit von Ventoy, da es vom gleichen Entwickler stammt und auch einige blob-Dateien mit unbekanntem Inhalt enthält.
Aktuell liegen mir nur die beiden verlinkten Threads mit ihren Informationen vor – die ich für weitere Recherchen der Leserschaft mal im Raum stehen kann. Ich kann heute und die kommenden Tage wenig testen bzw. recherchieren, da ich plane, ein paar Tage offline zu sein. Ergänzung: Beachtet den nachfolgenden Kommentar auf iVentoy 1.0.21 – ob da das Problem behoben ist, weiß ich nicht endgültig.
Anzeige
Also das ist alles BS, da umgeht halt ein Certifikatloser Open Source Entwickler Microsofts Tyrannei und schon schreien alle die keine Ahnung haben.
Die allermeisten Antimalware Fools , schreien immer bei suspekten Signaturen los auch wen der damit signierte code 100% einwandfrei ist. Das ist alles mist.
Hier die details vom Entwickler: https://github.com/ventoy/PXE/issues/106#issuecomment-2857344318
Solange MS den Eigentümern der Systeme nicht einen sauberen weg bietet Treiber welchen die Eigentümern der Systeme vertrauen zu laden, finde ich alles gut was MS's Einschränkungen umgeht.
Zur Erhöhung der Sicherheit und Stabilität nur vom Hardwareanbieter freigegebene und signierte Treiber laden zu lassen, ist eine Tyrannei?
Nicht vom Hardwareanbieter sondern von Microsoft selber, und ja, wen es sich gegen den erklärten willen des Besitzers der Hardware richtet.
Wenn der Besitzers der Hardware ein Treiber welchen er laden will nicht laden kann das ist Tyrannei, Enteignung, Computersabotage, you name it.
Es ist ein verbrechen gegen den Besitzer der Hardware.
Es wurde soeben eine neue Version iVentoy 1.0.21 released, in der der angemeckerte Treiber und das Zertifikat entfernt sind.
Zur Einordnung ist hier vielleicht ganz gut zu erwähnen das die Problematik mit dem Root-CA und dem damit signierten Treiber nur in dem Windows PreBootEnvironment auftritt welches dazu genutzt wird die ISO von der man installieren will zu laden und zu starten. Es wird weder ein Zertifikat noch ein Treiber in das zu installierende OS eingebunden. Ist unschön, aber würde ich eher als Schlampigkeit einordnen. Der Entwickler hat ja auch auf Github erklärt das es nicht mehr nötig ist da einfach der Test-Modus von WinPE genutzt wird in dem jegliche unsignierte Treiber funktionieren und er nur vergessen hat die Geschichte mit dem Cert und Treiber rauszulöschen (das Cert funktioniert eh nicht mehr unter neueren Windows Versionen)
Hier das offizielle Statement vom Entwickler
https://github.com/ventoy/PXE/issues/106#issuecomment-2857344318
Hört sich aber auch nur so „halb gut" an…
OK. Let me explain about this.
iVentoy is a tool to install Windows/Linux through PXE. As we know, PXE is based on network, so we need a driver to mount the ISO file in the server side as a local drive (e.g. Y: Z:) though network. So I choose httpdisk.
httpdisk is an open source project https://www.accum.se/~bosse/httpdisk/httpdisk-10.2.zip
httpdisk driver will only be installed in the WinPE step, that means it only exist in the RAM and will not be installed to the final Widows system in the harddisk.
But in windows, by default a driver file must be signed to install.
So I find a signed version of httpdisk driver file in the internet and try to use it. But this signed version has already been rejected by latest Windows,
so finally I use another way, to boot the WinPE in test mode (again, only the WinPE environment).
When WinPE is booted in test mode, a driver file no need to be signed to install.
So finally, actually we don't need the signed version of httpdisk driver file and don't need to load the CA anymore.
Only that the code is not deleted.
So I will release a new version later that remove the signed httpdisk driver file and will not load the CA.
Ich sehe das jetzt als nicht so wild an, zumal in der Erklärung ja auch steht, "er existiert nur im RAM und wird nicht auf das endgültige Windows-System auf der Festplatte installiert." wie Joseph Ernest Erklärt, wenn man überhaupt damit ein Windows System Installieren möchte. Ich benutze es eher für Diverse Bootmedien, Acronis, Clonezilla, Linux als Live Medium u.s.w. zumal das glaube ich auch eher eine Installation auf einen Teil des Datenträgers betrifft, so als Bootoption im Startmenü.
Da mache ich mir eher bei Microsoft und Adobe Gedanken was dort an veralteten Zertifikaten installiert ist oder wird.
"A fool with a tool is still a fool!"
Seit NT4 liefert M$FT den Treiber RAMDISK.SYS auf dem Installationsmedium; dieser stellt ein vom ebenfalls von M$FT gelieferten PXE-Bootlader in's RAM geladene Dateisystemabbild (seit Vista als "boot.wim" auf jedem Installationsmedium vorhanden) auch unter Windows 11 als "wirrtuelle" Festplatte bereit, von der WinPE gestartet wird.
Kein Schwein braucht Schrott wie Ventoy oder den von diesem missbrauchten httpdisk.sys um Windows per PXE zu booten.
EINMAL mit Profis arbeiten…
Ich arbeite seit über 25 Jahren in der IT und habe großen Respekt vor Ihrem Namen.
Ventoy finde ich praktisch, da ich mehrere ISO 's "einfach auf den Stick werfe" und die "Rescue oder andere Umgebung" .. starte.
Ich finde das "elegant" und nicht als Schrott.
ich habe echt Angst vor dem Tag, wo deine Generation mit Wissen in Rente geht, meine übergangsweise verantwortlich ist, bis die Generation komplett in der Verantwortung steht und entscheidet, die jetzt 10-15 Jahre Berufserfahrung hat.
Welches Wissen? Der kennt Ventoy überhaupt nicht, aber Hautpsache polemisch draufdreschen….
Stefan ist dermaßen DeepDive im OS, da haben wir alle vielleicht nur ausversehen Mal hingeschaut und dann auch nicht gewusst und schon gar nicht verstanden, worum es geht.
wenn man existierende Technik verstanden hat, muss man nicht Reverse-Engineered oder gebastelt das Rad neu erfinden, man nimmt das Rad, das schon da ist.
aber dafür müsste man es verstanden haben …
Nochmal, wer den Unterschied zwischen Ventoy und iVentoy nicht kennt, der hat vieles nichts verstanden – du anscheinend ja auch nicht.
Wieso "nochmal"? Darum gehts doch überhaupt nicht …
Erwartest Du etwa, dass Kleinkinder, die nicht 'mal ihren Namen schreiben können, in der Lage sind, sinnentnehmend (also mitdenkend) zu Lesen?
Ja. Du kennst mich, ich glaube an vielen Stellen noch (auch an das Gute), statt es zu wissen ;-)
Außer Beleidigungen hast du hier aber auch so gar nichts zu bieten, oder?
Apropos "Kleinkinder, die nicht Lesen und Mitdenken können": für welche(s) Betrübssystem(e) gips den Treiber HTTPDISK.sys?
Wenn man ein solches Auftreten unter seriöser Aussenwirkung versteht, nun denn. Für die wirkliche Welt kann allerdings auch der Eindruck entstehen, dass hier vermeintliche Experten doch nur im Sandkasten um Förmchen streiten.
Kindergarten und Polemik pur presented by Stefan…
Wir sollten den Thread auslaufen lassen. Danke.
Doch darum geht's. Ihr kennt beide nicht den Unterschied zwischen Ventoy und iVentoy und führt Euch auf, als hättet Ihr die Weisheit mit Löffeln konsumiert.
Wird dann halt ziemlich peinlich ;-)
Hättest Du dazu eine einigermaßen aktuelle Quelle? Ich finde leider nur uralte Anleitungen mit Windows Server 2003 zu dem Thema …
GROSSE AUSNAHME: normalerweise antworte ich Kleinkindern, die nicht 'mal ihren vollen Namen schreiben können, NICHT!
Es ist wurscht, ob Windows PE/RE vom Installationsmedium oder per PXE/TFTP in die RAMDisk geladen und von dieser ausgeführt wird.
Das folgende Batch-Skript erzeugt den BCD dafür:
— *.CMD —
BCDEdit.exe /CreateStore "%TMP%\BCD"
BCDEdit.exe /Store "%TMP%\BCD" /Create {RamDiskOptions}
BCDEdit.exe /Store "%TMP%\BCD" /Set {RamDiskOptions} RamDiskSDIDevice boot
BCDEdit.exe /Store "%TMP%\BCD" /Set {RamDiskOptions} RamDiskSDIPath \boot\boot.sdi
BCDEdit.exe /Store "%TMP%\BCD" /Create {d2b69192-8f14-11da-a31f-ea816ab185e9} /Application OSLoader /D "Windows PE/RE"
BCDEdit.exe /Store "%TMP%\BCD" /Set {d2b69192-8f14-11da-a31f-ea816ab185e9} DetectHAL Yes
BCDEdit.exe /Store "%TMP%\BCD" /Set {d2b69192-8f14-11da-a31f-ea816ab185e9} Device RamDisk=[boot]\Boot\boot.wim,{RamDiskOptions}
BCDEdit.exe /Store "%TMP%\BCD" /Set {d2b69192-8f14-11da-a31f-ea816ab185e9} OSDevice RamDisk=[boot]\Boot\boot.wim,{RamDiskOptions}
BCDEdit.exe /Store "%TMP%\BCD" /Set {d2b69192-8f14-11da-a31f-ea816ab185e9} SystemRoot \Windows
BCDEdit.exe /Store "%TMP%\BCD" /Set {d2b69192-8f14-11da-a31f-ea816ab185e9} WinPE Yes
BCDEdit.exe /Store "%TMP%\BCD" /Create {BootMgr} /D "Windows PE/RE BootManager"
BCDEdit.exe /Store "%TMP%\BCD" /DisplayOrder {d2b69192-8f14-11da-a31f-ea816ab185e9}
BCDEdit.exe /Store "%TMP%\BCD" /Set {BootMgr} TimeOut 999
— EOF —
Das "System Deployment Image" boot.sdi und die boot.wim liefert M$FT auf dem Installationsmedium bzw. mit dem AIK. Letzteres enthält auch pxeboot.n12, das der PXE/TFTP-Server den Clients anbieten muss. Dieses wiederum lädt Boot\bootmgr.exe aus dem Wurzelverzeichnis des TFTP-Servers. bootmgr.exe lädt dann Boot\BCD ebenda und bietet die in {BootMgr} eingetragenen Systeme zur Auswahl an (der mittlere Teil des Batch-Skripts kann mit anderen GUIDs wiederholt werden; diese sind in /DisplayOrdner aufzuzählen).
Es geht doch aber bei iVentoy darum beliebige iso images über pxe booten zu können. Das man Windows PE auch anders über PXE booten kann ist klar.
Hier andere User beleidigen finde ich übrigens deutlich schwieriger als das nicht jeder bereit ist unter vollem Namen zu posten.
Siehe https://technet.microsoft.com/en-us/library/cc771845.aspx sowie https://technet.microsoft.com/en-us/library/cc721977.aspx
Wenn man "ventoy virus" bei Google eingibt, kommen jede Menge Links zum Vorschein. Und keineswegs nur welche aus den letzten Tagen. So war mir noch ein Bericht von LinuxNews im Gedächtnis: "Malware: Warnung vor Ventoy" vom 13.11.2021
Link: https://linuxnews.de/warnung-vor-ventoy/
Ob da was dran ist, vermag ich nicht zu sagen, aber ich persönlich würde eine solche Software nicht verwenden.
wenn Du "windows virus" eingibts, kommen vermutlich deutlich mehr "Links zum Vorschein"…
"Ob da was dran ist, vermag ich nicht zu sagen, aber ich persönlich würde eine solche Software nicht verwenden."
Was hat eine uralte Meldung von 2021 zu einer anderen Software damit zu tun?