Dailydave mailing list archives

By Date

By Thread

Re: PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case)

On Mon, May 18, 2009 at 7:20 PM, Piotr Bania <bania.piotr () gmail com> 
wrote:

Yo,

I've got a few questions regarding your approach.

1) In section 4.4 you discuss predicting data propogation and you use
the term 'symbolic execution'. Does this mean you treat all input as
symbolic? e.g. everything from a recv() call is marked as 'tainted'
2) If the answer to the previous question is 'yes'; how do you deal
with symbolic read/writes using your O_in/O_out register mechanism? I
can't see this working for memory, as the size of those sets becomes
potentially unbounded (well, bounded by the amount of usable memory)
e.g how do you describe the memory written to by **mov dword ptr
[eax], ebx** if eax is symbolic and dependent on user input? A more
tangible situation might be the case where a child object is created,
then written to memory at a symbolic offset and then later read again.

First of all, SpiderPig in current shape requires the user to pick the
starting point (that was the main idea of it from the beginning). In 
other
words user must specify the register or memory region which is tainted 
(pick
a root of the taint). SpiderPig can taint either memory ___location or CPU
elements like registers, flags etc. etc. Regarding the 4.4 section
(Predicting Data Propagation) the symbolic execution approach (O_in/O_out
variants) refers only to the elements of the CPU architecture - not the
memory locations pointed by them.

OK, but without considering tainting of memory what happens if the
first thing the app does is pass the region marked as 'tainted'
through a 'toUpper' function, and then operates exclusively on that
data? In this case will your data flow graph be empty?

Congratulations i ran SpiderPig for you, its quite something since i havent 
used it like in couple of months :-)
Anyway simple scenario just to not produce weird graph - application does 
following things:
1) take 4 bytes (located at 0x0012FE7C...)
2) execute toupper() on them
3) then bytes are destroyed by simple overwrite ("00401091 MOV DWORD PTR 
SS:[ESP+4],41414141")

Graph is available here:
http://piotrbania.com/all/spiderpig/toupper.png

As you can see initial bytes were destroyed by the same instruction that 
"creates" same memory regions after toupper is executed. Finally the memory 
regions created by toupper() function are destroyed by 0x401091.

No doubt SpiderPig will require some additional modifications, it is still a 
prototype software. However now its time to get some sleep :-)

- pb

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave

By Date

By Thread

Current thread:

• PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case) Piotr Bania (May 18)
  • Re: PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case) nnp (May 18)
    • Re: PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case) Piotr Bania (May 18)
      • Re: PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case) nnp (May 18)
      • Re: PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case) Piotr Bania (May 18)
  • Re: PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case) Fosforo (May 18)
    • Re: PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case) Piotr Bania (May 19)