Domanda:
La semplice decompressione di un'immagine JPEG può innescare un exploit?
JDługosz
2015-08-27 00:01:00 UTC
view on stackexchange narkive permalink

Il romanzo Daemon è spesso elogiato per essere realistico nella sua rappresentazione, piuttosto che semplicemente per mescolare parole d'ordine.

Tuttavia, questo mi è sembrato irrealistico:

L'e-mail di Gragg conteneva un JPEG avvelenato del logo dell'intermediazione. I JPEG erano file di immagine compressi. Quando l'utente visualizzava l'e-mail, il sistema operativo eseguiva un algoritmo di decompressione per rendere il grafico sullo schermo; è stato questo algoritmo di decompressione che ha eseguito lo script dannoso di Gragg e lo ha lasciato scivolare nel sistema dell'utente, garantendogli pieno accesso. C'era una patch disponibile per il difetto di decompressione, ma le persone più anziane e ricche in genere non avevano idea delle patch di sicurezza.

Esiste una cosa del genere? Questa descrizione è basata su un vero exploit?

È stato pubblicato nel dicembre 2006.

È sensato dire che "il sistema operativo" stava decomprimendo l'immagine per renderla?

Nota che questo non ha nulla a che fare con la sicurezza degli script di caricamento delle immagini PHP. Sto chiedendo informazioni sul processo di decodifica della visualizzazione di un JPEG , non sugli script che ricevono input da utenti remoti, né sui file denominati erroneamente .jpeg . Il contrassegno duplicato a cui sto rispondendo sembra scadente anche per una corrispondenza di parole alla moda; in realtà niente di simile tranne menzionare i file di immagine.

Sfortunatamente, quasi tutti i formati possono essere avvelenati. Anche alcuni file danneggiati possono mandare in crash le routine di decompressione e / o decodifica incorporate.
Non riesco a trovare alcuna prova su Internet, ma ricordo che una volta ho ricevuto un'immagine "JPG" che ha aperto il vassoio del mio CD (era più di 12 anni fa con Windows XP).
Il malware nei file di immagine è diventato popolare nella narrativa da quando l'exploit GDI + nel 2004 era un caso reale. Questo esempio è abbastanza plausibile. Alcuni lo sono meno. Forse il peggio è stato il caso di * Bones * dove qualcuno ha inciso un'immagine frattale nell'osso di una vittima di omicidio che ha preso il controllo della rete dei protagonisti quando hanno caricato le fotografie. Mi ha fatto male il cervello.
Questo non è sufficiente per una risposta reale, ma un formato di immagine diverso, WMF, in realtà ti ha permesso di eseguire codice arbitrario * per progettazione *. È stato progettato per una grafica vettoriale intelligente ai tempi di Windows a 16 bit e all'epoca era considerato un buon compromesso. Avanti veloce fino ad oggi e Internet rende questo un brutale buco di sicurezza. C'era anche un exploit dei file TTF (font). È del tutto possibile che alcuni parser di JPG possano avere una vulnerabilità di exploitabel allo stesso modo.
Se jpeg non consente il codice arbitrario per progettazione, come può avere lo stesso tipo di vulnerabilità?
AFAIR quell'apri CD-tray non era un JPEG - era uno script VBS, che IE eseguiva nonostante l'estensione del file jpeg.
Era un metodo comune per eseguire il root della prima versione di iPhone.
@arivero "it" si riferisce a ...? (Un exploit di decodifica o qualcosa del genere in un commento precedente)
@user158037 grazie, non ricordavo se fosse il visualizzatore di immagini o IE ad avere questo difetto.
@JDługosz er ... "it" si riferisce alla tua domanda originale, "decompressione di un'immagine JPEG".
La semplice visualizzazione di una pagina con un file jpeg avrebbe "rootato" il telefono? Com'è comodo. Hai un link di riferimento per questo?
Sono piacevolmente sorpreso di vedere Daemon qui. L'ho letto qualche anno fa ed è incredibile quanto sia rimasto fedele alla tecnologia realistica e preesistente. Infatti, proprio la scorsa settimana, mi sono imbattuto in un sistema audio ipersonico (il tipo di sistema audio che era a casa di Sobol) in un Best Buy, ed è stato piuttosto interessante da provare.
possibile duplicato di [Il malware può essere allegato a un'immagine?] (http://security.stackexchange.com/questions/55061/can-malware-be-attached-to-an-image/)
Uno degli exploit utilizzati su PS3 per giocare a giochi PS2 registrati (non scherzando) è stato quello di aprire un'immagine TIFF appositamente predisposta sulla versione 1.75 del firmware. Inoltre, c'è la [vulnerabilità StageFright] (http://security.stackexchange.com/questions/95165/how-exactly-does-the-stagefright-vulnerability-work-on-android) su Android, che non richiede nemmeno aprendo il messaggio! Quindi sì, assolutamente possibile.
Secondo quanto riferito, ne sta succedendo uno nuovo. [Fonte] (http://steamcommunity.com/groups/reddit#announcements/detail/145594019967735932)
Inoltre, JPEG + ZIP è anche una tecnica di steganografia: una ignora i contenuti extra alla fine del file, l'altra all'inizio di un file.[Esempio.] (Https://github.com/MiroslavVitkov/scripts/tree/master/crypto)
Cinque risposte:
gowenfawr
2015-08-27 00:10:55 UTC
view on stackexchange narkive permalink

Esiste una cosa del genere?

Assolutamente. Fornire input dannosi a un parser è uno dei modi più comuni per creare un exploit (e, per un JPEG, "decompressione" è "parsing").

Questa descrizione è basata su alcuni exploit?

Potrebbe essere basato sulla vulnerabilità di overflow del buffer di Microsoft Windows GDI +:

Esiste una vulnerabilità di overflow del buffer in il modo in cui il componente di analisi JPEG di GDI + (Gdiplus.dll) gestisce immagini JPEG non corrette . Introducendo un file JPEG appositamente predisposto al componente vulnerabile, un utente malintenzionato remoto potrebbe attivare una condizione di buffer overflow.

...

Un telecomando, non autenticato l'autore dell'attacco potrebbe potenzialmente eseguire codice arbitrario su un sistema vulnerabile introducendo un file JPEG appositamente predisposto. Questa immagine JPEG dannosa può essere introdotta nel sistema tramite una pagina web, un messaggio di posta elettronica HTML o un allegato di posta elettronica.

.

È stato pubblicato nel dicembre 2006.

La vulnerabilità di analisi GDI + JPEG è stata pubblicata nel settembre 2004.

È è sensato dire che "il sistema operativo" stava decomprimendo l'immagine per renderla?

Sicuro; in questo caso, era una libreria di sistema che richiedeva una patch del fornitore del sistema operativo per correggerla. Spesso tali librerie vengono utilizzate da più pacchetti software, rendendole parte del sistema operativo piuttosto che specifiche dell'applicazione.

In realtà, "l'applicazione di posta elettronica ha invocato una libreria di sistema per analizzare un JPEG", ma "il sistema operativo "è abbastanza vicino per un romanzo.

Se ricordo bene, alcuni dei metodi iniziali di "jailbreak" per Playstation Portable (PSP) di Sony utilizzavano un file di immagine "appositamente predisposto" che rompeva il decoder della PSP e consentiva l'esecuzione del codice incorporato nel JPG.
"L'attaccante potrebbe potenzialmente eseguire codice arbitrario" è quel boilerplate per * qualsiasi * bug di overflow del buffer? L'elevazione dei privilegi dal thread in modalità utente sarebbe un altro problema.
@JDługosz, sì, questa è una descrizione standardizzata. La maggior parte dei CVE e le descrizioni dei buchi di sicurezza utilizzano una serie di frasi standard come "[locale | remoto] un attaccante potrebbe potenzialmente eseguire [arbitrario] [comandi | codice] [con privilegi [utente | elevato]]". Il riutilizzo di parole chiave e frasi succinte ("boilerplate") consente ai difensori di valutare rapidamente il rischio - ad esempio, la parola chiave [local | remote] è importante per la valutazione del rischio. La frase usata nell'annuncio GDI + mi dice che il codice funziona con i privilegi dell'utente che apre il JPEG - nel 2004-2006 Windows, spesso un amministratore!
Questo exploit sarebbe possibile solo se l'algoritmo di decompressione in questione avesse un bug che consentisse l'esecuzione di codice arbitrario, giusto?
@TripeHound sì, colori dell'arcobaleno, fantasma nell'immagine di copertina della shell e formato tiff per usare chickHEN. Li ho ancora da qualche parte qui intorno. Modifica: sì, chickHEN ma non tiff: /
@JDługosz Usano il termine "l'attaccante potrebbe potenzialmente eseguire codice arbitrario" piuttosto che "buffer overflow" perché l'effetto è più importante ai fini del processo decisionale rispetto al metodo utilizzato per farlo. Ad esempio, non mi interessa se esegui l'overflow del buffer per iniettare codice o se esegui il jailbreak aprendo un nuovo processo che riceve ed emette il tuo comando. L'effetto importante è che l'attaccante può ora emettere bytecode sulla mia macchina.
@MaxNanasy Sì, ma * sempre * è così; a volte è un bug nel codice, a volte è un bug nel sistema operativo, a volte è un bug nel design. E come molti esempi hanno mostrato, molti dei parser * hanno * in effetti questi bug - l'overflow del buffer che porta all'esecuzione del codice è quello visto più spesso, penso. È uno dei motivi per cui MS ha spinto .NET: finché rimani al sicuro nell'ambiente gestito, hai appena eliminato un'enorme via di vulnerabilità. Naturalmente, molti parser useranno codice non sicuro per motivi di prestazioni, quindi non è buono come potrebbe essere, ma aiuta comunque.
Nic Barker
2015-08-27 08:18:34 UTC
view on stackexchange narkive permalink

Concordare con altri di dire di sì è del tutto possibile, ma anche aggiungere un aneddoto interessante:

Joshua Drake (@jduck), ha scoperto un bug basato su un concetto molto simile (le immagini sono interpretate da il sistema operativo) che finì per essere chiamato "Stagefright" e interessò un numero ridicolo di dispositivi Android.

Ha anche scoperto un bug simile basato su immagini in libpng che provocherebbe il crash di alcuni dispositivi. Ha twittato un esempio dell'exploit dicendo fondamentalmente "Ehi, guarda questo bel PNG dannoso che ho creato, probabilmente bloccherà il tuo dispositivo", senza rendersi conto che Twitter aveva aggiunto il rendering automatico delle immagini in linea. Inutile dire che molti dei suoi follower hanno iniziato a causare il crash delle loro macchine nell'istante in cui il browser ha provato a caricare la miniatura dell'immagine nel loro feed.

In realtà, il framework multimediale si chiama "Stagefright", ma il nome è già abbastanza accattivante da chiamarlo "Stagefright bug". /fuori tema
user158037
2015-08-27 20:48:15 UTC
view on stackexchange narkive permalink

Non realistico? Recentemente si è verificato un bug critico nell'analisi della definizione dei caratteri: https://technet.microsoft.com/en-us/library/security/ms15-078.aspx e le note di modifica di libjpeg sono piene di avvisi sulla sicurezza. L'analisi dei file [1] è difficile: overflow, underflow, accesso fuori dai limiti. Recentemente sono stati sviluppati molti strumenti di fuzzing per il rilevamento semiautomatico di input che possono causare crash.

[1] o pacchetti di rete, XML o anche query SQL.

Sì ... così difficile con codice non gestito - Se si codificasse solo in codice gestito, gli overflow / underflow del buffer si ridurrebbero al di sotto dell'1% del loro attuale impatto sulla sicurezza ...
Se gli autori di compilatori C fossero interessati a promuovere la robustezza, C potrebbe superare Java per molte attività in cui la semantica è "Dato un input valido, produce un output corretto; dato un input non valido, produce output liberamente vincolato". Sfortunatamente, gli autori di compilatori sembrano non avere alcun interesse in questo e preferiscono ottimizzare la logica che impedirebbe forme critiche per la sicurezza di UB se non impedisce che quelle che altrimenti sarebbero forme di UB non critiche per la sicurezza si verifichino in quelle stesse situazioni.
Il codice gestito di @Falco: non è gratuito; d'altra parte, poiché il C iper-moderno sta eliminando molti dei vantaggi prestazionali che C aveva nei casi in cui ai programmatori non interessava un comportamento preciso in casi di cose come l'overflow, l'unico modo per vedere C rimanere competitivo è cataloga ufficialmente i comportamenti che non erano garantiti dallo Standard ma erano ampiamente implementati e consente ai programmatori di specificarli.
@Falco Sfortunatamente, anche i runtime gestiti hanno la loro quota di buffer overflow. Le persone che hanno scritto Java hanno fatto un lavoro orribile usando la programmazione difensiva per proteggere i punti deboli del runtime. In effetti, ne ho appena incontrato uno nell'ultimo Java (e l'ho segnalato a Oracle, che lo ha confermato). Tutto si riduce a una sconsiderata ricerca di un'ottimizzazione prematura. Mi chiedo se improvvisamente avremo una svolta e possiamo costruire chip a 20 GHz, i programmatori finalmente accetteranno i controlli dei limiti e cose del genere. O sono troppo testardi.
MS15-078 è ancora più allarmante perché il driver del font Adobe * viene eseguito in modalità kernel *.
@AleksandrDubinsky Non tratterrei il respiro: abbiamo avuto alcuni aumenti nell'ordine di grandezza delle velocità di elaborazione e così tanti si aggrappano ancora per evitare il controllo dei limiti. Le ragioni che hanno avuto finora saranno le stesse se le CPU diventeranno 1000 volte più veloci. C'è speranza, però - per esempio, Microsoft Research ha lavorato su un sistema operativo gestito in piena regola da zero - non è stato progettato per le prestazioni ma piuttosto per la sicurezza e la protezione, ma per un progetto di ricerca, ha funzionato comunque abbastanza bene. E quando l'intero sistema operativo è gestito, si evitano i costi di comunicazione tra gestito e non gestito.
Emilio M Bumachar
2015-08-31 00:42:25 UTC
view on stackexchange narkive permalink

Come altri hanno sottolineato, tali attacchi di solito sfruttano gli overflow del buffer.

Per quanto riguarda i noccioli di come, si chiama un attacco che distrugge lo stack. Implica la corruzione dello stack di chiamate e la sovrascrittura di un indirizzo in codice legittimo da eseguire con un indirizzo in codice fornito dall'attaccante, che viene invece eseguito.

Puoi trovare i dettagli su insecure.org/stf/smashstack.html.

TheJulyPlot
2015-08-27 00:08:04 UTC
view on stackexchange narkive permalink

Sì, è possibile:

Una nuova variante del malvagio trojan bancario Zeus - soprannominato ZeusVM - è nascosta nei file di immagine JPG, secondo i risultati di collaborazione di Jerome Segura, ricercatore senior sulla sicurezza con Malwarebytes e Xylitol, ricercatore di sicurezza francese.

L'atto è noto come steganografia: nascondere messaggi o immagini in altri messaggi o immagini.

Nel caso di ZeusVM, il codice del malware è nascosto in immagini JPG senza pretese, ha rivelato un post sul blog di Segura. Queste foto servono come indirizzamento errato per ZeusVM per recuperare il suo file di configurazione.

"Il JPG contiene il file di configurazione del malware, che è essenzialmente un elenco di script e istituzioni finanziarie, ma non deve essere aperto dal vittime stesse ", ha detto Segura a SCMagazine.com in una corrispondenza e-mail del martedì. "In effetti, lo stesso JPG ha pochissima visibilità per l'utente ed è in gran parte una tecnica di cloaking per garantire che non venga rilevato dal punto di vista del software di sicurezza."

Fonte.

Sebbene la tecnica * sia * possibile contro un decodificatore JPEG difettoso, questo non sembra essere un esempio del genere. Si tratta semplicemente di codificare un file di configurazione in un JPEG per nascondere gli aggiornamenti a un'infezione * esistente *. OP sembra chiedere informazioni sulle immagini JPEG come vettore per la trasmissione di nuove infezioni.
Bene, se vuoi essere un pedante al riguardo, l'analisi e la decompressione sono due cose separate anche nei jpeg e nell'informatica più ampia. Uno descrive i dati * per modo di dire * l'altro, beh, decomprime qualcosa. In ogni caso, il punto è che il malware può essere distribuito tramite jpeg utilizzando una serie di metodi discreti.
Penso che questo esempio sia ancora più interessante di una semplice immagine infetta con la quale è probabile che un utente debba interagire con essa. Questo esempio mostra piuttosto un metodo dannoso sofisticato che non attira l'attenzione dell'utente e può portare ad attacchi man-in-the-browser
Il punto di un'immagine infetta che sfrutta un decompressore JPEG è che non è richiesta * nessuna * interazione. Se hai un'implementazione JPEG difettosa, come nell'esempio GDI + fornito da @gowenfawr, puoi essere compromesso semplicemente visualizzando una pagina web o un'e-mail. Tali immagini possono essere fornite da uno script pubblicitario anche su siti affidabili. Questo è * molto * più interessante e preoccupante del JPEG utilizzato come meccanismo di comunicazione apparentemente innocuo per un'infezione * preesistente *.
Capisco il tuo punto, ma non la pertinenza del mio commento. Puoi essere infettato semplicemente scaricando l'immagine in un browser anche da questo. L'esempio gowenfawrs è stato un buon esempio sì, sono d'accordo. Più vicino all'esempio teorico nella domanda originale. Ad ogni modo, come ho detto, ci sono molti metodi diversi per distribuire malware tramite un jpeg, incluso questo che ho presentato semplicemente come un esempio di jpeg dannoso. https://blog.malwarebytes.org/security-threat/2014/02/hiding-in-plain-sight-a-story-about-a-sneaky-banking-trojan/
@TheJulyPlot Penso che tu stia fraintendendo come funziona. In questo esempio, Zeus Trojan utilizza un jpg per nascondere il modo in cui scarica il suo file di configurazione. Un computer già infettato dal trojan scaricherà l'immagine ed estrarrà i dati. L'immagine contiene solo il file di configurazione (nascosto), non il trojan, e non ha alcun meccanismo per infettare i sistemi da solo. Non puoi essere infettato semplicemente scaricando l'immagine in un browser.
Non sto affatto fraintendendo..in effetti quello è stato descritto nel link che ho postato.
Non sono sicuro che "sofisticato" descriva davvero qualcosa del genere. I decodificatori JPEG generalmente funzionano solo su un byte EOF (se presente), rendendo questo facile come concatenare qualsiasi altro file alla fine del file immagine. `cat img.jpg evil.zip> evil.jpg` è tutto ciò che serve.


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...