User manual

[netwer...@gmail.com]

Hi,

 

first of all thanks for this tool. Based on the paper and part of the presentation I witnessed at BH it seems like a cool thing.

 

Unfortunately I got problems getting the tool to report something usefull. Thats probably my ignorance but a better manual or explanation on e.g. the provided testcases would help.

 

My setup: make a testcase thats easy to exploit (I think)

* ubuntu 10.10 64 bit

* disabled ASLR

* enabled executable stack

* created a program thats full of bugs

** printf format string bug

** Buffer overrun on heap bumping into the VPTR of a simple class

** I have attached the source code for reference.

 

Things I do not understand. I would expect it to report the address of argv[1] or a offset in that buffer.

 

When I attach during the 'sleep' it reports the address right after the sleep call.

 

(./test AAAAAAAAAAAAAAAAA & ); ./pmcma -d -p `pidof test`

.

.

 

.

.

 --> total : 1 validated function pointers
            (and found 0 additional control flow errors)

 

 

When I call pmcma with the -C option it complains:

 

./pmcma -C ./test AAAAAAAAAAAAAAAAAAAAAAAAAAA
 [!] Couldn't parse command line

 

Adding "-d" will make it happy:

 

./pmcma -d -C ./test AAAAAAAAAAAAAAAAAAAAAAAAAAA

Function prologue: yes
Valid (strict) compatible: yes
 -->> backed up original bytes at 0x00400913
55 48 89 e5 48 83 ec 10 48 83 ec 10 48 83 ec 10    UH.eH.l.H.l.H.l.
48 83 ec 10                                        H.l.           
 -->> executing fork stub at new ip=0x400915 (3)
 ** Attempting to hijack function pointer at 00007fffffffefed with new pid=3967
signo: 11 errno: 0 code: 128
killing:3967

 --> total : 0 validated function pointers
            (and found 0 additional control flow errors)
 

Could someone give some explanation on how to interpret the output.

 

Best regards,

 

Ruud

[Jonathan Brossard]

Dear Ruud,

Thanks for trying pmcma and posting the first message ever on this
mailing list.

First of : I agree we need to make an effort on documentation, figuring
out what pmcma is actually usefull for isn't too easy if you are not
able to read the whitepaper, which is very technical.

> * enabled executable stack
> * created a program thats full of bugs
> ** printf format string bug
> ** Buffer overrun on heap bumping into the VPTR of a simple class

You don't need an executable stack. You don't need to disable ASLR
either : pmcma was built to help exploitation under real conditions ;)

Now, heap overflows are definitly inside the capabilities of pmcma as it
is today (by overwritting function pointers in the heap).

> --> total : 1 validated function pointers
> (and found 0 additional control flow errors)

It would be usefull to have the full log of the analysis, which is
normaly saved under ./report-<pid>/analysis.txt for your reference.

From the small output you are showing us, pmcma manages to find a
function pointer actually used after you trigger the bug. Now, is it in
the heap section (which is a pre requisite so we can overwrite it using
the heap overwrite you are triggering) ? Impossible to answer without a
full report from pmcma :) It all depends if the given function pointer
found is in the heap section and if you can get to overwrite it using
the particular bug you are triggering.

> When I call pmcma with the -C option it complains:
>
> ./pmcma -C ./test AAAAAAAAAAAAAAAAAAAAAAAAAAA
> [!] Couldn't parse command line
>
> Adding "-d" will make it happy:

You just found a bug in pmcma. Please fill a bug report on github along
with full analysis.txt reports in both cases : that will help us narrow
down the bug and get it fixed faster.

Note that you can submit patches on github yourself : we already
accepted and merged several bug fixes !!

Thanks and regards,

Jonathan Brossard

> --
> You received this message because you are subscribed to the Google
> Groups "pmcma" group.
> To post to this group, send email to pm...@googlegroups.com.
> To unsubscribe from this group, send email to
> pmcma+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pmcma?hl=en.

[Jonathan Brossard]

Oups, I missed the attachements ;)

>--[ Stopped at:
>cmp rax, 00000000FFFFF001h

>--[ Registers:
>rax=0xfffffffffffffdfc

The bug looks more like an invalid memory dereference in read mode, eax
pointing to unmapped memory. This type of bug is normally not exploitable.

That being said, pmcma also reports that the stack is likely to be
corrupted : if such is the case, you may have created a stack overflow
and the rest of the analysis will be biased (you can double check this
easily : did you compile the binary with stack cookies that would make
stack overflows direct exploitation fail because of stack cookies
overwrite ?).

>--[ Validating function pointers (relaxed mode):
>
> <*> Dereferenced function ptr at 0x00007fffffffe698 (full control flow
hijack)
> 0x00007fffffffe698 --> 0x000000000040092c // repeatability:101/100

>
> --> total : 1 validated function pointers
> (and found 0 additional control flow errors)

This means that at location 0x00007fffffffe698, you have a reliable
function pointer to overwrite. If you can overwrite it, then you can
hijack control flow of execution with a probability of 100% (pretty
common with disabled ASLR ;). Since you made the whole address space
executable, you'd like to modify your trigger to have this pointer
overwritten with a pointer to your own shellcode : that would grant you
a reliable exploit under the conditions you are testing.

Thanks and regards,

Jonathan Brossard