Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
vbox-hgcm-ssm-cparms — VirtualBox 7.2.20 - Alta - Locale - Heap overflow - HGCM SSM cParms wrap | Kitploit
Strumenti/GitHubGitHub/abraxas/vbox-hgcm-ssm-cparms
Memory ForensicsAnalisi delle VulnerabilitàExploitVirtualizzazione per la SicurezzaPaper e RicercaBinary ExploitationLab e Pratica
GitHubabraxas/vbox-hgcm-ssm-cparms

vbox-hgcm-ssm-cparms

VirtualBox 7.2.20 - Alta - Locale - Heap overflow - HGCM SSM cParms wrap

Vedi Repository
33 giorni faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

Abraxas Labs - vbox-hgcm-ssm-cparms

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

vbox-hgcm-ssm-cparms

Classe: Heap overflow Raggiungibilità: Locale (host)

Oracle VM VirtualBox OSS 7.2.20 (f2792cf44) - Oracle

L'HGCM live rifiuta ancora cParms > 32. Il caricamento dello stato salvato no. vmmdevR3HgcmLoadState legge cParms dal .sav senza alcun limite VMMDEV_MAX_HGCM_PARMS, poi dimensiona il comando con uint32_t cbCmd. Con cParms = 0x4000000 quel prodotto va in wrap a sizeof(VBOXHGCMCMD) (~120). Il primo store di enmType è già una scrittura di 4 byte oltre il blocco.

Un utente host che ripristina uno stato salvato ostile causa un overflow dell'heap del processo VM. Un guest non può inserirlo tramite Save.

IDnessuna CVE al momento
ClasseHeap overflow (scrittura OOB nel processo VM; non è un escape dal kernel host)
RaggiungibilitàLocale (host) (UI:R ripristino stato salvato / snapshot)
CWECWE-190, CWE-787
CVSSHigh: 7.8 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
ProdottoVirtualBox OSS
Affetto7.2.20 (f2792cf44f663989818507e36d3db5f978523c5e)
Authl'utente host ripristina una VM salvata, uno snapshot o un .sav
LicenzaGNU Affero GPL v3.0
Labsolo 127.0.0.1. Harness sorgente. Nessun avvio di VirtualBox, nessuna analisi del .sav.

Cosa può fare un attaccante

Consegnare all'operatore una cartella VM il cui stato salvato trasporta una CALL VMMDev HGCM in sospeso. L'operatore fa clic su Start su una VM salvata, ripristina uno snapshot o adotta il .sav. Il ripristino della console attraversa SSMR3 fino a vmmdevR3LoadExec e poi vmmdevR3HgcmLoadState. Questo è UI:R. Il residuo è il parser, non una hypercall del guest.

VMMDev è attivo per impostazione predefinita. Nessun 3D. Nessun Guest Additions. Nessun VRDP. Non PUEL.

Metodo e sink

PassoDoveCosa concede
RipristinoUI host / VBoxManage startvm su una VM salvataL'utente host apre il .sav ostile. È l'unico clic richiesto.
Unità SSMVMMDev vmmdevR3HgcmLoadState (VMMDevHGCM.cpp:2043-2091)SSMGetU32 in cParms senza il limite VMMDEV_MAX_HGCM_PARMS (32).
Wrap dell'allocazionevmmdevR3HgcmCmdAlloc (VMMDevHGCM.cpp:376-381)uint32_t cbCmd = sizeof(VBOXHGCMCMD) + cParms * (40+24). cParms = 0x4000000 va in wrap a ~120. RTMemAllocZ di quella dimensione riesce rispetto al budget dell'heap.
Primo storeciclo di caricamento paGuestParms[i].enmType (VMMDevHGCM.cpp:2085-2091)paGuestParms è pCmd + sizeof(VBOXHGCMCMD), che dopo il wrap è già la fine dell'allocazione. Il primo dword di tipo è una scrittura OOB di 4 byte. Il flusso necessita solo dell'header CALL più un tipo di parametro. Non servono 67 milioni di record.

Privilegi

TipoProvenienzaCosa ottiene l'attaccante
ReconnessunaI byte di overflow sono scelti dal sav. Non si tratta di una fuga di informazioni. Il contenuto dell'heap non viene restituito al file.
Integritàdimostrato in laboratoriocParms=0x4000000 fa wrappare uint32_t cbCmd a 120. Un singolo store enmType con i=0 distrugge un canary 0xA5. canary0=56424f58 è il prefisso VBOX di VBOX-HGCM-SSM-CPARMS-WITNESS. Il controllo cParms=2 lascia il canary intatto.
IntegritàdedottoUlteriori record di parametri controllati dal sav (dword di tipo più campi a 32/64 bit o descrittori di puntatore) scrivono linearmente a partire dal blocco RTMemAllocZ di ~120 byte in VirtualBoxVM / VBoxHeadless. Si tratta di una primitiva di scrittura nel processo della VM, della stessa classe della memcorr della migrazione di QEMU. Questo pacchetto non dimostra il controllo del puntatore di istruzione.
DisponibilitàdedottoCrash di VBoxVM se lo smash non viene trasformato in una scrittura controllata. L'harness è uno smash del canary, non un crash del processo VirtualBox.

Cosa questo residuo non concede

  • Non guest-to-host. La funzione live vmmdevR3HgcmCallAlloc rifiuta ancora cParms > 32 (VMMDevHGCM.cpp:921-926). Un guest non può inserire il wrap tramite un Save legittimo.
  • Kernel host. Altre VM. VBoxSVC.
  • File host. Restricted-token / AppContainer di Windows. Il Project Zero IDispatch 544666386 è pubblico e non è questo residuo.
  • Wrap della dimensione degli argomenti HGCM live (sink live di CVE-2013-5892). Quella voce è chiusa su questo pin (VMMDEV_MAX_HGCM_PARMS 32, VMMDEV_MAX_HGCM_DATA_SIZE 128MiB).
  • La memcpy gemella offValue / cbValue al completamento è una seconda scrittura sull'heap host solo se i client HGCM ripristinano nello stesso sav. Non è questo laboratorio.

Per ottenere host-user / host-kernel completi serve ancora un residuo di hardening. Combinare questo smash con il bypass IDispatch pubblico è scartato.

Come l'ho trovato

Ho fissato il tag v7.2.20 di VirtualBox/virtualbox con peel f2792cf44. La prima lettura è stata l'HGCM live perché CVE-2013-5892 era di questa classe: wrap della dimensione degli argomenti in VBOXHGCMCMD. Il percorso live ha ancora il limite:

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 no. vmmdevR3HgcmLoadState prende cParms dal sav e chiama lo stesso allocatore:

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

AssertCompile commenta su questo pin mette CMD a 120, guestparm a 40, svcparm a 24. cParms = 0x4000000 rende il prodotto a 64 bit 0x100000000 + 120. La scrittura su uint32_t mantiene 120. Poi:

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

paGuestParms si trova a pCmd + sizeof(VBOXHGCMCMD). Dopo il wrap, quella è la fine dell'allocazione. Il primo store è già OOB.

Vicoli ciechi già registrati: trattare l'HGCM live come il residuo (è ancora limitato a 32); percorrere 67 milioni di store nell'harness (il primo dword è la prova); sostenere che un guest possa inserirlo tramite Save; gonfiare la corruzione dell'heap del processo VM fino a un'evasione verso il kernel host; concatenare IDispatch pubblici.

Teatro: una reverse shell, un parser .sav, l'avvio di VirtualBox. L'oracolo è il wrap più una corruzione canary di VBOX-HGCM-SSM-CPARMS-WITNESS.

Lab

cd lab
./run.sh

O dalla radice del pacchetto:

python3 vbox-hgcm-ssm-cparms-Abraxas-Labs.py
Scarica lo strumento