[Secure-testing-team] A full audit of SPARC arch by our static binary analysis tool

[Jake Appelbaum]

On Thu, 2005-08-04 at 10:18 +0200, Moritz Muehlenhoff wrote:
> The website is rather short on technical details:
> - Could you describe your approach? Are you performing abstract interpretation?

I suppose you could call it an abstract interpretation, much like the
way the Java VM bytecode verifier works. The difference, other than that
we operate on non-Java opcodes, is that we also do inter-function value
tracking through both bottom-up and top-down static analysis. Does this
answer your question?

> - How do you handle the backtracking from a potentially detected vulnerability
>   in the assembly back to the source level? Do you require debug symbols to
>   be present? 

We use stabs or DWARF2 standard debug information, if present. Yes,
debug symbols are required to report the line of source code. Without
it, we can still report things but will only be able to give the binary
offset and sometimes the function name.

> - Does you solution withstand compiler optimizations? (Which should be semantically
>   equal to the non-optimized version, but will might yield totally different
>   patterns on the assembly level?)

Yes, it does. We test with -O[0-5] with gcc 2.95, gcc 3.4.2, and
platform-specific compilers (e.g. suncc 5.7). Because we do a high-level
emulation of the opcodes, the results between optimized and
non-optimized binaries are generally the same except where inlining
changes the function a vulnerable item may be reported in.

So, while you would have to compile the debian SPARC binaries with
symbols to get the most directly useful reporting, you don't have to do
any special optimizations. You could choose to just scan the SPARC
binaries as-is and then resolve the binary offsets to source file/line
after the fact via some other means.

Let me know if you have any other questions.

We'd love that some of the debian security team contact us if they're
interested.

-- 
Jake Appelbaum <jacob at appelbaum.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050804/849200c5/attachment.pgp