|
|
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 sd hysteria sk (1 replies) Re: Preventing exploitation with rebasing Feb 04 2003 11:20PM David Litchfield (david ngssoftware com) 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: 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 |
DL> Assuming the server did stay up, though. You've got to go through 0x7FFFFFFF
DL> addresses looking for your code or something that will get you back to your
DL> code. There'll be maybe 50 addresses with "jmp esp" - or whatever
DL> instruction you're looking for - giving you a 1 in 42949672 chance or so.
DL> Brute forcing is not reliable therefore. With all those attempts - someone's
DL> going to notice something going on - or so one would hope, anyway.
Your math is broken :-) DLL's are (as you stated) based mod 64k, so
there's only 0x80000000 / 64k - 1 different addresses on which a DLL can
start. That's less than 32k, and your chance is 1 in 32768. On
average, you get a hit after 16384 tries. Oh, btw, this method could
be optimized as you can be pretty sure that large DLL's aren't mapped
closely underneath 0x80000000.
How do you deal with EXE's that have been stripped of relocation
information ? (simple answer, not at all)
Cheers,
Halvar
[ reply ]