|
BugTraq
Preventing exploitation with rebasing Feb 04 2003 05:08AM David Litchfield (david ngssoftware com) (7 replies) Re: Preventing exploitation with rebasing Feb 05 2003 01:41PM dullien gmx de (1 replies) Re: Preventing exploitation with rebasing Feb 04 2003 10:52PM David Litchfield (david ngssoftware com) (2 replies) Re: Preventing exploitation with rebasing Feb 04 2003 02:00PM Torbjörn Hovmark (torbjorn hovmark abtrusion com) Re: Preventing exploitation with rebasing Feb 04 2003 11:38AM Charlie Root (weedpower home ro) (4 replies) Re: Preventing exploitation with rebasing Feb 06 2003 01:00AM Deus, Attonbitus (Thor HammerofGod com) Re: Preventing exploitation with rebasing Feb 04 2003 08:08PM Brian Hatch (bugtraq ifokr org) (2 replies) Re: Preventing exploitation with rebasing Feb 04 2003 05:26PM Alan DeKok (aland freeradius org) (2 replies) Re: Can't Preventing exploitation with rebasing Feb 05 2003 10:06AM bugtraq gaza halo nu (2 replies) Observation on randomization/rebiasing... Feb 05 2003 09:10PM Nicholas Weaver (nweaver CS berkeley edu) (1 replies) Re: Preventing exploitation with rebasing Feb 04 2003 06:38PM David Litchfield (david ngssoftware com) (1 replies) Re: [VulnDiscuss] Re: Preventing exploitation with rebasing Feb 05 2003 05:32PM Halvar Flake (halvar gmx net) Re: Preventing exploitation with rebasing Feb 04 2003 11:34AM Eugene Tsyrklevich (eugene securityarchitects com) Re: [VulnDiscuss] Preventing exploitation with rebasing Feb 03 2003 09:49PM Michal Zalewski (lcamtuf coredump cx) |
|
Privacy Statement |
sumarise here
> This won't protect against heap overflows etc.
Agreed. The suggestion I was making was that exploits that rely on a
specific instruction such as "jmp esp" being at a specific address can be
defeated or slowed down by this.
>You can brute force the address space.
Yes - you can - IF the server stays up. In many cases it does not. In those
cases where the server does stay up at least you _have_ to brute force. It
means that you haven't compromised my server straight away. In the interim
of the exploit starting the attack on the server and the server being
compromised I'd hope that my _other_ defences such as IDS/IPS will notice
that something is awry.
> It's better to patch
Of course it is. (If you do rebase a system though you'll need to re-rebase
it after applying patches.)
>or mark the stack as non-executable
Sure. But in the absence of this rebasing can help protect.
> Most exe's don't have a .reloc section and can't be rebased.
Agreed. I was in error and forgot when writing the mail. That said even if
the exe can't be rebased then default Image Base is 0x00400000. _If_ there
was a suitable instruction in the exe image - one that will get you back to
the actual code - then this address has a NULL in it. Many vulnerabilities
require the arbitrary code to go after the saved return address as
everything above gets munged. So the possibility of exploitation is
reduced - note reduced - not negated.[Of course - in the case of unicode
overflows the NULL is not an problem]
What determines whether this is a reasonable protection method/step to take
is the cost versus likelihood of attack.
It's easy to rebase a system so the cost is low. As most Windows exploits
are simple affairs the likelihood of attack is fairly high.
Those that rebase their system will be vulnerable to c. 30-40% of exploits.
Those that don't will be vulnerable to 100%.
What I'm trying to say is that, "If my system has to be/or is going to be
vulnerable to a vulnerability - I want to make sure that it's going to be a
better than average exploit that suceeds in gaining control."
Security is about putting as many hurdles in front of an attacker as
possible. The more hurdles the less likely they are to break in. I'm not
forcing anyone to adopt this as a "hurdle" to add. I put it forward simply
as another line of defence that people may choose to do if they wish.
Take it or leave it.
Cheers,
David Litchfield
[ reply ]