Exploiting stack buffer overflows on an Arduino

Your question can be read two ways, DarkCoffee:

If a particular Arduino based device can be induced to overflow its stack, can it be exploited?

Yes, it is possible to exploit a stack overflow on an Arduino.

One possible attack is the return oriented programming method, which requires sufficiently complex firmware. So, one defense here is to keep your firmware as simple as possible. It is highly unlikely that the Arduino "hello world" sketch is vulnerable. That shouldn't be much comfort to you, though, because an LED blinker isn't terribly useful. Useful firmware will have more functions, and therefore more function tails to harvest for use in an abstract machine.

The Arduino also has a boot loader, which inherently has the power to overwrite firmware. It may be possible to exploit it to overwrite existing benign but vulnerable firmware with malign firmware.

My reading of the first page of the INRIA attack paper leads me to believe it combines both approaches: return oriented programming to execute enough code to activate the self-flashing ability of the microcontroller so that arbitrary code can be permanently loaded.

Are there stack overflow attacks on Arduinos in general?

I'm not aware of any attack that works on all Arduino based devices. Again, the "hello world" LED blinker sketch is probably invulnerable, simply because it is too trivial to be vulnerable.

The more code you write, the more likely it is that you will create a vulnerability.

Note that writing 5,000 lines of code then replacing 2 kLOC with 1,000 new lines isn't a net savings of 1 kLOC from a security standpoint. If those 5 kLOC were secure and you messed up while writing some of the new 1 kLOC, it's still a vulnerability. The moral of the story is that the most secure code tends to be that which is stared at the longest, and that means keeping it unchanged as long as possible.

Obviously, every vulnerability should be patched ASAP. This is no argument for keeping old vulnerabilities around. It's an argument against adding features thoughtlessly to code you believe secure though inspection, audit, and analysis.

The important thing is that we cannot answer this question with "no" with anything close to absolute certainty, unless we formally verify a given Arduino system, as deployed, instruction by instruction, and even then.

Arduinos have optional ethernet interfaces and other form of remote communication, so remote exploits are possible in concept. There is a TCP stack for internetworking, and even if it is small and simple, it could have flaws.

But, specifically, are stack buffer overflows possible? Consider that the Atmel AVR processors have a Harvard architecture, which means that code and data resides in separate memory spaces. That tends to rule out exploits where code is injected into the stack and subsequently executed. An address placed into the stack by an attack vector will be interpreted as being in the code space, whereas the remaining attack vector bytes containing the malicious payload are in data space.

If you look at what normally gets exploited in x86 systems, ie, heap overflows, stack overflows, seh overwrites, format strings etc there isn't that big of an attack surface. With the possible exception of format strings I don't see any of those attacks working since the architecture simply doesn't allow it.

If you are interested in this type of research I would recommend looking at clock and voltage glitching, this often allows extracting information from devices even when locked, and just buggering with them in general. You could also try differential power analysis if you're up to the statistics. Lastly timing attacks are probably the easiest to exploit if you are looking for something to start with.

On the straight up hardware side there's a program called degate that allows reversing chips at the silicon level. There's been a couple of decent conference talks on the subject and you'll probably love those.