Is it possible exploit stack buffer overflows on an Arduino board?
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.
There isn't really anything to exploit on an embedded processor like the ATmega (used on Arduino) since there's only one execution level (full access) and no fancy stuff like Intel/AMD CPU ring protection (keeping user code away from kernel code in hardware).
If you hook up a debugger you get full access to RAM and flash, so there's no need to exploit anything, really...
Buffer exploits with intent to control via code incection only work against Princeton Architecture, because data storage and program storage share the same memory.
Now our plucky little Atmel has a Harvard Architecture - it runs code from a different memory than data. And our craftily exploited buffer overflow can only write to SRAM, which cannot be executed.
It might crash the Arduino, though, if you have a way to transfer data to the buffer.
As Madmanguruman pointed out, there is not really anything TO exploit on an embedded processor, in a way. The real question is WHY do you want to exploit an embedded device? If you had a standalone Ardunio, and could exploit something, what could you do with it?
In modern PCs, most often exploiting a vulnerability will get you remote root access which is pretty much the ultimate goal. But an embedded system USUALLY does not have files, information, or anything like those, though there are exceptions.
If you want to exploit an embedded system, its usually for a specific purpose. On top of that, the exploit is going to be completely unique almost every time. Furthermore, most embedded devices are not going to be connected; meaning you need physical access to them in order to do anything. And once you have physical access, you hold all of the cards and anything can be done. This is one of the rare aspects of engineering that is actually trying to find a solution to a problem, not the other way around.