La tua domanda può essere letta in due modi, DarkCoffee:

Se un particolare dispositivo basato su Arduino può essere indotto a sovraccaricare il suo stack, può essere sfruttato?

Sì, lo è possibile sfruttare uno stack overflow su un Arduino.

Un possibile attacco è il metodo di programmazione orientata al ritorno, che richiede un firmware sufficientemente complesso. Quindi, una difesa qui è mantenere il firmware il più semplice possibile. È altamente improbabile che l ' schizzo "hello world" di Arduino sia vulnerabile. Che non dovrebbe essere molto conforto per voi, però, perché un lampeggiatore LED non è molto utile . Un firmware utile avrà più funzioni, e quindi più code di funzioni da raccogliere per l'uso in una macchina astratta.

Arduino ha anche un boot loader, che ha intrinsecamente il potere di sovrascrivere il firmware. Potrebbe essere possibile sfruttarlo per sovrascrivere il firmware benigno ma vulnerabile esistente con firmware maligno.

La mia lettura della prima pagina del documento sull'attacco INRIA mi porta a credere che combini entrambi approcci: programmazione orientata al ritorno per eseguire codice sufficiente per attivare la capacità di auto-lampeggiamento del microcontrollore in modo che il codice arbitrario possa essere caricato in modo permanente.

Esistono attacchi di overflow dello stack su Arduino in generale?

Non sono a conoscenza di alcun attacco che funzioni su tutti i dispositivi basati su Arduino. Di nuovo, lo schizzo del lampeggiatore LED "ciao mondo" è probabilmente invulnerabile, semplicemente perché è troppo banale per essere vulnerabile.

Più codice scrivi, più è probabile che creerai una vulnerabilità.

Nota che scrivere 5.000 righe di codice e poi sostituire 2 kLOC con 1.000 nuove righe non è un risparmio netto di 1 kLOC dal punto di vista della sicurezza. Se quei 5 kLOC erano sicuri e hai sbagliato durante la scrittura di alcuni dei nuovi 1 kLOC, è ancora una vulnerabilità. La morale della storia è che il codice più sicuro tende ad essere quello che viene fissato più a lungo, e questo significa mantenerlo invariato il più a lungo possibile.

Ovviamente, ogni vulnerabilità dovrebbe essere corretta il prima possibile. Questo non è un argomento per mantenere le vecchie vulnerabilità in giro. È un argomento contro l'aggiunta sconsiderata di funzionalità al codice che ritieni sicuro attraverso l'ispezione, il controllo e l'analisi.

La cosa importante è che non possiamo rispondere a questa domanda con "no" con qualcosa di vicino alla certezza assoluta, a meno che non verifichiamo formalmente un dato sistema Arduino, come distribuito, istruzione per istruzione e anche allora.

Gli Arduino hanno interfacce ethernet opzionali e altre forme di comunicazione remota, quindi gli exploit remoti sono possibili concettualmente. Esiste uno stack TCP per l'internetworking e, anche se è piccolo e semplice, potrebbe avere dei difetti.

Ma, in particolare, sono possibili overflow del buffer dello stack? Considera che Atmel I processori AVR hanno un'architettura Harvard, il che significa che codice e dati risiedono in spazi di memoria separati . Ciò tende a escludere gli exploit in cui il codice viene iniettato nello stack e successivamente eseguito. Un indirizzo inserito nello stack da un vettore di attacco verrà interpretato come se fosse nello spazio del codice, mentre i byte del vettore di attacco rimanenti contenenti il ​​payload dannoso si trovano nello spazio dei dati.

Se guardi ciò che normalmente viene sfruttato nei sistemi x86, cioè, heap overflow, stack overflow, seh sovrascrive, stringhe di formato ecc., non c'è una superficie di attacco così grande. Con la possibile eccezione delle stringhe di formato, non vedo nessuno di questi attacchi funzionante poiché l'architettura semplicemente non lo consente.

Se sei interessato a questo tipo di ricerca, ti consiglio di guardare l'orologio e glitch di tensione, questo spesso consente di estrarre informazioni dai dispositivi anche quando sono bloccati e semplicemente di disturbarli in generale. Puoi anche provare l'analisi della potenza differenziale se sei all'altezza delle statistiche. Infine, gli attacchi a tempo sono probabilmente i più facili da sfruttare se stai cercando qualcosa con cui iniziare.

Sul lato hardware c'è un programma chiamato degate che consente di invertire i chip a livello di silicio. Ci sono stati un paio di discorsi decenti sull'argomento e probabilmente li adorerai.

Non c'è davvero nulla da sfruttare su un processore integrato come ATmega (utilizzato su Arduino) poiché c'è solo un livello di esecuzione (accesso completo) e niente cose fantasiose come l'anello CPU Intel / AMD protezione (mantenendo il codice utente lontano dal codice del kernel nell'hardware).

Se colleghi un debugger ottieni pieno accesso a RAM e flash, quindi non c'è bisogno di sfruttare nulla, davvero ...

Gli exploit del buffer con l'intento di controllare tramite l'incisione del codice funzionano solo contro l'architettura di Princeton, perché l'archiviazione dei dati e l'archiviazione del programma condividono la stessa memoria.

Ora il nostro piccolo e coraggioso Atmel ha un'architettura di Harvard: esegue codice da una memoria diversa dai dati. E il nostro buffer overflow abilmente sfruttato può solo scrivere su SRAM, che non può essere eseguito.

Potrebbe mandare in crash Arduino, però, se hai un modo per trasferire i dati nel buffer.

Come ha sottolineato Madmanguruman, non c'è davvero nulla da sfruttare su un processore incorporato, in un certo senso. La vera domanda è PERCHÉ vuoi sfruttare un dispositivo embedded? Se avessi un Ardunio autonomo e potessi sfruttare qualcosa, cosa potresti farci?

Nei PC moderni, molto spesso lo sfruttamento di una vulnerabilità ti darà accesso root remoto, che è praticamente l'obiettivo finale. Ma un sistema integrato di solito non ha file, informazioni o qualcosa di simile, sebbene ci siano delle eccezioni.

Se vuoi sfruttare un sistema integrato, di solito è per uno scopo specifico. Inoltre, l'exploit sarà completamente unico quasi ogni volta. Inoltre, la maggior parte dei dispositivi incorporati non verrà collegata; il che significa che hai bisogno di un accesso fisico a loro per fare qualsiasi cosa. E una volta che hai accesso fisico, hai in mano tutte le carte e tutto può essere fatto. Questo è uno dei rari aspetti dell'ingegneria che sta effettivamente cercando di trovare una soluzione a un problema, non il contrario.