> Umm, no. Before you can play games like masking to produce the desired
> address in a register, you have to gain control first, which means you
> need to overwrite the return address on the stack. If the attack code
> is on the stack, and then the return address which you need to write
> contains a null, and as long as some routine which is expecting a null
> terminated string (i.e., strcpy) is used to overrun the on-stack buffer,
> it will stop before it has a chance to write the entire return address.
Ah, yes yes... you are right. You need to divert into the code on the stack
first, that is correct. But then, give you can succeed with the diversion of
intended execution, then you need code with a non-zero in order not to have
your diversion cut out. The run-way problem is still there to solve.
> This won't save you if the program is using memcpy, but with memcpy
> there is an explicitly length passed in, and *hopefully* the programmer
> has been bright enough to sanity-check the length before passing it into
> memcpy.... but stupider things have happened in the past.
Oh yes... like those that those who avoid strcpy by doing
memcpy(t, s, strlen(s)+1)
I mean, memcpy is supposed to be safe, ain't it ;)
> This also won't save you if the attacker knews the address of a static
> buffer (which is in the data segment), and can store arbitrary data of
> his/her choosing in that static buffer, and then overwrites the return
> address on the stack to point to the static buffer. But then again, the
> non-executable stack hack won't save you in this case either.
Certainly true. Then, by the nature of our habbit we would go off and mark
the datasegment as non-executional. I wounder how many programs that would
go bezerk from that.
As we cut down on what goes executional we also cut down on what can be
dynamically loaded or generated (tcpdump -d makes you think) by an application
we suddenly start to cut down on the freedom that exists in the current
scheme. The discussion is touchy as we have seen on just making the stack
non-executional. Maybe we should add an extra bit for executional stack and
one for executional heap to the chmod stuff and only allow root or whatever
to set them. This would certainly force people to look at those applications
but only at those (in this respect I migth add) instead of all. There is no
trick in these waters that is simple and that works in a generic way all the
way.
> Of course, all of these solutions are kludges. No question! The real
> right answer is to get application programmers to use appropriate
> defensive coding techniques, or if you're really desparate, compile
> programs using something like Stackguard.
For a long time we had faith in that people would (at least eventually) write
propper stable code. This has sadly not happend and we still make the same
misstakes all over again. However much it hurts in the hacker hart, it seems
like limiting the freedom of the programmer in various fashions is one of the
few strategies that actually works. Yes, you can do less neat tricks but some
of those has to be sacrificed on the altar of security by our high priests in
hope of a better life there after.
We wont solve this as easy as the PPP over SDH/SONET trouble ...
Cheers,
Magnus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/