WebApp Sec mailing list archives
RE: Code Complexity vs. Security
From: "Michael Silk" <michaels () phg com au>
Date: Tue, 27 Jul 2004 12:53:10 +1000
Hi Mark, I don't see that Cyclomatic Complexity will lead to greater readability, readability comes more from appropriate variable names, appropriate variable usage, and comments. Most of the code I read that is difficult to understand/follow is due to extremely weird usage of variable names and just strange general overall design of the application and algorithms, not the physical number of brackets or branches. For example even consider the code from one of the obfuscated c code competition: http://www.au.ioccc.org/2001/coupard.c It doesn't seem to be very Cycolmatically complex, but god help me if I ever had to change something in that code. -- Michael -----Original Message----- From: Mark Mcdonald [mailto:m.mcdonald () cgl com au] Sent: Tuesday, 27 July 2004 11:26 AM To: Suha Demir CAN; webappsec () securityfocus com Subject: RE: Code Complexity vs. Security Here's some oOther metrics I've studied, although they were demonstrated for estimating the number of defects, they could be just as easily applied to security defects. McCabes Cyclomatic Complexity is the number of independent paths through a given method, calculated using a connected graph of the method, and this: V(G) = e - n + 2 Where e is the number of edges in the graph, and n is the number of nodes. function abc() { alert('w00t'); if (a < b) c(); } Is graphed: O | o | \ | o | / O e = 4 n = 4 V(G) = 4 - 4 + 2 = 2 ie, there are 2 independent paths through this method. An alternative formula is just V(G) = d + 1, where d is the numebr of decision nodes (if, for, while, etc.) - however this fails when the decision nodes have more than 2 paths (case statements). Cyclomatic complexity is also an /excellent/ measure of code readability (maintainability) and should be kept under about 12 (ymmv) per method. Other metrics (not necessarily complexity) include fan-in/out (fan in being the number of calls TO a given method, fan out being the number of calls FROM the given method), Depth of Inheritance Tree (DIT), cohesion & coupling (high cohesion is good, high coupling is bad, cohesion is the "measure" of independence of a module and coupling is the interdependance, see http://c2.com/cgi/wiki?CouplingAndCohesion) It's fairly trivial to code tools to calculate metrics (such as cyclomatic complexity and fan in/out) from byte code (see http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html) or source code (using a tool such as javacc), and I would love to see some results from people regarding security. HTH Mark Mark McDonald | CGL i.s. | web developer -----Original Message----- From: Suha Demir CAN [mailto:sdcan () gsu linux org tr] Sent: Monday, 26 July 2004 12:19 AM To: David King Cc: webappsec () securityfocus com Subject: Re: Code Complexity vs. Security The authors state that (paraphrasing): "estimates are anywhere between 5 to 50 bugs per KLOC (thousand lines of code) in that book. The numbers corresponding to a system that has undergone rigourous quality assurance and a system that has only been feature tested, like most commercial software." they also include LOC counts for some software systems, Windows XP (40M), Space Station (40M), Linux (1,5M), Windows95 (<5M) etc I cant think of any code complexity metrics other than loc, and even that isnt most satisfying. Can anyone think of any general one ? IMHO, it wouldnt be wrong to think more locs more bugs, as a general guideline. The number and nature of entry points to the program can also have a value in determining the risk level the software is exposed to. Suha Demir Can ---------------------------------------------------------------------- "When the game is over, the king and the pawn go in the same box" -----> sdcan <----- GCS d? s:+>: a-- C++(++++)$ UL+++ P+ L+++ E---- W+(++) N+() o? K? w(---) !0 M-(+) !V PS+ PE- Y+ PGP t- 5? X-(+) R+(+++) tv b++ DI D+ G++ e+>++ h-(!) r* y+ ---------------------------------------------------------------------- On Sat, 24 Jul 2004, David King wrote:
I remember there was a section on this near the beginning of the book "Exploiting Software: How to Break Code" (Greg Hoglund and Gary McGraw). If I remember right they site a couple of studies and they seem to believe the number of lines of code is the one of the best indicators of the number of bugs the software will have. Dave King www.thesecure.net On Sat, 24 Jul 2004 20:36:07 -0600, David King <davewking () gmail com> wrote:I remember in the book "Exploiting Software: How to Break Code" (Greg Hoglund and Gary McGraw) there was a section on this near the beginning of the book. If I remember right they site a couple of studies and they seem to believe the number of lines of code is the one of the best indicators of the number of bugs the software will have. Dave King www.thesecure.net On Fri, 23 Jul 2004 21:25:20 +0000, Gunnar Peterson <gunnar () arctecgroup net> wrote:Dan Geer's Blackhat Windows keynote talk last January charted lines of code against vulnerabilities over time. LOC is not complexity per se, but it is an indicator. Quoting Mark Curphey <mark () curphey com>:Has anyone seen any good studies that analytically compare the security quality of code to code complexity ?
*** DISCLAIMER **** This e-mail and any attachments to it are confidential. If you receive them in error, please tell us immediately and delete them. You must not retain, distribute, disclose or otherwise use any information contained in them. Before opening or using any attachments with this e-mail you should check them for viruses and other defects. The sender does not warrant that they will be free from computer viruses or other defects. ******************* *** DISCLAIMER **** This e-mail and any attachments to it are confidential. If you receive them in error, please tell us immediately and delete them. You must not retain, distribute, disclose or otherwise use any information contained in them. Before opening or using any attachments with this e-mail you should check them for viruses and other defects. The sender does not warrant that they will be free from computer viruses or other defects. ******************* This email message and accompanying data may contain information that is confidential and/or subject to legal privilege. If you are not the intended recipient, you are notified that any use, dissemination, distribution or copying of this message or data is prohibited. If you have received this email message in error, please notify us immediately and erase all copies of this message and attachments. This email is for your convenience only, you should not rely on any information contained herein for contractual or legal purposes. You should only rely on information and/or instructions in writing and on company letterhead signed by authorised persons.
Current thread:
- Re: Code Complexity vs. Security, (continued)
- Re: Code Complexity vs. Security athena (Jul 26)
- Re: Code Complexity vs. Security Ed Moyle (Jul 26)
- RE: Code Complexity vs. Security Mark Curphey (Jul 25)
- Re: Code Complexity vs. Security Adam Shostack (Jul 25)
- Re: Code Complexity vs. Security Skip Carter (Jul 26)
- Re: Code Complexity vs. Security Martin Mačok (Jul 28)