Related articles |
---|
Dealing with load/store instructions on static tainted flow analysis gabrielquadros@hotmail.com (Gabriel Quadros) (2011-06-06) |
Re: Dealing with load/store instructions on static tainted flow analys gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-06-07) |
Re: Dealing with load/store instructions on static tainted flow analys kym@kymhorsell.com (2011-06-08) |
Re: Dealing with load/store instructions on static tainted flow analys gneuner2@comcast.net (George Neuner) (2011-06-09) |
Re: Dealing with load/store instructions on static tainted flow analys martin@gkc.org.uk (Martin Ward) (2011-06-12) |
From: | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
Newsgroups: | comp.compilers |
Date: | Tue, 7 Jun 2011 09:04:08 +0000 (UTC) |
Organization: | A noiseless patient Spider |
References: | 11-06-010 |
Keywords: | analysis, Java |
Posted-Date: | 11 Jun 2011 13:50:41 EDT |
Gabriel Quadros <gabrielquadros@hotmail.com> wrote:
> I am trying to implement a pass to detect information leak in
> programs. The problem is a variation of static tainted-flow analysis:
> I have some source functions, sink functions and sanitizers. I want to
> know if it is possible for data to flow from source to sink without
> going across a sanitizer.
(snip)
> In particular, if you could point me some paper that does it,
> that would be great.
It isn't exactly the same, but I would start looking at the Java
class verifier.
Well, for one Java requires bounds checking, so you can be sure
that only references to the same array would leak. Java also
requires the verifier to detect references that load/store the
wrong data type, such as treating a double as two ints.
(I believe it detects both stack and heap accesses.)
-- glen
Return to the
comp.compilers page.
Search the
comp.compilers archives again.