7
\$\begingroup\$

Is it possible exploit stack buffer overflows on an Arduino board?

\$\endgroup\$
8
\$\begingroup\$

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.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Thank you. I've read the INRIA attack paper and I'm trying to do the same thing with arduino language on atmega2560, but I can't reach the return address with the avr atmega2560. I don't understand where are my mistakes. \$\endgroup\$ – DarkCoffee Aug 16 '13 at 15:22
  • 1
    \$\begingroup\$ @DarkCoffee: This attack requires digging below the C++ level. You'll have to disassemble the firmware and study the AVR assembly language code, to see which function tails have useful side-effects. Then, to call each one, you'll have to do a raw JMP instruction. If that leaves you with more questions, best bring them up on Stack Overflow. \$\endgroup\$ – Warren Young Aug 16 '13 at 15:27
  • \$\begingroup\$ Thank you so much. For the moment I'm trying to create a vulnerability with the buffer overflow. I'm going to write on Stack Overflow. Thank you! \$\endgroup\$ – DarkCoffee Aug 16 '13 at 15:35
5
\$\begingroup\$

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.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ -1: Harvard architecture isn't a perfect protection, as I point out in my answer. Also, the hardwired TCP stack on an Arduino Ethernet shield's WizNet chip is probably not possible to attack. At least, it isn't likely to affect the separate CPU chip. \$\endgroup\$ – Warren Young Aug 16 '13 at 1:42
2
\$\begingroup\$

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.

| improve this answer | |
\$\endgroup\$
1
\$\begingroup\$

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...

| improve this answer | |
\$\endgroup\$
  • 1
    \$\begingroup\$ If you hook up a debugger, it's not a remote exploit: you have physical access. \$\endgroup\$ – Kaz Aug 14 '13 at 13:53
  • 2
    \$\begingroup\$ Exploit doesn't mean to gain the highest privilege, but simply to make some machine execute unauthorized code on behalf of the attacker. Exploits never have to leave an unprivileged security context (e.g. that of a user application on a PC) in order to do real harm. \$\endgroup\$ – Kaz Aug 14 '13 at 14:14
  • 2
    \$\begingroup\$ Code execution, if not a designed feature, is an exploit - existence of privilege model or not. \$\endgroup\$ – Chris Stratton Aug 14 '13 at 15:17
0
\$\begingroup\$

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.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ There's a useful point here, but it's not a pure harvard architecture. If the Arduino bootloader is present and you can get that to come up on the serial (by causing a reset) then you can flash anything you want. \$\endgroup\$ – Chris Stratton Aug 14 '13 at 15:19
  • \$\begingroup\$ -1: Sorry, but you're propagating myths here. AVRs have been exploited, and Harvard architecture in general doesn't prevent stack smashing attacks from executing arbitrary code. See my answer for details. \$\endgroup\$ – Warren Young Aug 14 '13 at 17:55
-1
\$\begingroup\$

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.

| improve this answer | |
\$\endgroup\$
  • 1
    \$\begingroup\$ What could you do with it? Oh, suppose the embedded board is controlling a keyless entry system. If the software has a flaw, you could gain unauthorized access. \$\endgroup\$ – Kaz Aug 14 '13 at 13:54
  • 2
    \$\begingroup\$ -1: There are plenty of things to exploit in embedded systems, there are plenty of attacks on them, and embedded systems are becoming increasingly connected. Just this last week, there was a well-reported remote attack against smart toilets. \$\endgroup\$ – Warren Young Aug 14 '13 at 15:53
  • \$\begingroup\$ Yeah, I suppose I could have worded it better. But I was basically stating that some generic vulnerability for one specific device (arduino) doesn't necessarily buy you anything. Yeah, you can exploit a keyless entry system, or a toilet, but the approaches would be immensely different, and some generic "buffer overflow for ardunio" wouldn't apply. I was trying to get the asker to approach the question differently, looking for a reason to do so and exploiting that, rather than trying to find a way to "attack all things" with one process. \$\endgroup\$ – Kris Bahnsen Aug 14 '13 at 16:13
  • \$\begingroup\$ Of course the attack buys you something: complete pwnage of the attacked system. What more did you want? :) \$\endgroup\$ – Warren Young Aug 14 '13 at 17:21
  • \$\begingroup\$ @WarrenYoung Quick! Attack my 3D printer controller via the USB-serial connection through my PC connected to the internet and use it to print phallic objects! haha \$\endgroup\$ – Kris Bahnsen Aug 14 '13 at 17:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.