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.