Re: [SC-L] Compilers

2006-12-27 Thread Tim Hollebeek
 However, not 
 all of the kinds of things should be put in the compiler (how 
 many coders do you know that use the -Wall??!).

All the decent ones???  I remember people talking about Warning 
free with -Wall as a minimal requirement, and personally using 
that standard, over 15 years ago.  And that was just for code
quality reasons.  Granted, many monkeys with keyboards were
pulled into the industry during the 90s IT boom, but are shops
that insist on warning free compiles really that rare?

I'm not sure How can we create secure software in an environment
where people don't even conform to minimalist software engineering
principles? is a helpful topic for discussion as a way forward,
no matter how useful it may be as a source for tool and consulting

Tim Hollebeek
Research Scientist
Teknowledge Corp.

Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.

Re: [SC-L] Coding with errors in mind - a solution?

2006-09-05 Thread Tim Hollebeek

 -Original Message-
 From: Pascal Meunier [mailto:[EMAIL PROTECTED] 
 Sent: Friday, September 01, 2006 7:41 AM
 Cc: Tim Hollebeek;
 Subject: Re: [SC-L] Coding with errors in mind - a solution?
 On 8/31/06 8:05 PM, mikeiscool [EMAIL PROTECTED] wrote:
  His point, I think, is that if you wrap a series of 
 statements in an 
  try/catch block, you might not roll back every statement you needed 
  to, or checked appropriate conditions.
  For example:
  try {
  } catch(Exception e){

 Ah, yes, I can see a bad (or under pressure) programmer 
 lumping together the handling of exceptions that should be 
 handled separately, or making just one giant try block so 
 when there's an exception, even if you specify the type 
 there's still ambiguity as to where it came from and 
 therefore can't handle it properly.  That could be quite a 
 mess.  Thanks.
 Exceptions simplify the code? I don't think so. They also 
 don't reduce 
 code duplication [per se] you need to add extra functions, 
 etc, to do 
 They can simplify the code because
 -as previously mentioned by Tim, they separate error handling 
 from normal logic, so the code is easier to read (it is 
 simpler from a human reader's perspective).

But they only really separate the error handling if you have
one big try block, and that can make proper diagnosis difficult.
For example, in the above case, if you get a FileNotFound exception,
did it come from openFile or moveFile?  It may be possible to
figure that out, but the extra logic will be more than you would
have had if you had just checked the return value of the call.

 -if an exception is handled several call layers above, you 
 don't have to copy/translate and relay the error at each 
 layer, with the attached loss of context and possible 
 translation mistakes (error #3 in one layer/module may mean 
 something different in another...).  So, there's less 
 (duplicated) code.

But the intervening stack frames have to be (painfully) aware of
the fact that they might terminate abruptly.  Experience has shown
that getting this right is very hard, offsetting the benefits of
being able to quickly pop back up to a frame where the error can
be handled.

 -It is common (and bad, IMO) practice for errors to be 
 signified to callers by returning an out of range or 
 different type (or null) value when something else is 
 semantically expected.

This is especially true when there is only one value available
for all errors (like zero).  GetLastError/errno is a silly
substitute for not having another 'out' parameter, justified
on the basis that sometimes you don't care what the error was.
Except that you should!

Exceptions can be useful, but they really aren't what you want for
error handling, and are often cause as many problems as they cause.

What you really want is for all the (partial) side effects of a
function to disappear when it unrolls, but that's hard to do.
Even cleanup code is tough to get right due to the fact that
(A)(B)(A^-1) != B
(can we reboot the universe with that feature disabled?  
It causes problems all over the place ...)

That said, Windows Vista will have transactions for file system/
registry modifications, so perhaps that will make life a bit easier...


Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -

Re: [SC-L] How can we stop the spreading insecure coding examples attraining classes, etc.?

2006-08-30 Thread Tim Hollebeek

Really, the root of the problem is the fact that the simple version
is short and easy to understand, and the secure version is five
times longer and completely unreadable.  While there always is some
additional complexity inherent in a secure version, it is nowhere
near as bad as current toolkits make it seem.

Demo code generally demonstrates some fairly powerful capability;
the reason it is often short and sweet is because lots of effort
has gone into making it possible to do useful things with minimal
effort.  Unfortunately, it is often the case that much less effort
has gone into making it possible to do the same thing securely, so
that code is quite a bit longer.  You're right, if there was more
of a pushback against broken demo code, maybe more effort would go
into making it easy to do things securely, instead of insecurely.

I think part of the problem is that people have fallen into the
trap of thinking that security is supposed to be hard and that
checking all your errors is supposed to bloat your code by a factor
of five, instead of wondering why library functions are designed
in such a way that omitting complex logic around them fails in an
insecure way.  Secure code can be short and sweet, too, just not
with most of the languages and tools that are currently popular.

This is an old, old problem.  strcpy is insecure, and any code
involving strncpy or a length check will be longer and/or more
complex.  But this is really just an artifact of the fact that
buffers don't know their own length, making an additional check 
necessary.  There is no reason why the secure version couldn't 
have been just as short and sweet, it just wasn't done.

Tim Hollebeek
Research Scientist
Teknowledge, Corp.

Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -

RE: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-04 Thread Tim Hollebeek
 $ java -cp . -noverify HelloWorld
 # An unexpected error has been detected by HotSpot Virtual Machine:
 #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x6d7415fb, 
 pid=3512, tid=2260 # # Java VM: Java HotSpot(TM) Client VM 
 (1.5.0_06-b05 mixed mode) # Problematic frame:
 # V  [jvm.dll+0x615fb]

Note that EXCEPTION_ACCESS_VIOLATION is the Windows equivalent of a
segmentation violation; this isn't the Verifier complaining, it's
the JVM crashing.

The fact that editing the .class file allows you to produce one that
causes the JVM to crash is pretty strong evidence the verifier was
NOT used to validate the file.

Tim Hollebeek
Research Scientist
Teknowledge Corp.

Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -