Vulnerability Development mailing list archives
RE: Techniques for Vulneability discovery
From: John Daniele <johnd () tsintel com>
Date: Sun, 7 Apr 2002 15:46:27 -0400 (EDT)
What you described is more akin to 'functional design' testing than vulnerability analysis. While there definately are elements of black box testing as you described, within the vulnerability analysis process, they are complemented by the application of reverse engineering tools and techniques. Tools such as gdb, strace/truss, Softice and IDA Pro are used to intercept a process or disassemble a function to gain a better, low-level understanding of what the application is actually doing. At that point, the tester will be able to determine whether a function has been implemented correctly and performs as documented or identify potential points of manipulation to force the application to do something it was never intended to do. When application code is available for review, the tester could develop scripts to parse through the code to identify obvious points of failure such as the misuse of certain functions (improper or no bounds checking), signedness issues, memory mismanagement, etc. etc. As well, they would manually review code pertaining to critical functions or activities such as authentication, authorization, etc. There are commercial code audit tools (such as L0pht^H^H^H@stake's slint) available to ASSIST the tester in this job, but IMHO should never be used to replace the role of a security-minded testing team. Security QA (not functional design / QA testing) is something that is severely lacking in all development shops. _________________________________________ John Daniele Technical Security & Intelligence Toronto, ON Voice: (416) 605-2041 E-mail: johnd () tsintel com Web: http://www.tsintel.com On Fri, 5 Apr 2002, W. Lee Schexnaider wrote:
Hello, As a software tester I might offer some information. I am primarily a "black box" tester, which means I do not go into the code. I use the product as a user would. We do some automated testing with tools like Winrunner. However, many testers do exploratory or ad hoc testing for these items. This involves using the program thinking of ways to break it, theny trying them and documenting the results. In many cases there are requirements to test against, but these rarely find the type of problems you are addressing. However, requirements and written test cases can ensure that the bug does not reappear due to code reuse or old code getting into a build. Testing can be a basic as holding down a key in a field for two minutes to see if a buffer overflow happened (it did). I include things like the entry of bad data and other items in my test cases.From a customer standpoint, many people do not allow new code to be placed on production systems. They have separate test systems where the program is exercised before it can go on to production system. Such a system can lend itself to automating test cases for new version of existing software.It really comes down to having people who like to break software. These do not have to be programmers or IT admins. My background is in newspaper journalism. In some cases specific technical knowledge may be needed. But often the technical person needs to be teamed with someone who thinks more like a user. If a programmer says "someone would never do that" in reference to an action with a program, you can bet everything you own that at some time somebody will. Take the classic case of a video card that if it had more than one monitor connected to it, the monitors would catch fire! -----Original Message----- From: kaipower [mailto:kaipower () subdimension com] Sent: Thursday, April 04, 2002 7:05 PM To: security-basics () securityfocus com; vuln-dev () security-focus com; vuln-dev () securityfocus com Subject: Techniques for Vulneability discovery Hi, After reading the mailing list for quite a while, there is a burning question which I kept asking myself: How do experts discover vulnerabilities in a system/software? Some categories of vulnerabilities that I am aware of: 1) Buffer overflow (Stack or Heap) 2) Mal access control and Trust management 3) Cross site scripting 4) Unexpected input - e.g. SQL injection? 5) Race conditions 6) password authentication Do people just run scripts to brute force to find vulnerabilities? (as in the case of Buffer overflows) Or do they do a reverse engineer of the software? How relevant is reverse engineering in this context? Anybody out there care to give a methodology/strategy in finding vulnerabilities? Mike _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com __________________________________________________ D O T E A S Y - "Join the web hosting revolution!" http://www.doteasy.com
Current thread:
- RE: Techniques for Vulneability discovery, (continued)
- RE: Techniques for Vulneability discovery Pedro Hugo (Apr 05)
- Re: RE: Techniques for Vulneability discovery LS (Apr 08)
- RE: Techniques for Vulneability discovery Pedro Hugo (Apr 05)
- RE: Techniques for Vulneability discovery Marc Maiffret (Apr 05)
- Re: Techniques for Vulneability discovery NoCoNFLiC (Apr 05)
- Re: Techniques for Vulneability discovery 3APA3A (Apr 06)
- Re: Techniques for Vulneability discovery Rafael Anschau (Apr 09)
- Re: Techniques for Vulneability discovery GomoR (Apr 09)
- RE: Techniques for Vulneability discovery David Hawley (Apr 10)
- RE: Techniques for Vulneability discovery Ed Moyle (Apr 05)
- RE: Techniques for Vulneability discovery W. Lee Schexnaider (Apr 05)
- RE: Techniques for Vulneability discovery John Daniele (Apr 07)
- Re: Techniques for Vulneability discovery Ivan Arce (Apr 05)
- RE: Techniques for Vulneability discovery Guillermo Marro (Apr 05)