Are Sun/Oracle's SPARC processors invulnerable to buffer overrun exploits?

Question

We all use Intel architectures these days, in small part because Oracle has totally dropped the ball regarding SPARC CPU development. But with so many now saying that protection against viruses is largely futile, I am wondering if a revival of a different architecture entirely might be a good idea, especially one that keeps much of the stack inside the CPU's stacked overlapping register sets like the SPARC does. But would this solve the buffer overrun problem?

Answer 1

The problem with buffer overruns is that a buffer is overrun -- this is nonsensical, i.e. it is a bug, after which application code behaviour ceases to follow the pre-ordained plan.

The classical, let's even say primitive, method to exploit a buffer overflow is to overwrite the return address slot of a function, so that execution is derailed into a location that the attacker controls. This works only for stack-based buffers, and the industry has come up with various countermeasures to make exploitation harder for the attacker, e.g. canaries (to detect an overflow before using the return address slot) and ASLR (to make the jump less reliably controlled by the attacker).

The SPARC architecture includes register windows, which can be viewed as a dedicated in-CPU stack, kept outside of the main memory address space. Thus, it can be construed that SPARC are somehow "immune" to buffer overflows since the return address slot cannot be overwritten with a memory based access. However, this is not true, for the following reasons:

• The register windows are only in limited number (at most 32 in the architecture definition); when the call depth exceeds the number of windows in the CPU, an exception occurs and a dedicated routine flushes some of them into RAM, to be loaded back at a later time. Thus, the windows really work as a cache over RAM; consequence is that a return address slot can still be overwritten in some cases.

• There is more than the return address slot in life. Basically, any field that functionally contains a pointer to some code is a nice target for attackers. Object-oriented languages such as C++ are full of such slots, both on the stack and in main RAM (these are called vtables). The return address slot in only traditionally the main attacker target, because 20 years ago it was the easiest to reach. (A famous exploit that leveraged such non-stack function pointers after a buffer overflow was the PS3 Jailbreak.)

• Any overwrite of data can be helpful to the attacker; though injecting his own code gives him the highest power, other kinds of overflow can still lead to successful exploitation. Think, for instance, of the heartbleed bug which was all the rage a few months ago; it made thousands of sysadmins and so-called security experts scream and run around in panic ("like headless chickens", as they say around here); and yet it was only a read overflow, where nothing at all was overwritten.

A crucial point is that all these canaries and ASLR and register windows are just ways to try to cope with the aftermath of the overflow. The application has still derailed, and data was still damaged. It would be much better to act a little bit earlier, and prevent the overflow from occurring. Ideally with rigorous compile-time analysis (possibly with the help of the compiler), or at least by blocking the overflow attempt at runtime, turning it into some exception: the application still stops functioning properly, but at least it does so cleanly, without blindly keeping on with damaged memory structures.

Thus, for defence against buffer overflows, the interesting technology acquired (and then killed) by Oracle is not SPARC, but Java.