Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

FeedsKontaktDatenschutz© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
vbox-hgcm-ssm-cparms — VirtualBox 7.2.20 – Hoch – Lokal – Heap-Überlauf – HGCM SSM cParms wrap | Kitploit
Tools/GitHubGitHub/abraxas/vbox-hgcm-ssm-cparms
SpeicherforensikSchwachstellenanalyseExploitationSicherheitsvirtualisierungPapers & ForschungBinary-ExploitationLabs & Praxis
GitHubabraxas/vbox-hgcm-ssm-cparms

vbox-hgcm-ssm-cparms

VirtualBox 7.2.20 – Hoch – Lokal – Heap-Überlauf – HGCM SSM cParms wrap

Repository anzeigen
3vor 3 TagenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

Abraxas Labs - vbox-hgcm-ssm-cparms

abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  vbox-hgcm-ssm-cparms

vbox-hgcm-ssm-cparms

Klasse: Heap-Overflow Reichweite: Lokal (Host)

Oracle VM VirtualBox OSS 7.2.20 (f2792cf44) - Oracle

Live-HGCM verweigert weiterhin cParms > 32. Das Laden eines gespeicherten Zustands nicht. vmmdevR3HgcmLoadState liest cParms aus der .sav ohne VMMDEV_MAX_HGCM_PARMS-Begrenzung und dimensioniert dann den Befehl mit uint32_t cbCmd. Bei cParms = 0x4000000 läuft dieses Produkt auf sizeof(VBOXHGCMCMD) (~120) über. Der erste enmType-Store ist bereits ein 4-Byte-Schreibzugriff über den Block hinaus.

Ein Host-Benutzer, der einen feindlichen gespeicherten Zustand wiederherstellt, verursacht einen Heap-Overflow im VM-Prozess. Ein Gast kann dies nicht über Save einschleusen.

IDnoch keine CVE
KlasseHeap-Overflow (OOB-Schreibzugriff im VM-Prozess; keine Host-Kernel-Escape)
ReichweiteLokal (Host) (UI:R Wiederherstellung gespeicherter Zustände / Snapshots)
CWECWE-190, CWE-787
CVSSHoch: 7.8 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
ProduktVirtualBox OSS
Betroffen7.2.20 (f2792cf44f663989818507e36d3db5f978523c5e)
AuthHost-Benutzer stellt eine gespeicherte VM, einen Snapshot oder eine .sav wieder her
LizenzGNU Affero GPL v3.0
Labornur 127.0.0.1. Source-Harness. Kein VirtualBox-Boot, kein .sav-Parsen.

Was ein Angreifer tun kann

Dem Bediener einen VM-Ordner übergeben, dessen gespeicherter Zustand einen ausstehenden VMMDev-HGCM-CALL enthält. Dieser klickt auf Start bei einer gespeicherten VM, stellt einen Snapshot wieder her oder übernimmt die .sav. Die Konsolen-Wiederherstellung durchläuft SSMR3 in vmmdevR3LoadExec und dann in vmmdevR3HgcmLoadState. Das ist UI:R. Der Überrest ist der Parser, kein Gast-Hypercall.

VMMDev ist standardmäßig aktiviert. Kein 3D. Keine Guest Additions. Kein VRDP. Kein PUEL.

Methode und Sink

SchrittWoWas es ermöglicht
WiederherstellenHost-UI / VBoxManage startvm bei einer gespeicherten VMDer Host-Benutzer öffnet die feindliche .sav. Das ist der einzige erforderliche Klick.
SSM-EinheitVMMDev vmmdevR3HgcmLoadState (VMMDevHGCM.cpp:2043-2091)SSMGetU32 in cParms ohne VMMDEV_MAX_HGCM_PARMS-Begrenzung (32).
Alloc-WrapvmmdevR3HgcmCmdAlloc (VMMDevHGCM.cpp:376-381)uint32_t cbCmd = sizeof(VBOXHGCMCMD) + cParms * (40+24). cParms = 0x4000000 läuft auf ~120 über. RTMemAllocZ dieser Größe gelingt gegen das Heap-Budget.
Erster StoreLadeschleife paGuestParms[i].enmType (VMMDevHGCM.cpp:2085-2091)paGuestParms ist pCmd + sizeof(VBOXHGCMCMD), was nach dem Wrap bereits das Alloc-Ende ist. Das erste Typ-Dword ist ein 4-Byte-OOB-Schreibzugriff. Der Stream benötigt nur den CALL-Header plus einen Parametertyp. Er benötigt keine 67 Millionen Datensätze.

Berechtigungen

ArtHerkunftWas der Angreifer erhält
ReconkeineDie Overflow-Bytes werden vom sav bestimmt. Dies ist kein Leak. Heap-Inhalte werden nicht an die Datei zurückgegeben.
Integritätlab-provencParms=0x4000000 lässt uint32_t cbCmd auf 120 überlaufen. Ein i=0 enmType-Store zerstört einen 0xA5-Canary. canary0=56424f58 ist das VBOX-Präfix von VBOX-HGCM-SSM-CPARMS-WITNESS. Die Kontrolle cParms=2 lässt den Canary intakt.
IntegritätabgeleitetWeitere vom sav kontrollierte Parm-Records (Typ-Dword plus 32/64-Bit- oder Pointer-Desc-Felder) schreiben linear ausgehend vom ~120-Byte-RTMemAllocZ in VirtualBoxVM / VBoxHeadless. Das ist ein Write-Primitive im VM-Prozess, dieselbe Klasse wie QEMU-Migration-memcorr. Dieses Paket demonstriert keine Kontrolle über den Instruction-Pointer.
VerfügbarkeitabgeleitetVBoxVM-Absturz, wenn der Smash nicht in einen kontrollierten Write umgewandelt wird. Der Harness ist ein Canary-Smash, kein VirtualBox-Prozessabsturz.

Was dieser Überrest nicht gewährt

  • Kein Guest-to-Host. Das Live-vmmdevR3HgcmCallAlloc lehnt weiterhin cParms > 32 ab (VMMDevHGCM.cpp:921-926). Ein Gast kann den Wrap nicht über ein legitimes Save platzieren.
  • Host-Kernel. Andere VMs. VBoxSVC.
  • Host-Dateien. Windows Restricted-Token / AppContainer. Project Zero IDispatch 544666386 ist öffentlich und nicht dieser Überrest.
  • Live-HGCM-Argumentgrößen-Wrap (CVE-2013-5892 Live-Sink). Dieser Eintrag ist auf diesem Pin geschlossen (VMMDEV_MAX_HGCM_PARMS 32, VMMDEV_MAX_HGCM_DATA_SIZE 128MiB).
  • Das benachbarte offValue / cbValue-memcpy beim Abschluss ist nur dann ein zweiter Host-Heap-Write, wenn HGCM-Clients im selben sav wiederherstellen. Das ist nicht dieses Lab.

Vollständiger Host-User / Host-Kernel benötigt weiterhin einen Härtungs-Überrest. Die Kombination dieses Smash mit dem öffentlichen IDispatch-Bypass wird verworfen.

Wie ich es gefunden habe

Ich habe VirtualBox/virtualbox auf Tag v7.2.20 Peel f2792cf44 gepinnt. Live-HGCM war die erste Lektüre, weil CVE-2013-5892 diese Klasse war: Argumentgrößen-Wrap in VBOXHGCMCMD. Der Live-Pfad hat weiterhin die Obergrenze:

ASSERT_GUEST_STMT_RETURN(   cParms <= (cbHGCMCall - sizeof(VMMDevHGCMCall)) / cbHGCMParmStruct
                         && cParms <= VMMDEV_MAX_HGCM_PARMS,
                         LogRelMax(50, ("VMMDev: request packet with invalid number of HGCM parameters: ...")),
                         VERR_INVALID_PARAMETER);

Load nicht. vmmdevR3HgcmLoadState nimmt cParms aus dem sav und ruft denselben Allocator auf:

const uint32_t cbCmd = sizeof(VBOXHGCMCMD) + cParms * (sizeof(VBOXHGCMGUESTPARM) + sizeof(VBOXHGCMSVCPARM))
                     + (enmCmdType == VBOXHGCMCMDTYPE_CONNECT ? sizeof(HGCMServiceLocation) : 0);

AssertCompile-Kommentare an diesem Pin setzen CMD auf 120, guestparm auf 40, svcparm auf 24. cParms = 0x4000000 macht das 64-Bit-Produkt zu 0x100000000 + 120. Der Store auf uint32_t behält 120. Dann:

for (i = 0; i < cParms; ++i)
{
    VBOXHGCMGUESTPARM * const pGuestParm = &pCmd->u.call.paGuestParms[i];
    rc = pHlp->pfnSSMGetU32(pSSM, &u32);
    pGuestParm->enmType = (HGCMFunctionParameterType)u32;

paGuestParms liegt bei pCmd + sizeof(VBOXHGCMCMD). Nach dem Wrap ist das das Alloc-Ende. Der erste Store ist bereits OOB.

Bereits festgehaltene Fehlannahmen: Live-HGCM als Restbestand behandeln (es deckelt weiterhin bei 32); 67 Millionen Stores im Harness durchlaufen (das erste Dword ist der Beweis); behaupten, ein Gast könne dies über Save einschleusen; den Heap-Smash im VM-Prozess zum Host-Kernel-Escape aufblasen; öffentliches IDispatch verketten.

Theater: eine Reverse Shell, ein .sav-Parser, das Booten von VirtualBox. Das Orakel ist Wrap plus ein Canary-Smash von VBOX-HGCM-SSM-CPARMS-WITNESS.

Lab

cd lab
./run.sh

Vom Paketstammverzeichnis aus:

python3 vbox-hgcm-ssm-cparms-Abraxas-Labs.py
Tool herunterladen