Hi Artur,

On 6 Sep 2005, at 08:34, Artur Grabowski wrote:
> Hm. ok...
>
> I think I understand the idea, but I don't really understand the
> problem you're trying to solve.
>
> [snipped]

Ok, I think the confusion here is my fault, because I did not fully
explain the threat model we are trying to deal with. What we're
trying to address is when an attacker has gained control of execution
but is dealing with a IDS/IPS (e.g., systrace, or sequence-based
syscall IDSs), where the attacker is constrained in what can be
done. So, in the case of systrace, the attacker must execute an
attack using a subset of the available syscalls and argument values.
Nevertheless, we showed in a paper at USENIX Security that these kind
of advanced mimicry attacks are possible, and furthermore can be
created automatically given nothing but the vulnerable binary (the
paper is available at http://www.cs.ucsb.edu/~wkr/publications/
usenixsec05mimicry.pdf, though we didn't consider systrace
specifically). Now, this attack relied heavily on overwriting
function pointers to regain control of the vulnerable process at
certain points during execution, and of course the easy target is the
PLT, which is almost always available. So, that was the main reason
for us to look at this.

> For that reason I believe that we should kill lazy binding
> and get rid of the whole mprotect scheme. The problem with that is
> that some architectures (most notably alpha) have so buggy gcc and/or
> binutils that they don't run without lazy binding (it was easier to
> implement lazy binding than to locate the bug).
>
> Completly getting rid of lazy binding would be simpler, would actually
> remove code (which is always good) and probably make things faster
> because the whole song and dance with mprotect made things so much
> slower that the added performance from lazy binding.

Sounds reasonable, this may be the way to go depending on how
lightweight (or not) an alternate, effective solution would be.

> Another approach we've been discussing is to make a special syscall
> for
> doing those modifications, but we'll have to try a few solutions to
> see
> what works best.

So I've heard, but unfortunately I haven't heard enough to know
whether it would be sufficient to protect the linking infrastructure
from an attacker who has already gained control. Of course, it's up
to you guys as to whether you care about our threat model or not, but
as I said before, I thought I'd post the idea anyway. :-) In any
case, removing lazy binding does fix all of this.

> //art
>
> ps. I'm not sure if I like the idea of making some parts of the
> address space more equal than others.

In theory, I do. As far as I can see, ld.so should be the only code
updating the PLT, and it would seem to make sense to enforce some
kind of access control to reflect that...

--
William Robertson
Reliable Software Group, UC Santa Barbara
http://www.cs.ucsb.edu/~wkr/