Adobe Flash Player è scritto in un linguaggio di codice non gestito, vulnerabile al seguente vulnerabilità comunemente citate :
- Overflow del buffer basato su heap
- Vulnerabilità use-after-free
- Overflow intero
- Overflow del buffer basato su stack
- Vulnerabilità double-free
- "confusione di tipo" non specificata
- Argomento formato stringa stringa
In genere, il codice non gestito è anche soggetto a un flusso di dati o flusso di dati approfondito o arricchito. I ricercatori di sicurezza più approfonditi esaminano i percorsi del codice, più saranno scoperte le vulnerabilità di memoria-trespass. Flash Player ha un flusso di controllo molto profondo, prende molte decisioni e invoca un sacco di fattori situazionali, aggiungendo alla sua complessità.
Lo stato dell'arte della memoria che affligge le vulnerabilità è continuamente aggiornato dai ricercatori della sicurezza. Negli ultimi anni, le catene ROP hanno reso lo sviluppo degli exploit un processo più semplice e più ampio. Gli strumenti e le tecniche aumentano in modo esponenziale dal momento che più ricercatori dedicati alla sicurezza vengono reclutati da organizzazioni sempre più grandi e potenti. Prendi questo post del blog di Libformatstr dall'unico giorno in cui il ricercatore ha rilasciato un nuovo framework per semplificare il processo di sviluppo degli exploit. È un esempio della ricerca esplosiva e innovativa in corso nel campo dello sviluppo degli exploit.
Per questi motivi e l'impollinazione incrociata degli exploit di Flash in Exploit Kits presenti nei sistemi di distribuzione del traffico, in particolare tramite Domain Shadowing, aggiorno Flash Player tramite Chrome e lo spengo deliberatamente (ovvero, chrome: // plugins, disable ), attivandolo solo per destinazioni note come i sistemi IT sotto il controllo di my o my org. Le applet Java hanno avuto una cronologia simile a quella di Flash Player, che ha causato il blocco permanente di Chrome per queste applet: mi aspetto che le applet Flash seguiranno presto.