RE: malicious code

From: Jason Coombs (jasonc@science.org)
Date: 01/28/03

  • Next message: Michal Zalewski: "Re: safe strcpy()?" 
    From: "Jason Coombs" <jasonc@science.org>
To: <lists@notatla.demon.co.uk>, <jsquared@erols.com>, <secprog@securityfocus.com>
Date: Mon, 27 Jan 2003 22:07:16 -1000

    My experience has been that if you simply ask yourself the question "what
    should this program NOT do/allow?" and then go try to make it do/allow
    whatever your answer is, often times you will find security flaws
    immediately.

    Programmers are so busy focusing on coding to specs, adding features that
    make software do things, that they usually don't consider adequately the
    anti-spec: the list of things the software should never do.

    Vulnerability analysis should start with an anti-spec and end with automated
    scanning for unintentional errors. If anyone put code in the system to
    enable it to do things it should never do, you'll usually find that code by
    going straight to the place it must be in order to have its intended bad
    function. There are only so many ways for bad code to get involved in
    interprocess communication, and it's pretty easy to analyze all such
    communication pathways in detail -- even without access to source code. Many
    forensic analysts prefer to read assembly anyway; source code is an
    illusion, only approximating what a program is capable of doing or being
    forced to do.

    Jason Coombs
    jasonc@science.org

    -----Original Message-----
    From: lists@notatla.demon.co.uk [mailto:lists@notatla.demon.co.uk]
    Sent: Monday, January 27, 2003 9:20 PM
    To: jsquared@erols.com; secprog@securityfocus.com
    Subject: Re: malicious code

    From: "Jeff Williams" <jsquared@erols.com>

    > I'm not looking for technology. It is going to be a very long time before
    > software can even find unintentional security errors. I was hoping that
    > someone had done some research on how human code review can find malicious
    > logic. Is the problem exactly the same as searching for inadvertent
    > security flaws, or are there specialized techniques for searching out
    > malicious logic.

    ISTR one malicious logic of recent years (TCP wrapper trojan, 1999 ?) had
    different behaviour according to the source port of the connection.

    Calling crypt(3) and comparing the result to a stored string might be
    another indicator.

    Features such as starting a shell (or anything else) in a program you know
    shouldn't do that would be another. That's one of the things you can
    prevent with technology (such as SubDomain).

    I agree that anything approaching comprehensive detection is hopeless.

    Relevant Pages

    • Re: Secure or insecure
      ... not been scrutinized to the extent that Open Source code has. ... inherently insecure code, once released to the public, can show its ... to catch up on "fixing" any security flaws found in the released code ...
      (alt.os.linux.suse)
    • Re: secprog Digest 2 Apr 2005 19:17:38 -0000 Issue 293
      ... >> analysis to find security flaws. ... > A good introductory article on static analysis of source code for ... > analyzing security issues can be found at ...
      (SecProg)