RE: malicious code

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

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

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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. Received on Tue Jan 28 03:17:54 2003