
Dailydave mailing list archives
Re: PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case)
From: nnp <version5 () gmail com>
Date: Mon, 18 May 2009 20:04:47 +0100
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? I don't think I'd class what you're doing as symbolic execution, unless you're doing something not mentioned in the paper to take into account the semantics of the instructions and their effect on the data/flow control. If you're not, then the use of the term 'symbolic execution' tends to lead to confusion (or maybe I'm just easily confused ;-) ) -- http://www.unprotectedhex.com http://www.smashthestack.org _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
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) 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) Fosforo (May 18)