Buffer overflows and SPARC register windows

I found a report on “Code Injection in C and C++ : A Survey of Vulnerabilities and Countermeasures” (July 2004). At 70+ pages it’s too early to say whether I’d recommend it as light reading but as I’m anticipating a long train journey in the next few days I should be able to get through it.

What set this off was a lunchtime discussion on how buffer overflows can affect processors with register windows. If you don’t know what I’m talking about then check the Wikipedia article. Fascinating … if you’re technically minded.

The thing with register windows is that the return pointer you want to overflow may not be in memory. You have to overflow spilled register sets. I was struggling to find a reference to this and most people I’ve asked just give me a blank look. For sometime now I’ve been wondering if I’ve been missing something obvious.

Thankfully, Google came to the rescue and found a paper all about this. It contains this quote:

As long as register windows are available, it is not possible for an overflow to overwrite the function’s return address or frame pointer as they will still be contained in registers. However when the oldest window is saved to the stack, they are again vulnerable to overwriting.

Apologies to the authors if I should not have quoted this article, I couldn’t find any distribution or copyright notices

The paper discusses the state of the ‘art’. That above quote came from a discussion on StackGhost which attempts to validate return addresses when filling the register window.

So it does appear that register windows do offer some protection but I’ve never managed to demonstrate this with simple overflow code. If anybody has an example to back me up I’d be very interested to try it.

Leave a comment


  1. Marshall T. Vandegrift

     /  June 27, 2005

    Maybe I’m missing something, but doesn’t context switching cause every register window being used by the process spill to the stack? And then when the process is switched back in, aren’t the registers reloaded from the stack spill space? This would lead to unusual conditions where exploitation would fail because the process hadn’t been switched out between when the stack overflowed and the jmpl instruction executed, but usually things would work as on any non-windowed architecture.

  2. Matty

     /  June 27, 2005

    Assuming that PC/NPC will be in a register and not on the stack doesn’t hold much weight. It’s easy enough to force window overflows, and I have never had an issue with PC not containing a valid value when I needed to overwrite it (busy systems that use non-leaf function ensure this). Ghandi briefly covers this in his Defcon 8 presentation “Dot-Com Smashing: Buffer Overflows on the SPARC.”

  3. Thanks for the comments, I’ve written a follow up to the entry with some example code that demonstrates a contrived example of an overwritten stack not being effective due to register windows.
    I am definitely not claiming that register windows are a defence against stack overflows, it was more the intellectual exercise of understanding the subtleties of SPARC register windows.
    Referring to Matty’s comment … is there a transcript of the Defcon 8 presentation anywhere? I found the video and audio.

  4. Peter Harvey

     /  July 15, 2005

    I’ve now listened to the DefCon 8 presentation. Ghandi does briefly answer the question as to how we overwrite the return address when, due to register windows, it ought to be in a register. Essentially, sytem activity tends to ensure that a spill has taken place at some point before the actual overflow takes place.
    My later blog entry illustrates this in more detail. In particular it shows that (say) calling printf() before overflowing the buffer is sufficient to spill the caller’s stack.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

  • Sporadic tweets from me

  • Tags of interest

  • Categories

  • Advertisements
%d bloggers like this: