Tu pregunta se puede leer de dos maneras, DarkCoffee:

Si un dispositivo en particular basado en Arduino puede ser inducido a desbordar su pila, ¿puede ser explotado?

Sí, es posible explotar un desbordamiento de pila en un Arduino.

Un posible ataque es el método programación orientada al retorno , que requiere un firmware suficientemente complejo. Entonces, una defensa aquí es mantener su firmware lo más simple posible. Es altamente improbable que el croquis de "Hola mundo" de Arduino sea vulnerable. Sin embargo, eso no debería ser muy cómodo para usted, porque un parpadeo con LED no es terriblemente útil . El firmware útil tendrá más funciones y, por lo tanto, más colas de funciones para recopilar para usar en una máquina abstracta.

El Arduino también tiene un cargador de arranque, que inherentemente tiene la capacidad de sobrescribir el firmware. Puede ser posible explotarlo para sobrescribir el firmware existente benigno pero vulnerable con el firmware maligno.

Mi lectura de la primera página del el documento de ataque de INRIA me hace creer que combina ambos enfoques: programación orientada hacia el retorno para ejecutar código suficiente para activar la capacidad de parpadeo automático del microcontrolador para que se pueda cargar permanentemente un código arbitrario.

¿Hay ataques de desbordamiento de pila en Arduinos en general?

No tengo conocimiento de ningún ataque que funcione en todos los dispositivos basados en Arduino. Una vez más, el boceto de luces intermitentes LED "hola mundo" es probablemente invulnerable, simplemente porque es demasiado trivial para ser vulnerable.

Cuanto más código escriba, más probable es que cree una vulnerabilidad.

Tenga en cuenta que escribir 5,000 líneas de código y luego reemplazar 2 kLOC con 1,000 líneas nuevas no es un ahorro neto de 1 KLOC desde un punto de vista de seguridad. Si esos 5 kLOC eran seguros y se equivocó al escribir algunos de los nuevos 1 kLOC, todavía es una vulnerabilidad. La moraleja de la historia es que el código más seguro tiende a ser el que se mira por más tiempo, y eso significa mantenerlo sin cambios el mayor tiempo posible.

Obviamente, todas las vulnerabilidades deben parchearse lo antes posible. Este no es un argumento para mantener viejas vulnerabilidades alrededor. Es un argumento en contra de agregar características irreflexivas al código que usted cree seguro mediante inspección, auditoría y análisis.

Lo importante es que no podemos responder a esta pregunta con un "no" con certeza absoluta, a menos que verifiquemos formalmente un sistema Arduino determinado, como se implementó, instrucción por instrucción, e incluso entonces.

Los arduinos tienen interfaces Ethernet opcionales y otras formas de comunicación remota, por lo que las explotaciones remotas son posibles en concepto. Hay una pila TCP para interconexión de redes, e incluso si es pequeña y simple, podría tener fallas.

Pero, específicamente, ¿son posibles los desbordamientos del búfer de pila? Considere que los procesadores AVR de Atmel tienen una arquitectura de Harvard, lo que significa que el código y los datos residen en espacios de memoria separados . Eso tiende a descartar los exploits donde el código se inyecta en la pila y se ejecuta posteriormente. Una dirección colocada en la pila por un vector de ataque se interpretará como que está en el espacio de código, mientras que los bytes restantes del vector de ataque que contienen la carga útil maliciosa están en el espacio de datos.

Si observa lo que normalmente se explota en los sistemas x86, es decir, los desbordamientos de pilas, los desbordamientos de pila, las sobrescrituras, las cadenas de formato, etc. no es tan grande como una superficie de ataque. Con la posible excepción de cadenas de formato, no veo que ninguno de esos ataques funcione, ya que la arquitectura simplemente no lo permite.

Si está interesado en este tipo de investigación, recomendaría ver errores de reloj y voltaje, esto a menudo permite extraer información de los dispositivos incluso cuando están bloqueados, y simplemente fastidiarlos con ellos en general. También puede probar el análisis de potencia diferencial si está a la altura de las estadísticas. Por último, los ataques de tiempo son probablemente los más fáciles de explotar si buscas algo con lo que empezar.

En el lado derecho del hardware, hay un programa llamado degate que permite invertir los chips en el nivel de silicio. Ha habido un par de charlas decentes sobre el tema y probablemente te encantarán.

Realmente no hay nada que se pueda explotar a en un procesador integrado como el ATmega (usado en Arduino) ya que solo hay un nivel de ejecución (acceso completo) y no hay cosas sofisticadas como el anillo de CPU Intel / AMD protección (mantener el código de usuario alejado del código del kernel en hardware).

Si conectas un depurador, obtienes acceso completo a RAM y flash, por lo que no hay necesidad de explotar nada, realmente ...

Las explotaciones de búfer con la intención de controlar a través de incisión de código solo funcionan contra la arquitectura de Princeton, porque el almacenamiento de datos y el de programas comparten la misma memoria.

Ahora nuestro valiente Atmel tiene una arquitectura de Harvard: ejecuta código desde una memoria diferente a la de los datos. Y nuestro desbordamiento de búfer explotado de forma astuta solo puede escribir en SRAM, que no se puede ejecutar.

Sin embargo, podría bloquear el Arduino si tiene una forma de transferir datos al búfer.

Como señaló Madmanguruman, en realidad no hay nada que explotar en un procesador integrado. La verdadera pregunta es ¿POR QUÉ quieres explotar un dispositivo integrado? Si tuvieras un Ardunio independiente y pudieras explotar algo, ¿qué podrías hacer con él?

En las PC modernas, la mayoría de las veces, explotar una vulnerabilidad te dará acceso remoto a la raíz, que es prácticamente el objetivo final. Sin embargo, un sistema incorporado, por lo general, no tiene archivos, información ni nada por el estilo, aunque hay excepciones.

Si desea explotar un sistema integrado, generalmente es para un propósito específico. Además de eso, la vulnerabilidad será completamente única casi siempre. Además, la mayoría de los dispositivos integrados no se van a conectar; lo que significa que necesita acceso físico a ellos para hacer cualquier cosa. Y una vez que tiene acceso físico, tiene todas las tarjetas y se puede hacer cualquier cosa. Este es uno de los aspectos raros de la ingeniería que intenta encontrar una solución a un problema, no al revés.