RE: Code Complexity vs. Security

["Michael Silk" <michaels () phg com au>]

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.