Domanda:
Se conosco l'architettura della CPU di un target, posso inviare istruzioni incorporate in un'immagine?
Faminha102
2018-10-29 06:47:57 UTC
view on stackexchange narkive permalink

Posso inviare istruzioni incorporate in un'immagine a un target, se conosco la sua architettura della CPU?

Possibile duplicato di [Il malware può essere allegato a un'immagine?] (Https://security.stackexchange.com/questions/55061/can-malware-be-attached-to-an-image)
Certo che puoi.Ma non li eseguirà.In realtà la maggior parte dei byte sono istruzioni CPU valide.
certo, scrivi poi su un pezzo di carta e scatta una foto ... :)
Si noti che ci sono formati di immagine che si basano esplicitamente sull '"esecuzione di codice arbitrario" (principalmente dalla vecchia era quando la compatibilità e il risparmio di memoria e CPU erano più importanti della protezione delle immagini).Il più notevole è probabilmente WMF, dove la funzionalità era molto ragionevole e sicura nell'implementazione originale, ma la sicurezza è stata persa durante il porting del codice da Windows 3.0 (16 bit) a Windows NT (32 bit e solo su x86).Quindi questo è stato uno dei rari casi in cui ad es.Windows 98 (desktop) era più sicuro di Windows NT (server / professionale) :)
Le [vulnerabilità] (https://docs.microsoft.com/en-us/security-updates/vulnerabilityresearchadvisories/2012/msvr12-004) hanno portato a porre questa domanda?
Certo che puoi, e anche per qualsiasi altra forma di media.Quindi è meglio fidarsi del proprio visualizzatore multimediale per non avere bug o "funzionalità" impreviste.
Sette risposte:
Antzi
2018-10-29 13:42:48 UTC
view on stackexchange narkive permalink

Altre risposte forniscono una buona spiegazione tecnica, ma fammi provare con un'analogia:

Invia il numero della tua carta di credito a scam@example.com

  • L'hai letto?

  • L'hai fatto?

È più o meno lo stesso per la tua CPU. Leggere qualcosa non è come eseguirlo.

Tuttavia, non è la migliore analogia perché come esseri umani possiamo fermarci e decidere se qualcosa è una buona idea, ma un computer no.Il computer deve "decidere" prima di iniziare.
+1 per aver cercato di spiegare per analogia.Solo perché * leggo * un insieme di istruzioni, non significa che in realtà * le esegua *.
@CaptainMan è un'ottima analogia.Non mi sorprenderebbe più di tanto se dopo alcuni anni "scam@scammer.org" non ricevesse i numeri di carta di credito b / c di questo intervento.
Qual è il passaggio successivo?Sono passate quasi 8 ore da quando ho inviato la posta e non ho ancora ricevuto risposta.
@emory Pensi davvero che qualcuno che sa leggere l'inglese abbastanza bene da trovare questa pagina e leggere quella frase non capirà il contesto in cui è stata pubblicata, al punto da scambiarlo per istruzioni che devono eseguire?
@Adonalsium Sì, penso che con un numero sufficiente di lettori sia inevitabile.In effetti, siamo portati a credere che sia già successo.
@CaptainMan Ed è qui che entrano in gioco la convalida degli input, il controllo dei limiti, la separazione dei dati e la memoria delle istruzioni, le strategie di protezione della memoria e così via.Hai guardato il messaggio e hai deciso che non era sicuro eseguire le istruzioni.Tutto quanto sopra fornisce alla CPU o al sistema operativo la capacità di prendere tale decisione.
Ti viene detto di copiare la scrittura dal pezzo di carta su un altro pezzo di carta.Il foglio dice "Invia il numero della tua carta di credito ...".Sei perfettamente in grado di elaborare queste istruzioni (in particolare, copiarle), senza eseguirle.Non è diverso che se il giornale dicesse "erwcwmexrnwem, cwtuvklewer".
Per completare l'analogia, supponiamo che il truffatore riesca a incorporare l'istruzione in una lettera che sembra essere stata inviata dalla banca.Ora il messaggio si trova all'interno di un'area contrassegnata come "istruzioni", e verrà eseguito.
@emory - apparentemente "scammer.org" è in vendita, quindi potresti acquistare il dominio e aspettare di vedere cosa succede se lo desideri.:)
@Jules è una truffa :)
@Adonalsium In prospettiva, è comune per coloro che gestiscono una truffa nigeriana * continuare * a riferirsi a se stessi come un principe della Nigeria, anche se il nome è sinonimo della truffa.Si ritiene che questo funzioni come una sorta di filtro: solo i più creduloni continueranno a rispondere a un principe della Nigeria.Le email di massa sono economiche, ma il resto del processo è svolto da un essere umano.Il fatto che continuino a usare questo soprannome piuttosto che evolversi * fortemente * suggerisce che un numero sufficiente di persone si innamora di questa truffa per valerne la pena.
@CaptainMan Non evitiamo di inviare un'e-mail perché ci siamo fermati e abbiamo deciso se fosse o meno una buona idea.Proprio come un computer può scegliere di rendere i dati leggibili o eseguibili in base al contesto, noi possiamo fare lo stesso.Stiamo leggendo questa truffa in un contesto informativo, non nel contesto di un ordine che dobbiamo seguire.
@CortAmmon IIRC sono soprattutto gli anziani che cadono nella demenza che si fidano di e-mail del genere ... il che lo rende più schifoso.Indipendentemente da ciò, questo è un problema di fiducia, non un problema di comprensione della lettura.
@forest sì.Non cascarci perché sappiamo che le istruzioni sarebbero il tuo lavoro antivirus.
"Tutti si tirano indietro! Ho l'immagine di una pistola e non ho paura di usarla!":-P
Un'analogia migliore potrebbe essere "Vuoi uscire con me?% § ~ ÍŠ [carta di credito borseggiatore]".
L'analogia è imprecisa perché le e-mail sono comunemente utilizzate per inviare istruzioni.Un'immagine con codici operativi non viene visualizzata dalla CPU come un insieme di istruzioni.
yshavit
2018-10-29 11:28:01 UTC
view on stackexchange narkive permalink

Le istruzioni per la CPU sono fornite in quelli che vengono chiamati codici operativi e hai ragione che quelli vivono nella memoria proprio come la tua immagine. Tuttavia, vivono in "aree" di memoria concettualmente diverse.

Ad esempio, potresti immaginare un codice operativo "read" (0x01) che legge un byte di input da stdin e lo inserisce da qualche parte, e un altro operando "add" (0x02) che aggiunge due byte. Alcuni codici operativi possono accettare argomenti, quindi ne daremo alcuni al nostro esempio: il codice operativo "read" prende un operando per dove memorizzare il byte che legge, e quello "add" prende tre operandi: due per dove leggere i suoi input e uno per dove scrivere il risultato. 

  0x01 a1 // legge un byte nella posizione di memoria 0xa10x01 a2 // legge un byte nella posizione di memoria 0xa20x02 a1 a2 a3 // legge i byte nelle posizioni 0xa1 e 0xa2, aggiungili // e scrivi il risultato nella posizione 0xa3

Questo è tipico di come funzionano molte istruzioni: la maggior parte di esse opera solo sui dati che sono in memoria , e alcuni di loro inseriscono nuovi dati in memoria dal mondo esterno (dalla lettura di stdin, in questo esempio, o dalla lettura di un file o di un'interfaccia di rete).

Sebbene sia vero che le istruzioni e i dati su cui operano sono entrambi in memoria, il programma eseguirà solo le istruzioni. È compito della CPU, del sistema operativo e del programma assicurarsi che ciò avvenga. Quando falliscono, puoi infatti caricare i dati nello spazio di esecuzione, ed è un grave bug di sicurezza. Buffer overflow sono probabilmente l'esempio più famoso di un tale bug. Ma a parte questi tipi di bug, puoi essenzialmente pensare allo spazio dati e allo spazio di esecuzione come blocchi separati di CPU.

In un computer giocattolo, usando l'esempio sopra, la memoria potrebbe assomigliare a qualcosa di simile : 

  (loc) | Iniziale | Dopo op 1 | Dopo l'op 2 | Dopo l'operazione 3 | 0x00 | * 01 a1 | 01 a1 | 01 a1 | 01 a1 | 0x02 | 01 a2 | * 01 a2 | 01 a2 | 01 a2 |
0x04 | 02 a1 a2 a3 | 02 a1 a2 a3 | * 02 a1 a2 a3 | 02 a1 a2 a3 | 0x08 | 99 | 99 | 99 | * 99 | ... 0xa1 | 00 | 03 | 03 | 03 | 0xa2 | 00 | 00 | 04 | 04 | 0xa3 | 00 | 00 | 00 | 07 |

In questo esempio, l'asterisco ( * ) punta al successivo codice operativo che verrà eseguito. La colonna più a sinistra specifica la posizione di memoria iniziale per quella riga. Quindi, ad esempio, la seconda riga ci mostra due byte di memoria (con valori 01 e a2 ) nelle posizioni 0x02 (esplicitamente nella colonna di sinistra) e 0x03.

(Per favore, comprendi che questa è tutta una grande semplificazione. Ad esempio, in un vero computer la memoria può essere intercalata - non avrai solo un pezzo di istruzioni e un pezzo di tutto il resto. dovrebbe essere abbastanza buono per questa risposta, però.)

Nota che mentre eseguiamo il programma, la memoria nelle aree 0xa1 - 0xa3 cambia, ma la memoria in 0x00 - 0x08 no. I dati in 0x00 - 0x08 sono l'eseguibile del nostro programma, mentre la memoria nelle aree 0xa1 - 0xa3 è la memoria che il programma usa per fare il crunch dei numeri.

Quindi, per tornare al tuo esempio: i dati nel tuo jpeg verrà caricato nella memoria dagli opcode e sarà manipolato dagli opcode, ma non sarà caricato nella loro stessa area in memoria. Nell'esempio sopra, i due valori 0x03 e 0x04 non erano mai nell'area del codice operativo, che è ciò che esegue la CPU; erano solo nell'area da cui leggono e scrivono i codici operativi. A meno che tu non abbia trovato un bug (come un buffer overflow) che ti consente di scrivere dati in quello spazio del codice operativo, le tue istruzioni non verranno eseguite; saranno solo i dati che vengono manipolati dall'esecuzione del programma.

La tua risposta è nella migliore delle ipotesi parzialmente corretta.A parte la semplificazione che tutti i dati devono risiedere nello "stack", è un presupposto sbagliato che la manipolazione dei dati sullo stack non possa essere utilizzata per l'esecuzione di codice arbitrario.
@JimmyB Dice letteralmente che si tratta di una grande semplificazione, e la domanda non sta parlando di exploit, ma solo di inserire codice in un'immagine.La risposta fa un buon lavoro nel spiegare in termini semplici perché il codice inserito in un'immagine non verrà semplicemente eseguito.
@Blackhawk: Quasi tutto ciò che riguarda lo stack è sbagliato.È un po 'vagamente simile a come funzionano le architetture [stack machine] (https://en.wikipedia.org/wiki/Stack_machine), ma la maggior parte dei computer moderni non utilizza un'architettura di stack machine, e anche le macchine stack usano lo stack comeun terreno di ritenzione temporaneo per gli ingressi e le uscite delle istruzioni, non come dove vengono conservati tutti i dati.(Lo stack di chiamate utilizzato nelle moderne architetture di computer è una cosa diversa e quello stack non funziona come descritto in questa risposta.)
Inoltre, i buffer overflow generalmente sovrascrivono cose come gli indirizzi di ritorno, non la memoria eseguibile.
Sebbene la parte "no a meno che non si sfrutti un bug" sia corretta, questa risposta include molti, molti dettagli non necessari e * sbagliati * che la fanno sembrare più informativa a un lettore inesperto, ma in realtà rende la risposta peggiore di quella breve ma correttarisposte che non sono state accettate.
@user2357112 Stavo cercando di inventare un piccolo "giocattolo VM", ma penso che tu abbia ragione sul fatto che si è sacrificato troppo e non ha semplificato abbastanza.Mi sono sbarazzato delle menzioni dello stack.Fatemi sapere cosa ne pensate.
(Ho omesso le discussioni sui registri e simili, però - non credo che aggiungerebbero molto a ciò che chiede l'OP.)
Cosa direbbe von Neumann?
Probabilmente sarebbe molto più semplice dire "I dati vengono eseguiti solo se il registro IP viene cambiato nell'indirizzo dei dati in memoria" piuttosto che passare attraverso tutto questo.
@forest Penso che funzionerebbe principalmente se qualcuno avesse già molte di queste conoscenze.Stavo cercando di prendere di mira qualcuno che capisse che il programma vive nella memoria, e anche i dati dell'immagine, ma non capisce come vengono tenuti distinti.Personalmente trovo utile fornire un esempio concreto, anche se semplificato, anche se capisco perfettamente che altre persone pensano che non funzioni.:)
@Blackhawk Questa è "prova dell'autorità", quanto sopra è "bugie raccontate ai bambini".Le bugie raccontate ai bambini hanno valore.
Dovrebbe esserci un pulsante per spostarlo in chat, se vuoi farlo.
@yshavit Penso che dovresti rimuovere l'affermazione "Sebbene sia vero che le istruzioni ei dati su cui operano sono entrambi in memoria, sono in parti diverse della memoria."perché nel migliore dei casi è fuorviante e nel peggiore dei casi è semplicemente sbagliato.
@JimmyJames Sono in luoghi concettuali diversi.È vero che i due spazi sono fisicamente intervallati, ma il punto che stavo cercando di trasmettere è che sono trattati come diversi, e infatti quando non vengono trattati accidentalmente come diversi, questo è un bug.Cosa ne pensi di modificarlo in "sono in parti concettualmente separate della memoria"?
@yshavit Meglio?È un concetto difficile da spiegare senza comprendere il modo in cui viene eseguito il codice macchina.Il modo succinto in cui direi è qualcosa del tipo: "i dati vengono eseguiti come istruzioni solo quando un processo in esecuzione li interpreta in quel modo".
Ma i sistemi moderni sono architettura Von Neumann, non architettura Harvard, quindi non è altro che un bit di esecuzione che determina se una pagina è eseguibile, non dove vive in memoria (ignorando il fatto che le CPU x86 sono Harvard internamente, cosa con L1d e L1i separaticache).
@forest: x86 ha i-cache coerente (a differenza di molte altre architetture che richiedono insns di flush / sync espliciti prima di poter eseguire in modo affidabile byte di codice macchina appena memorizzati), quindi da un software PoV moderno x86 è puro von Neumann.[Osservazione del recupero delle istruzioni obsolete su x86 con codice di auto-modifica] (https://stackoverflow.com/q/17395557).E a proposito, le cache L1 divise per uno spazio di indirizzi unificato sono generalmente descritte come un'architettura di Harvard modificata, della varietà quasi von-Neumann.https://en.wikipedia.org/wiki/Modified_Harvard_architecture#Split-cache_(or_almost-von-Neumann)_architecture
@PeterCordes Sì, so che è un'architettura di Harvard modificata, ma è invisibile all'ISA.
@forest: sì, invisibile nell'ISA è esattamente quello che stavo dicendo anch'io.:) (Beh tecnicamente, su carta x86 è consentito eseguire istruzioni obsolete fino a jmp / branch, ma le implementazioni hardware effettive scelgono di essere più forti dell'ISA cartaceo perché in realtà è più facile che essere * esattamente * forte come la specifica ma mai più debole. Questo è ciò di cui parla la risposta di Andy Glew sulla domanda e risposta collegata. (Andy è stato uno degli architetti dell'uarch P6 di Intel). Anche nel tuo commento precedente hai tralasciato il "Modificato", e mi sentivo pedante.: P Non modificatoHarvard implica spazi di indirizzi separati.
Joseph Sible-Reinstate Monica
2018-10-29 06:51:35 UTC
view on stackexchange narkive permalink

Puoi inviarli? Sì, naturalmente. Basta assemblarli e incollarli da qualche parte nel file immagine.

Il target li eseguirà? No, a meno che tu non abbia già il controllo sulla destinazione (e puoi quindi mettere un programma lì per leggerli ed eseguirli), o trovi qualche exploit in un visualizzatore di immagini e fai caricare l'immagine al suo interno.

La CPU non dovrebbe eseguire le istruzioni aprendo solo l'immagine?
No, perché dovrebbe?
Perché la CPU dovrebbe elaborare quelle informazioni, da quello che ho capito.
L'elaborazione di byte di dati è diversa dall'esecuzione di tali byte.Uno non implica l'altro.
Non è tutto byte alla fine?
Sì, ma alcuni byte vengono eseguiti e altri vengono trattati come dati.
Capisco, e solo così posso capirlo: chi ne è responsabile?il sistema operativo che tratta i file jpg come dati, invece di eseguibili?
@Faminha102 Se camminassi fuori e incappassi su un pezzo di carta con alcune istruzioni su di esso, seguiresti quelle istruzioni?Probabilmente no.Potresti ancora leggere e comprendere quelle istruzioni, ma non agiresti in base a esse perché sai che non sono destinate a te.Un'idea simile si applica qui.
@Faminha102: Proprio come nell'analogia di tlng05, è tutto sul contesto impostato dal codice attualmente in esecuzione.Se il programma che legge un file esegue istruzioni che ne interpreteranno il contenuto come una matrice di punti colorati e visualizzeranno l'immagine risultante, questo è ciò che accadrà (o il programma potrebbe fallire su dati mal formati);se il programma esegue istruzioni che interpreteranno i dati del file come altre istruzioni e le eseguirà, questo è ciò che accadrà (a meno che, di nuovo, la sequenza di istruzioni risultante sia mal formata).
@Faminha102 sì, se un file è determinato come eseguibile o meno dipende interamente dal sistema operativo.I file vengono interpretati dai programmi e puoi avere un file interpretato in più modi.Un esempio comune sono i programmi di installazione che possono essere eseguiti come programmi o aperti come file ZIP.
Alcuni byte vengono forniti al computer per l'esecuzione.Altri no.È davvero così semplice.Se metti i tuoi byte in un file eseguibile e convinci l'utente del computer a eseguirlo, il sistema operativo passerà quei byte alla CPU per l'esecuzione e via.Se lo fa per le immagini JPEG, c'è qualcosa che non va.
L'idea sbagliata qui potrebbe derivare dall'osservazione che il doppio clic su un'immagine * visualizza * ("avvia") l'immagine, proprio come il doppio clic su un eseguibile avvia l'eseguibile.
Quando in realtà, ciò che accade quando fai doppio clic su un'immagine, è che il tuo sistema operativo esegue l'eseguibile associato a quel particolare tipo di file, in base all'estensione del file, e passa semplicemente il percorso del file come argomento.
@Faminha102 Se aiuta, i byte dell'immagine non vengono semplicemente alimentati attraverso la CPU.Se la CPU riceve un set o byte che le istruiscono a fare qualcosa, leggerà uno per uno quei byte di istruzione e farà come indicato.Nel caso di caricamento di un'immagine, potrebbe iniziare copiando ogni byte dell'immagine dal disco alla memoria.I byte dell'immagine non passeranno attraverso la CPU.Il disco verrà istruito a caricare ogni byte dell'immagine sul bus e quindi la memoria verrà istruita a caricare i byte dal bus.Questa è una semplificazione grossolana, ovviamente, ma si spera che aiuti a capire l'idea generale.
Non dovrebbe, ovviamente, ma c'erano (sono?) [Vulnerabilità] (https://docs.microsoft.com/en-us/security-updates/vulnerabilityresearchadvisories/2012/msvr12-004) che possono causare un JPEGessere giustiziato.Perché sulla Terra stai scrivendo una libreria di immagini in un modo che può causare questo è al di là di me, però.
Robyn
2018-10-29 15:50:02 UTC
view on stackexchange narkive permalink

Potresti farlo se il tuo target usasse una versione di Internet Explorer precedente all'agosto 2005 per visualizzare un JPG. O se stavano per aprire un PNG in Windows Media Player su Windows 98 senza aggiornamenti di sicurezza installati. E così via.

C'erano molti vecchi software che avevano dei bug in cui, se si creava un file immagine in cui la prima parte del file immagine mentiva in modo oltraggioso sulla dimensione e la posizione del pixel dati nel file, il software potrebbe fare qualcosa di sbagliato e saltare accidentalmente al codice all'indirizzo sbagliato o scrivere dati dal file in un punto in cui dovrebbe essere il codice del programma. Ricordo che uno di questi hack riguardava un file la cui intestazione sosteneva che l'immagine avesse dimensioni negative. Probabilmente non puoi farlo con le versioni più recenti di Internet Explorer o Edge, perché ora tutti conoscono il problema e Microsoft ha fatto del suo meglio per risolverlo.

I sistemi operativi odierni hanno alcune misure protettive in atto per rendere difficile (ma non del tutto impossibile) ottenere qualcosa di veramente brutto se trovi un nuovo modo per hackerare un programma usando un metodo come questo. È possibile impostare aree di memoria in modo che non possano essere eseguite. I programmi hanno spazi di indirizzi virtuali separati in modo che non possano accedere accidentalmente alla memoria reciproca. Alcuni componenti del sistema operativo vengono caricati in posizioni di memoria imprevedibili, quindi non è semplice per il codice dannoso trovarli e utilizzarli.

Ulteriori dettagli: https://security.stackexchange.com/questions/97856/can-simply-decompressing-a-jpeg-image-trigger-an-exploit
L'eminente blogger tedesco [Felix von Leitner] (https://blog.fefe.de/) sottolinea spesso che, paradossalmente, gli * scanner antivirus * espongono enormi superfici di attacco perché devono essere in grado di aprire tutti i formati di file mentre vengono eseguiti con i massimi diritti.Quindi non devi nemmeno aprire il JPEG;potrebbe essere sufficiente se il programma antivirus tenta di scansionarlo in background.
Esattamente.I file JPEG hanno sicuramente computer infetti.Una ricerca su Google proprio ora per * jpeg malware * ha restituito [questo sito che lo spiega] (https://www.bullguard.com/blog/2018/01/jpeg-files-and-malware).
Le vulnerabilità in alcuni software esistevano almeno fino al 2012: https://docs.microsoft.com/en-us/security-updates/vulnerabilityresearchadvisories/2012/msvr12-004
Daisetsu
2018-10-29 06:55:30 UTC
view on stackexchange narkive permalink

No. I file immagine come i file JPEG non eseguono codice, vengono semplicemente renderizzati e visualizzati.

Se vuoi nascondere alcune informazioni in un file chiamato Steganography, ma che nasconde solo informazioni, non lo fa eseguire qualsiasi istruzione.

Affinché un file possa eseguire codice deve essere un eseguibile o essere eseguito da un altro programma che legge il file, quindi esegue i comandi nel file.

In questo caso, il raro caso in cui un'immagine potrebbe provocare l'esecuzione del codice è se ci fosse un bug nel software che ha reso l'immagine in base al file. Questo è successo in passato, ma è estremamente raro. Per tutti gli scopi pratici un'immagine non può eseguire istruzioni.

Questo ovviamente non è il caso di PDF, Adobe Flash, ecc.

Interessante.Quindi con i PDF questo andrebbe bene, è quello che stai dicendo?
I PDF hanno più funzionalità, possono essere interattivi, caricare risorse esterne, incorporare altri file, ecc. Tuttavia non sono pericolosi come i file Word / Execl.
Potresti approfondire di più?
Elaborare di più su cosa?Un attacco in stile cavallo di troia si basa su un file dall'aspetto innocente che contiene un payload dannoso (macro di parole, file eseguibili, javascript) OPPURE viene letto da un parser vulnerabile.Questo secondo caso è piuttosto raro e riceve molta attenzione perché interesserebbe così tante persone.C'è un esempio che probabilmente conosci, che è Flash.Flash ha aggiornamenti di sicurezza costanti, perché cerca di fare così tanto, ci sono molti modi per creare un file che si traduce in (a volte) l'esecuzione di codice arbitrario.
@Faminha102 PDF è diverso perché il moderno formato di file PDF è progettato per eseguire javascript incorporato (simile a come fanno i file HTML).Ma l'utente deve aprire il file PDF
_ "I file immagine come i file JPEG non eseguono codice" _: lo trovo un po 'impreciso.Anche la maggior parte dei file eseguibili non eseguono codice, vengono eseguiti.
@phresnel è corretto.Probabilmente potresti creare un file che quando viene aperto come immagine JPEG mostra un'immagine (brutta) e quando viene eseguito come codice fa qualcosa di dannoso.
Per espandere il commento di @phresnel, * no * file eseguono codice, i programmi eseguono codice.I sistemi operativi hanno programmi associati alle estensioni di file.Quando si fa doppio clic su un file, viene eseguito il programma associato a tale estensione e tale programma aprirà il file.Se apri un file con un programma che esegue solo il rendering delle immagini, non verrà eseguito alcun codice nel file, indipendentemente dal contenuto.
@Captian Man, per fare in modo che un file venga eseguito direttamente (senza essere invocato da un altro processo che ne interpreterebbe le istruzioni) un programma deve essere un eseguibile binario (binario ELF per Linux, PE per Windows).Non puoi semplicemente prendere un binario e creare un file JPEG valido.Le intestazioni per JPEG e PE / ELF non si allineano.
@Daisetsu: Ma se hai un programma divertente "JpegExecuter" che carica i JPEG in memoria e interpreta i colori come istruzioni, allora quel file può essere eseguito.Proprio come posso eseguire i binari di Windows in formato .COM o .EXE su una macchina Linux, dato un programma divertente chiamato Wine.O .NET.Non eseguibile senza host.Questa discussione può diventare enorme, in realtà;cosa significa effettivamente "eseguire un file direttamente"?Anche il formato binario (probabilmente) più grezzo .COM deve essere caricato prima di essere interpretato dalla CPU e digerito nel microcodice.
Btw, http://www.dangermouse.net/esoteric/piet/samples.html
@phresnel chiunque può scrivere un programma per interpretare un file in un modo che non segue gli standard di formato (JPEG).Ma non è un caso realistico.La domanda riguardava i normali file JPEG, resi ostensibilmente dai normali programmi grafici.
Sì, ma questo non rende "I file JPEG non eseguono codice" più accurato di "I file EXE non eseguono codice".
rackandboneman
2018-10-30 17:39:35 UTC
view on stackexchange narkive permalink

Puoi, SE sai anche quale stack software toccherà l'immagine sul lato ricevente E SE ci sono vulnerabilità di sicurezza irrisolte in quello stack software.

Il semplice inserimento delle istruzioni nel file JPEG non fa nulla.

Tuttavia, se esiste un modo noto per far sì che una certa implementazione esatta del lettore JPEG si blocchi in un modo su un file JPEG non valido che copierà i dati dal file immagine a cui quei dati non appartengono (come, in cima a variabili che contengono informazioni sul flusso di controllo del programma come puntatori a funzione o indirizzi di ritorno), e se le contromisure a livello di sistema operativo o hardware (ad esempio DEP) non si fermano che dal momento che accada, c'è una possibilità realistica. Tali vulnerabilità sono esistite (ed esistono in legacy) implementazioni del mondo reale.

John U
2018-11-01 19:48:36 UTC
view on stackexchange narkive permalink

La versione breve è no, perché i computer (DOVREBBE) conoscono la differenza tra dati e istruzioni. Il peggio che DOVRESTI essere in grado di fare con un JPEG è qualcosa come una zip-bomb o qualcosa che blocca alcune routine di decompressione JPEG. Un programma per caricare & mostra un JPEG non tenterà di eseguire nessuno dei dati nel file, ma solo di leggerlo ed elaborarlo - e se colpisce alcuni dati inaspettatamente non jpeg si fermerà o si bloccherà, o mostrerà semplicemente un immagine davvero incasinata.

TUTTAVIA, a volte (ti sto guardando, Microsoft) le persone cercano di scrivere software utile che può essere vulnerabile (ad esempio) tentando di caricare automaticamente & visualizzare allegati di posta elettronica , creare formati di documenti che possono contenere script / macro, ecc. ed è qui che un file dannoso può causare danni.

L'esempio classico (e ora si spera defunto / protetto contro) sono gli allegati di posta elettronica chiamati qualcosa come .jpg.exe dove il file è realmente un eseguibile e Windows lo tratterà come tale, ma poiché Windows nasconde l'estensione (nascondendo l'ultima parte .exe) le persone vedi file.jpg e fai clic su di esso, facendo in modo che il sistema operativo lo esegua.

È la differenza tra leggere un libro e recitare o ut il contenuto del libro - se il libro dice "vai a prendere a pugni qualcuno" non lo farai, perché le parole (dati) nel libro non controllano il tuo cervello anche se il tuo cervello elabora quei dati.



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