Re: The coming death of all RISC chips.

Christopher <nadiasvertex@xxxxxxxxx> writes:
On Apr 23, 11:11=A0am, an...@xxxxxxxxxxxxxxxxxxxxxxxxxx (Anton Ertl)
wrote:
Christopher <nadiasver...@xxxxxxxxx> writes:

[register stack engine]

One thing that I like most is that it eliminates
the possibility of buffer overflows affecting the instruction
pointer. =A0(The register engine writes to and reads from a completely
different area of memory than the "stack", and it can be protected
from user or system code writes.)

That does not help in general, just like any software variants that
put return addresses in a separate place from other data do not help
in general: Any arbitrarily indirect pointer to code that can be
overwritten by a buffer overflow is a potential hole (and an actual
hole if the software later follows the chain of indirections and
finally executes the pointed-to code).

A typical example of such an indirect pointer is a pointer to an
object in C++; the object contains a pointer to a virtual function
table, and the table contains virtual function pointers (i.e., code
pointers). =A0And C++ code follows such indirection chains on every
indirect function call, i.e., typically quite often.

You have missed the point. The application can never deliberately
write in the register stack area. It is protected by the hardware.
So you can't overflow the stack and get at the return value pointer,
which is where the vast majority of problems are.

No, I did not miss that point. You missed my point: There are other
ways to exploit buffer overflows. If you want to be safe, it does not
suffice to close one hole if there are several.

The other piece is
that IA64 "calls" are functors, so it's much, much harder to get a
"suitably indirect pointer."

Explain why you think so. Given that you missed my point, I'm not
inclined to take your word for that.

The architecture eliminates the most common and easiest to exploit
vulnerability, which is overflowing a buffer located on the stack, and
causing it to affect the instruction

It does not.

Just consider a buffer located on the (non-register) stack followed by
a stack-allocated object (e.g., in C++). The buffer overflow can
change the vtable pointer in the object, and let it point into the
buffer. A method invocation for that object will then result in
executing code that is determined by the attacker.

While overflowing a buffer located on the heap can also be exploited,
it is typically much, much harder since you can rarely be sure about
the relative location of the buffers.

Predicting heap arrangement is unnecessary, as stuff on the stack has
this problem already. However, placing all buffers in the heap is not
secure, either, because there is no guarantee of random placement; on
the contrary, heap placement of a process tends to be the same as for
other instances of the process as long as the sequence of allocations
and deallocations is the same.

Consider: vtables are known at compile time, and are generally placed
in a read-only area, so you cannot generally overwrite the vtable
itself. To exploit a flaw in a vtable lookup you have to not only
modify the this pointer on the stack, you have to point it at a
deliberately crafted vtable with your malicious address at the right
offset.

Since I can write to the buffer and beyond, that's pretty easy.

Finally, the address pointed to has to exist in the local
call space and have a useable final destination address and call space
address.

I don't know what that's supposed to mean, but even if it restricts
the attacker to use an existing function (e.g., if stack and heap are
not executable), there are typically a number of functions that let
him do anything that the target process's owner can do, e.g., the
system(3) function.

Clearly, this is far more difficult than a "return to
arbitrary address" exploit possible on architectures which store the
return address in the same stack as the buffer that gets overflowed.

Yes, corrupting the return address is probably easier; at least that
would explain that that kind of exploit is more common. But if
someone closes that hole, the attacks will use one of the other holes.
Any claims that closing the return-address hole makes the system
secure are specious.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@xxxxxxxxxxxxxxxxxxxxxxxxxx Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
.

Relevant Pages

  • [0xbadc0ded #04] smtp.proxy <= 1.1.3
    ... A remotely exploitable format string vulnerability exists in smtp.proxy ... Since the 'line' buffer is ... Since smtp.proxy is started from a superserver, like inetd, the stack ... To determine the address of a function pointer we could either try to ...
    (Bugtraq)
  • [Full-Disclosure] [0xbadc0ded #04] smtp.proxy <= 1.1.3
    ... A remotely exploitable format string vulnerability exists in smtp.proxy ... Since the 'line' buffer is ... Since smtp.proxy is started from a superserver, like inetd, the stack ... To determine the address of a function pointer we could either try to ...
    (Full-Disclosure)
  • Re: Stack growth direction to thwart buffer overflow attacks
    ... However, growing the stack upwards doesn't help a bit, since usually buffer ... The only cure for buffer overflows is to cure the buffer overflow itself. ... * guard markers: exploiter writes the guard markers himself. ...
    (comp.security.misc)
  • Re: Stack growth direction to thwart buffer overflow attacks
    ... However, growing the stack upwards doesn't help a bit, since usually buffer ... The only cure for buffer overflows is to cure the buffer overflow itself. ... * guard markers: exploiter writes the guard markers himself. ...
    (comp.security.unix)
  • Re: Buffer Over-runs, was Open source firewalls
    ... > pointer to the systemlibrary function. ... anybody who thinks that the non-executable stack gives ... > shared libraries tend to be loaded." ... gcc level tricks to prevent buffer overflows are widely in use nowadays ...
    (Linux-Kernel)