RE: malicious code

From: Jason Coombs (jasoncat_private)
Date: Tue Jan 28 2003 - 00:07:16 PST

  • Next message: Michal Zalewski: "Re: safe strcpy()?"

    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
    jasoncat_private
    
    -----Original Message-----
    From: listsat_private [mailto:listsat_private]
    Sent: Monday, January 27, 2003 9:20 PM
    To: jsquaredat_private; secprogat_private
    Subject: Re: malicious code
    
    
    
    From: "Jeff Williams" <jsquaredat_private>
    
    > 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.
    



    This archive was generated by hypermail 2b30 : Tue Jan 28 2003 - 00:17:43 PST