Transmeta To Add 'NX' Antivirus Feature To Chips

Autoversicherung writes points to a ZDNet story which says that "Transmeta will support "No Execute," or NX, in their next core revision. Transmeta will provide advance versions of Efficeon-based systems with NX support to Microsoft for testing. Hope Linus get a few too, even if he's no longer working there. The NX-equipped Efficeon chips are due for general release later this year."

Comments

Note to editors

[Anonymous Coward]

The NX bit is not an 'antivirus' feature.

Re:is this worth it?

[LostCluster]

Because any time you're allocating memory for yourself, the OS isn't quite sure just what you're going to put there. When it's assembly-written code, the OS really can't tell the difference between the load of more code and the load of data.

Besides, what if the buffer exploit is inside the operating system itself? Even Linux could fall victim to that kind of mistake. We've found that as long as bad code is distributed, somebody will still be running it long after the issue has been discovered and patched, and there's been worms to prove it.

Anti-virus?

[__aagctu1952]

How exactly is this an anti-virus feature? Anti-buffer-overflow, yes. Anti-worm... well, maybe, but it'd be a bit of a stretch (anti-worm-based-on-buffer-overflow rather). Anti-virus? Hell no.

I just love tech journalism...

Re:Failure ?

[bersl2]

"No need to bother writing secure code cus new chips will have NX technology?"

I don't think that this segment of the programming population falls into those kind of pitfalls very often.

I know at least one other post called it a "fallback" measure, which sounds about right. It's a third line of defense against buffer overflows and the like (the first being good programming practices, the second being things like libsafe).

Sure, it is also helpful towards Microsoft; I can see how it restricts circumvention of DRM. But there are always other ways around. If you overflow into a buffer not protected by NX, you still have arbitrary code execution on your hands.

Of course, this is just what I get from the other posts and intuition. It's not like I RTFA or anything...

Re:So simple, we might as well do it.

[steveha]

A buffer overrun is a way of putting data PAST the end of your variable (which would be marked NX in your hypothetical scenario) into an about-to-be-executed chunk memory.

That could be true, if the buffer were placed right before an executable chunk. But it never is. Variables are allocated on the stack, not in code space. Heap memory is often allocated near the stack, but again not in code space.

When a program calls a function, it stashes a return address on the stack. This address specifies where execution should resume after the function returns. If an exploit can overrun the stack, the exploit overruns this return address! So an exploit will fill a buffer, run off the end of the buffer, put an address on the stack right where it overwrites the return address of the current function, and possibly then overrun some more. If there is a function embedded in the overrun (either on top of the buffer, or after the return address) the address of that function is used to overwrite the return address. So when the function returns, that function runs. A small amount of code can act as a bootstrap loader that loads the rest of the exploit.

Here's a primer on how to write a basic stack smashing local root attack. I just found this with Google.

http://community.core-sdi.com/~juliano/htce.txt

Here's the text of a comment from the sample code:

filling up the end of the buffer with our shellcode which will be executed on the stack after the bof

Emphasis added by me. "executed on the stack"... in other words, this exploit would not work if the stack were marked NX, like I said.

Can you find me an article about how to execute a stack-smashing attack, where the exploit actually blows past the end of the stack or the heap and somehow winds up in normal code space? I have never heard of any such. Can you find even one example of the technique as you describe it?

steveha