2

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?

2

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.

  • Even if an overflow occurs in the register windows that are backed up in RAM, surely Sun thought of a way to protect those from being written by user processes... Also as for Java, everyone knows it is very vulnerable to attack. It just may be designed for safety, but it was implemented very poorly. JIT compilation should not be relied on--- you're executing data after all. – Icann Feb 16 '15 at 3:12
  • Your information is a bit off... for the stack, it is in the process address space, thus no more (and no less) "protected" from the application itself than on any other architecture. As for Java, its security issues are in the applet model, which is about the OS/browser defending from hostile code, i.e. not at all what we are talking about here (here, we talk about non-hostile code being subverted through one of its bugs). Java code (be it applet or full-blown application or server code) is immune to buffer overflows by virtue of enforcing bound checks on all array accesses. – Thomas Pornin Feb 17 '15 at 14:07
  • @ThomasPornin, you are completely right about Java , being 'safer', and the whole misconception about its security issues being related to issues with the applet sandbox over the past few years. although I would also like to throw in that Java can call native code directly ( when not sandboxed ) with the "native" keyword and I can think of methods where this could be used maliciously ( although if a user is already running compromised code outside of the sandbox then that point is moot) by accessing libraries directly on the native system and maybe calling those directly to escape userland. – Damian Nikodem Feb 18 '15 at 17:20
  • Meh. If homeland security says to turn off Java, if security experts say to uninstall it, then I doubt that Oracle has been willing/competent to solve its security issues. – Icann Feb 22 '15 at 5:14

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.