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

On Thu, 2005-08-04 at 22:02 +0100, Baruch Even wrote:
> Jake Appelbaum wrote:
> > We''d love that some of the debian security team contact us if
they''re
> > interested.
> 
> I''m not part of the Debian security team, only the testing
security
> team, two distinct groups, with roughly the same goal, providing Debian
> with security updates.
> 
> I definitely do not represent anyone else but myself.
> 
> I am not sure that your suggestion is really something that is relevant
> to Debian itself. It seems similar to the Coverity folks offering of bug
> reports to the Linux Kernel folks. Though your suggestion is more
> comprehensive, possibly covering all packages.
> 
> I do think it is an interesting project to do for the general benefit of
> the Linux community. What would be the details of your offering? There
> is obviously the tool itself, and at least I don''t have access to
a
> sparc machine for the work.
We prefer to work with the team leaders of the Debian project at this
time. We don''t want to work against the wishes of the team leaders,
even
though we feel like it could be useful to them.

However it does require that we have their cooperation as it would
require a small amount of their time.

Specifically, we need to build all of the SPARC architecture with
debugging symbols to get the most useful information. Currently we''re
only offering this to the Debian project and only for SPARC.

-- 
Jake Appelbaum <jacob@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/bc1c6e63/attachment.pgp

Jake Appelbaum wrote:
> I''m sure people are a bit skeptical of a project like this and
what kind
> of things it can do. We''re not just doing this because we use
Debian but
> because we want to support Free Software in general.
Sounds like a good idea. Not only will it possibly reveal unpatched bugs
in free software, but it will also give your software quite a stress test.

You don''t need Debian''s approval to do this; just go ahead and
start it
running. I suggest that if you do start finding a lot of security holes,
you talk to MITRE to get CAN numbers for the holes you find. And then go
ahead and report the security bugs in the normal manner.

On Wed, 2005-08-03 at 20:25 -0400, Anthony DeRobertis
wrote:
> Jake Appelbaum wrote:
> 
> > I''m sure people are a bit skeptical of a project like this
and what kind
> > of things it can do. We''re not just doing this because we use
Debian but
> > because we want to support Free Software in general.
> 
> Sounds like a good idea. Not only will it possibly reveal unpatched bugs
> in free software, but it will also give your software quite a stress test.
> 
> You don''t need Debian''s approval to do this; just go
ahead and start it
> running. I suggest that if you do start finding a lot of security holes,
> you talk to MITRE to get CAN numbers for the holes you find. And then go
> ahead and report the security bugs in the normal manner.
While I would love to do this, personally it''s just not feasible for me
to personally scan all of SPARC. Our team is on a pretty tight schedule
of release and we don''t have the spare people power to dedicate them to
scanning all of Debian.

The real issue at hand isn''t just unpacking, uploading to our server or
even verifying the vulnerabilities. To get useful debug output (such as
function names, line numbers, file names, etc) one also needs to compile
the software with ''-g'' (using gcc). While I suppose you could
run the
entire SPARC binary tree through Logiscan without this, it would not be
nearly as useful. A very important part of scanning Debian would be
someone rebuilding everything with debugging information.

-- 
Jake Appelbaum <jacob@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/20050803/0e864ca5/attachment.pgp

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@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

Jake Appelbaum wrote:
> We prefer to work with the team leaders of the Debian project at this
> time. We don''t want to work against the wishes of the team
leaders, even
> though we feel like it could be useful to them.
This generally isn''t how Debian works. Our team leaders are all
volunteers, and are all generally pretty short on free time (at least,
this is what I gather from reading various Debian lists; I don''t
pretend
to speak for any of them). I suggest that if you mail debian-devel you
might be able to find some Debian developers willing to work with you.

However, if you really want to ask official permission to do this ---
which there really isn''t any need, you''re just finding bugs, a
job that
is always welcome (see http://www.debian.org/devel/join/ for an official
statment that "testing packages, as well as reporting and fixing bugs,
is a great help to us"). --- the right guy to contact is the Project
Leader, Branden Robinson, at <leader@debian.org>.
> Specifically, we need to build all of the SPARC architecture with
> debugging symbols to get the most useful information. Currently
we''re
> only offering this to the Debian project and only for SPARC.
I''d suggest doing it on the existing builds on SPARC, and only
rebuilding when you need to -- e.g., when you find something.

Jake Appelbaum wrote:
> I happen to work for a company that''s doing some innovative
development
> in the area of binary static analysis. We have a shipping product that
> is able to find novel exploitable vulnerabilities. The name of the
> company is Logic Library Inc. The product is Logiscan
> ( http://www.logiclibrary.com/solutions/logiscan.php )
>
> I''m sure people are a bit skeptical of a project like this and
what kind
> of things it can do. We''re not just doing this because we use
Debian but
> because we want to support Free Software in general.
> 
> If you are interested, let me know and I can go into more detail. If you
> have any initial questions, feel free to ask me.
The website is rather short on technical details:
- Could you describe your approach? Are you performing abstract interpretation?
- 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? 
- 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?)

Cheers,
        Moritz

Hi there,

I happen to work for a company that''s doing some innovative development
in the area of binary static analysis. We have a shipping product that
is able to find novel exploitable vulnerabilities. The name of the
company is Logic Library Inc. The product is Logiscan
( http://www.logiclibrary.com/solutions/logiscan.php )

A short list of vulnerabilities it can find include: buffer iteration
(as seen with the blaster worm), format strings, buffer overflows
(stack/heap), off by one, SQL injection, cross site scripting and more.

We are able to verify exploitability fairly accurately by fully tracking
user-supplied data throughout the application in our static analysis. We
have some advisories and whitepapers detailing the novel vulnerabilities
we have found in commercial software.

Since we''re using Knoppix as the base for our application
server''s OS,
we''re using lots of Debian Gnu/Linux packages [1]. Knoppix is a pretty
good base for a custom Application server. I can''t plug Knoppix Hacks
enough, it''s very helpful (Disclaimer: I wrote a few hacks in that
book).

After reading about the lack of security resources facing the Debian
team, I thought it would be a helpful to offer the use of our product to
the Debian security team. This can be used for full audit of the SPARC
binary packages in Debian. Stable, testing, unstable, etc.

I''m sure people are a bit skeptical of a project like this and what
kind
of things it can do. We''re not just doing this because we use Debian
but
because we want to support Free Software in general.

If you are interested, let me know and I can go into more detail. If you
have any initial questions, feel free to ask me.

[1] We comply with the GPL for all of the Free Software we''re using,
including mono and the Linux kernel.

Best,
-- 
Jake Appelbaum <jacob@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/20050803/73d91745/attachment.pgp