Re: GetPC code (was: Shellcode from ASCII)

From: Aaron Adams (aadams_at_securityfocus.com)
Date: 11/18/03

  • Next message: Paul Johnston: "Can you exploit this XSS?" 
    Date: Tue, 18 Nov 2003 15:57:51 -0700 (MST)
To: noir <noir@gsu.linux.org.tr>

    Hey Noir,

    I've been looking into FPU stuff a bit lately and decided to look into
    what you described a little deeper. I decided I'd give you and the list
    the details of what the deal is with this.

    Basically, you can do a GetPC procedure without simulating any exception.
    In fact, the data stored by fnstenv isn't influenced by the exception nor
    is it actually an exception record. fstenv/fnstenv is commonly used by FPU
    exception handler code though, to analyze the state of the FPU environment
    that an exception occured within.

    Although you are triggering an exception, all of the exception bits in the
    control word are masked by default when the environment is initialized. As
    such, if an exception occurs the only result will be the appropriate
    exception flag being set within the status word.

    So, keeping this in mind we'll see what actually allows the GetPC to be
    possible. Basically, the state of the FPU environment, following the first
    floating point instruction, is always maintained. The fnstenv/fstenv
    instructions can be used to save the state of the environment to the
    location pointed to by it's operand. So the only requirement to actually
    using fstenv/fnstenv is to have previously executed an FP instruction.

    The structure stored by fnstenv is defined as user_fpregs_struct in
    sys/user.h and is saved as so:

    0 | Control Word
    4 | Status Word
    8 | Tag Word
    12 | FPU Instruction Pointer Offset
    ...
    ...

    As you explained, the FPU Instruction Pointer will be the address of the
    previously executed FP instruction. And as seen above it's located at
    offset 12 within the structure.

    Because we can specify the location that fnstenv stores the structure
    I came up with something that can kind of simplify obtaining the PC. It
    can be seen in the following code, which is the smallest way I could come
    up with to do a GetPC procedure.

    fldz
    fnstenv -12(%esp)
    popl %ecx
    addb 10, %cl
    nop

    So, when this is executed you'll have the current pc in ecx when you hit
    nop. It's pretty similar to what you did, but hopefully it clarifies some
    stuff.

    ttyl.

    Aaron Adams

    On Fri, 27 Jun 2003, noir wrote:

    > """
    > > First thoughts on the second challenge: You can't use any of the call
    > > opcodes, but you might be able to setup a quick exception handler in
    > > the known mapped space. Cause a fault, and then find the address of
    > > your fault causing instruction in the structure that's passed. (Again
    > > I'm talking NT).
    >
    > I'm not sure this could be done (same problem) but, keep this in mind
    > anyway :-
    > ) [hint]
    >
    > gera
    > """
    >
    > i have spend good 20 minutes on this, i don't have the solution yet due to
    > lack of time but i thought this might be interesting for the list.
    >
    > basicly, i'm simulating a floating point exception (division by zero) and
    > then grabbing the EIP(pc) from the exception record. PC is the location of
    > the fdivs instruction since that instruction created the exception
    > condition so we add 11 on top to make %eax point to the nop instruction.
    > (ATT syntax)
    >
    > xor %eax, %eax
    > push %eax
    > fdivs (%esp)
    > fnstenv (%esp)
    > mov 0xc(%esp), %eax
    > add $0xd, %eax
    > nop
    >
    >
    > - noir
    >
    > sup mate ? ;)
    >
    >
    >
    >
    >
    >
    >
    >

  • Next message: Paul Johnston: "Can you exploit this XSS?"

    Relevant Pages

    • Re: GetPC code (was: Shellcode from ASCII)
      ... thanks for enlighting us about the internals of all this FPU stuff. ... you can do a GetPC procedure without simulating any exception. ... Basically, the state of the FPU environment, following the first ... > using fstenv/fnstenv is to have previously executed an FP instruction. ...
      (Vuln-Dev)
    • Re: nasm segment directive
      ... To determine what the "native" behavior of the FPU is, we could design a bootsector to test the behavior. ... There's a thread on clax about "Floating Point Exception" - a guy did an ordinary "div cl" without clearing ah. ... I rebuilt the library with "DEBUG" defined, it informed me that the interrupt routine wasn't in ROM... ... Maybe dos is hooking int 10h. ...
      (alt.lang.asm)
    • Re: enabling x87 interrupts
      ... there's no external FPU chip that would assert interrupts on the ... here the South Bridge is expected to generate an IRQ13 in response to ... to signal the FPU exception back to the processor. ...
      (comp.lang.asm.x86)
    • Re: [patch 2.6.13-rc3a] i386: inline restore_fpu
      ... >>If this patch makes a difference, could you do me a favour and check ... > That lazy FPU is a huge optimization on 99.9% of all loads, ... > big hit on doing the FP restore exception (an exception is a lot more ... why the code got lazy. ...
      (Linux-Kernel)
    • Re: weirdness with Pentium FPU
      ... >>Some algorithms seem to be prone to underflow whereas others ... there is an exception of some kind. ... The FPU has both a two byte "control word" which contains bits ...
      (comp.lang.asm.x86)
    • Quantcast