Se conosco l'architettura CPU di un target, posso inviare istruzioni incorporate in un'immagine?

Le istruzioni della CPU sono fornite in quelli che sono chiamati opcodes , e hai ragione che quelli vivono in memoria proprio come il tuo Immagine. Vivono in "aree" di memoria concettualmente diverse, però.

Ad esempio, si potrebbe immaginare un codice di lettura "read" (0x01) che legge un byte di input da stdin e lo mette da qualche parte, e un altro operando "add" (0x02) che aggiunge due byte. Alcuni opcodes possono accettare argomenti, quindi daremo alcuni esempi opcode: l'opcode "read" accetta un operando per dove memorizzare il byte che legge, e "add" uno prende tre operandi: due per dove leggere i suoi input e uno per dove scrivere il risultato.

0x01 a1 // read a byte to memory location 0xa1
0x01 a2 // read a byte to memory location 0xa2
0x02 a1 a2 a3 // read the bytes at locations 0xa1 and 0xa2, add them,
              // and write the result to location 0xa3

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

Anche se è 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ò accada. Quando falliscono, puoi infatti caricare i dati nello spazio di esecuzione ed è un grave problema di sicurezza. I buffer overflow sono probabilmente l'esempio più famoso di un tale bug. Ma oltre a questi tipi di bug, puoi essenzialmente pensare allo spazio dei dati e allo spazio di esecuzione come blocchi separati di CPU.

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

(loc)  | Initial      | After op 1   | After op 2   | After op 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 prossimo codice operativo che verrà eseguito. La colonna più a sinistra specifica la posizione di memoria iniziale per quella linea. Quindi, per 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.

(Si prega di capire che questa è una grande semplificazione: per esempio, in un vero computer la memoria può essere interlacciata - non si avrà solo una porzione di istruzioni e una parte di tutto il resto. abbastanza per questa risposta, però.)

Si noti 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 eseguibili del nostro programma, mentre la memoria nelle aree 0xa1 - 0xa3 è la memoria utilizzata dal programma per eseguire il crunch del numero.

Quindi, per tornare al tuo esempio: i dati nel tuo jpeg verranno caricati nella memoria da opcodes e saranno manipolati da opcodes, ma non verranno caricati nella loro stessa area in memoria. Nell'esempio sopra, i due valori 0x03 e 0x04 non erano mai nell'area opcode, che è ciò che viene eseguito dalla CPU; erano solo nell'area in cui gli opcode leggevano e scrivevano. A meno che tu non abbia trovato un bug (come un buffer overflow) che ti permette di scrivere dati in quello spazio opcode, le tue istruzioni non verranno eseguite; saranno solo i dati che vengono manipolati dall'esecuzione del programma.

Altre risposte danno una buona spiegazione tecnica, ma lasciatemi provare con un'analogia:

Please send your credit card number to [email protected]

• L'hai letto?

• L'hai fatto?

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

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

Il bersaglio li eseguirà? No, a meno che tu non abbia già il controllo sul target (e quindi puoi mettere lì un programma per leggerlo ed eseguirlo), o trovare qualche exploit in un visualizzatore di immagini e caricare l'immagine in esso.

Potresti se il tuo target utilizzava una versione di Internet Explorer da prima di 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'era un sacco di vecchi software che avevano bug in cui, se creavi un file immagine in cui la prima parte del file immagine mentiva in modo oltraggioso sulla dimensione e la posizione dei dati dei pixel nel file, il software poteva fare qualcosa di sbagliato e saltare accidentalmente al codice all'indirizzo sbagliato o scrivere i dati dal file in un posto dove dovrebbe essere il codice del programma. Ricordo che uno di questi ha coinvolto un file la cui intestazione sosteneva che l'immagine aveva una dimensione negativa. Probabilmente non puoi farlo con versioni più recenti di Internet Explorer o Edge, perché tutti ora conoscono il problema e Microsoft ha fatto del suo meglio per risolverlo.

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

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

Se vuoi nascondere alcune informazioni in un file che si chiama Steganography, ma che nasconde solo informazioni, non esegue alcuna istruzione.

Affinché un file esegua il 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, la rara istanza in cui un'immagine potrebbe causare l'esecuzione di un codice è se ci fosse un bug nel software che rendeva l'immagine basata sul file. Questo è successo in passato, ma è estremamente raro. Per tutti gli scopi pratici, un'immagine non può eseguire istruzioni.

Questo naturalmente non è il caso per PDF, Adobe Flash, ecc.

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.

Semplicemente inserendo le istruzioni nel file JPEG non fa nulla.

Tuttavia, se esiste un modo noto per far sì che una determinata implementazione di un lettore JPEG si arresti in modo anomalo su un file JPEG non valido in modo che copi i dati dal file immagine a cui tali dati non appartengono (ad esempio, sopra le variabili che contengono informazioni sul flusso di controllo del programma come i puntatori di funzione o gli indirizzi di ritorno) e se le contromisure OS o di livello hardware (es. DEP) non impediscono che ciò accada, c'è una possibilità realistica. Tali vulnerabilità sono esistite in (e esistono in legacy) implementazioni del mondo reale.

Ecco qualcosa da immaginare: se fosse davvero vero che un computer aveva bisogno di eseguire il codice macchina all'interno di un'immagine per visualizzarlo, tutto ciò che facciamo con le immagini digitali sarebbe suck .

• Per visualizzare un'immagine sul Web, dovresti avere un file immagine diverso per ogni singola architettura su cui desideri visualizzare l'immagine. Non dovresti solo coprire quelli comuni come x86, x64 e ARM, ma anche quelli potenzialmente più oscuri che potrebbero ancora visualizzare il tuo sito web come PowerPC e MIPS. Alcuni computer hanno la stessa architettura ma diverse convenzioni di chiamata (ad esempio x64 di Windows vs x86_64 di Linux), quindi è necessario tenere conto anche di questi. Non solo, ma la maggior parte dei PC reagisce in modo catastrofico se impostata per eseguire codice scritto per un'altra architettura, quindi dovresti concordare su uno standard in base al quale il codice per le diverse architetture di immagini potrebbe identificarsi correttamente (e aspettarti che le immagini rispettino correttamente quella ).
• Con questo in mente, non è più possibile trasferire le immagini tra i sistemi. Quasi tutti gli utenti non sarebbero in grado di inviare le foto scattate sul proprio telefono a un PC, soprattutto attraverso qualcosa come una scheda SD, e gli utenti Android non sarebbero in grado di inviare immagini agli utenti iOS, o viceversa. Se volevi inviare le immagini, dovresti convertirle dall'architettura del mittente all'architettura del ricevitore, che in effetti risulta essere un problema davvero difficile su alcune coppie di architetture.
• Alcuni sistemi operativi sono piuttosto permissivi sulla sicurezza dell'esecuzione (leggi: Windows XP), ma altri sistemi operativi sono costruiti sull'idea di fornire solo autorizzazioni specifiche agli eseguibili su quali risorse possono utilizzare. Android, ad esempio, ti mostra una finestra di dialogo delle autorizzazioni che ti dice esattamente quali parti del tuo telefono ha bisogno di accedere a un'applicazione prima di eseguirla - se Android ha bisogno di eseguire il codice nelle immagini per visualizzarle, otterresti la stessa finestra di dialogo delle autorizzazioni per ogni immagine su ogni sito web che hai mai trovato, e dovresti accettare queste autorizzazioni prima ancora di poter vedere quale sarebbe stata l'immagine (non potevi nemmeno mostrare un'anteprima, dato che avrebbe dovuto anche eseguire codice).
• E, naturalmente, quel codice probabilmente finirebbe con bug che causano la mancata visualizzazione dell'immagine o del tutto. Ad esempio, un semplice errore nella logica del programma potrebbe causare il caricamento dell'immagine in modo permanente e senza progresso.

Come ben spiegato dalle altre risposte, mentre un'immagine può certamente avere il codice macchina incorporato nei dati, non viene mai eseguito alcun codice macchina all'interno dell'immagine per poter visualizzare l'immagine. Un buon modo per pensarci è che, mentre, sì, un programma fa deve essere eseguito per mostrare un'immagine sullo schermo, quel programma è esattamente lo stesso per ogni immagine (dello stesso formato) il computer si imbatte mai - elabora solo dati diversi ogni volta. Pertanto, il file immagine si limita a includere la parte di dati e si aspetta che il computer visualizzandolo abbia già la parte del programma a disposizione - e quella parte del programma sarà sicuramente scritta nell'architettura del computer e speriamo che faccia la cosa giusta senza errori o inganno dannoso.

La versione breve è no, perché i computer (DOVREBBE) conoscere la differenza tra dati e istruzioni. La cosa peggiore che dovresti fare con un JPEG è qualcosa come una bomba a zip o qualcosa che blocca alcune routine di decompressione JPEG. Un programma per caricare & visualizzare un JPEG non tenterà di ESEGUIRE nessuno dei dati nel file, solo leggerlo ed elaborarlo - e se colpisce alcuni dati non-jpeg inaspettatamente si fermerà o si bloccherà, o mostrerà solo un'immagine veramente incasinata.

TUTTAVIA, a volte (sto guardando te, Microsoft) le persone provano e scrivono software utile che può essere vulnerabile (ad esempio) cercando di caricare automaticamente & visualizza allegati di posta elettronica, crea formati di documenti che possono contenere script / macro, ecc. ed è qui che un file dannoso può causare danni.

L'esempio classico (e ormai spero defunto / protetto contro) è l'allegato di e-mail chiamato qualcosa come .jpg.exe dove il file è veramente un eseguibile e Windows lo tratterà come tale, ma poiché Windows nasconde l'estensione (nascondendo l'ultima parte .exe) le persone visualizzano file.jpg e fanno clic su di esso, facendo in modo che il sistema operativo lo esegua.

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