Re: source code "forensic" practices
> * Yaroslav Halchenko:
> > The question is: are there any helper tools for doing source code
> > validation subject to possibly available snippets of code which might be
> > for illegal activity (ie sending out private information, or serve as
> > backdoors, etc)?
> There are several commercial bug finding tools and services. I don't
> know how good they are at detecting logic bombs and similar things.
some googling helped me to find some interesting pieces
from 1995: MCF: A Malicious Code Filter
http://seclab.cs.ucdavis.edu/papers/llo95.ps
Unfortunately articles such as "Detecting and Removing Malicious Code"
http://www.securityfocus.com/infocus/1610
do not list about any source code analysis.
This one
http://www.dsv.su.se/research/seclab/pages/pdf-files/2005-x-208.pdf
seems to be quite nice but talks about MS Access source code analysis
but it referred me to another interesting reading
Secure Software Development and Code Analysis Tools
http://www.sans.org/reading_room/whitepapers/securecode/389.php
Unfortunately I have to agree with
When a programmer intends to cause harm developing software, he will try to obfuscate
the code to hide it in many line codes. There are even automated tools that any
programmer could use to obfuscate code (they can also be used to avoid reverse
engineering). Essentially, when an auditor finds code with non-sense structures or that is
particularly difficult to follow it could point him to two different conclusions, first, that
the programmer intends to obfuscate the code, or second, that the system wasn't properly
programmed, since it not only makes security analysis complex, but maintenance as well.
Many times we hear that so many tools have been developed and the complexity of
choosing the right one makes it even harder to effectively protect an information
technology environment. Ashyby's law on requisite variety, "variety kills variety"
(referenced by Louise Yngstr�m in [LY03]) is in my opinion a realistic approach to
security in today's environment. We can not today, and probably never will, rely on a
silver bullet tool that will resolve all our security issues. This is due to the high level of
complexity we are facing; therefore we need several tools that can cope with several
different and specific problems.
Just wanted to share and see if there is any opinion/ideas on how to
give at least some assurance that the software which we package is safe
to use. Most of the time we are to rely on how obvious is a good intent
of the upstream authors from our subjective judgment.
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
Reply to: