Vulnerabilità ASP.NET CVE-2008-5100 (bypass firma assembly): esiste una correzione?

Per quanto ho capito, questo CVE è un vero disastro. Il nome sicuro è fondamentalmente una firma sulla DLL e la chiave pubblica è identificata dal " token di chiave pubblica ", che è un hash SHA-1 della chiave troncata a 64 bit . La funzionalità principale del "nome sicuro" è evitare le collisioni quando diversi sviluppatori, che non si conoscono, pubblicano DLL diverse con lo stesso nome.

Si suppone che i nomi forti supportino un framework di integrità del codice: una determinata applicazione farà riferimento a una DLL per nome, versione e token di chiave pubblica; la DLL corrispondente si trova nella Cache degli assembly globali . Un malintenzionato potrebbe tentare di caricare nella GAC una DLL dannosa con lo stesso nome di una vera DLL, sperando in un'altra applicazione (lanciata da un altro utente) per caricare la sua DLL invece di quella corretta. Per fare ciò, poiché l'applicazione contiene il "token della chiave pubblica", l'utente malintenzionato dovrà firmare la sua Evil DLL con una chiave che corrisponde al token della chiave pubblica - e il token della chiave pubblica è un hash crittografico , non può.

Il CVE-2008-5100 si riferisce principalmente a qualcuno che nota che le firme su DLL vengono effettivamente verificate quando la DLL è installata nel GAC, non quando viene caricata dal GAC. Questo ha senso: il GAC è protetto da alterazioni arbitrarie da parte del sistema operativo. Pertanto, se la DLL era valida all'entrata, è comunque valida in seguito. O, più accuratamente, per modificare una DLL che è stata installata nel GAC, hai bisogno di ampi diritti amministrativi che rendono tutto questo moot: se hai quel potere, allora possiedi già la macchina in tutti i modi possibili. Questo spiega il silenzio assordante del Web su questo CVE: è un non-problema . È come affermare che un lucchetto che può essere aperto dal interno di una casa è una vulnerabilità di sicurezza, perché un ladro che è già in casa potrebbe quindi aprire la porta e lasciare che ... ladri entra ? Vedi, quando uso un'analogia senza il velo del gergo tecnico, tutto diventa ridicolo.

Quindi il report dallo scanner non è appropriato. Il tuo problema è trovare il modo giusto per spegnerlo. La mia raccomandazione sarebbe quella di non utilizzare uno "scanner di sicurezza" che rende tali rapporti stupidi.

Ora, se guardiamo ai dettagli, c'è qualcosa di "subottimale" in questo business "Strong Name"; vale a dire, l'hash è troncato a 64 bit. Ciò significa che la resistenza a preimmagini è 2 ⁶⁴ , che è alta ma ancora tecnologicamente raggiungibile (uno sforzo di tale portata è stato fatto pubblicamente almeno una volta ) (a quanto pare, un secondo tentativo di questo tipo è iniziato in diverse università, per risolvere il registro discreto in una curva ellittica a 128 bit - da concludersi all'interno di un stimato dieci anni). Un utente malintenzionato potrebbe provare a generare una chiave pubblica che corrisponda al token della chiave pubblica utilizzato per una DLL specifica; se riesce, allora può fare una falsa DLL che sarà accettata dalle applicazioni, e per questo avrebbe solo bisogno di un accesso "normale" al GAC (non preoccuparti se nessun potenziale aggressore può aprire una normale sessione utente sulle tue macchine ).

La produzione di 2 ⁶⁴ coppie di chiavi RSA è costosa (non tanto quanto si potrebbe credere perché l'attaccante può rendere le chiavi un po 'invalide, ma comunque costose) quindi dubito che questo attacco sarebbe molto pratico, ma il margine di sicurezza è piuttosto basso.

Volevo solo aggiungere:

This vulnerability has a CVSS score of 10.0, making it the equivalent of the worst possible vulnerability ever encountered.

Sicuramente non lo puoi sempre supporre. Non tutti i CVSS 10 sono uguali ... alcuni sono molto, molto più severi di altri. Onestamente, è davvero difficile assegnare un valore numerico piatto a una vulnerabilità.