Re: Parameter Overflow Attack?
From: Mark Gordon (spamtrap@flash-gordon.me.uk)
Date: 11/28/02
- Next message: jardinero: "Re: canaries in live code"
- Previous message: Mark Gordon: "Re: IP Address & Anonymity"
- In reply to: Barry Margolin: "Re: Parameter Overflow Attack?"
- Next in thread: Walter Roberson: "Re: Parameter Overflow Attack?"
- Reply: Walter Roberson: "Re: Parameter Overflow Attack?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 28 Nov 2002 16:41:53 +0000 From: Mark Gordon <spamtrap@flash-gordon.me.uk>
On Tue, 26 Nov 2002 15:25:55 GMT
Barry Margolin <barmar@genuity.net> wrote:
> In article <arvrlg$sq3$1@cam-news1.cambridge.arm.com>,
> Peter Fordham <duh@duh.duh> wrote:
> >If this does corrupt the stacked return address and buffer overrun
> >style you can use this to branch to a difference bit of code is this
> >useful for anything interesting. i.e. can, if you do this to a
> >kernel/system call, execute arbitary code whilst remaining in kernel
> >space and hence with full access?
>
> No. When you perform a system call, you're actually calling a normal
> user-mode function that processes the arguments, and then performs a
> special instruction to enter kernel mode. The memory that you'll
> corrupt will be its user-mode memory, not the system-mode memory.
>
> If the OS is properly designed, nothing you do in user mode should
> ever be able to modify system memory, except in ways that the system
> calls intend.
Also, the normal C calling conventions are that the parameters are
pushed on to the stack in reverse order, followed by the return address
so the called routine would see everything correctly. The caller is then
normally responsible for removing the parameters from the stack.
Therefore with any OS written for follow C calling conventions (most
*nix type OSs?) will not have any problems with the extra parameter.
IIRC Windows generally uses Pascal calling conventions, which meens that
the parameters are pushed on to the stack in the order they appear in
the parameter list, so placing the extra parameter at the end will cause
the called routine to see the parameters in the wrong order, you can get
around this by putting the extra parameter first. However, since the
called routine is responsible for removing parameters from the stack it
will leave the stack pointer in the wrong place. IIRC the return address
would still be the last thing pushed on the stack during the call (I
can't think of any implementation where this won't be the case) so the
return from the OS call will still go to the correct place, however the
program may later attempt to execute arbitrary code and will almost
certainly crash. However, at whatever point the stack corruptopn causes
a problem it will be after return to user space execution of the program
(even if it is the return from the OS call) and therefor does not allow
the code access to anything the user executing the code did not already
have access to.
I have in the past debugged problems under Windows 2000 where, dur to
problems in headers provided with a device driver, calls to the driver
(which has full kernel privileges IIRC) were made with incorrectly sized
parameter and the call to the driver still returned to the correct
place, but the stack pointer was incorrect so the program crashed later
in the user space code.
-- Mark Gordon Paid to be a geek.
- Next message: jardinero: "Re: canaries in live code"
- Previous message: Mark Gordon: "Re: IP Address & Anonymity"
- In reply to: Barry Margolin: "Re: Parameter Overflow Attack?"
- Next in thread: Walter Roberson: "Re: Parameter Overflow Attack?"
- Reply: Walter Roberson: "Re: Parameter Overflow Attack?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
