Re: [inbox] Re: RE: Linux (in)security

["Gregory A. Gilliss" <ggilliss () netpublishing com>]

Okay, first how about a mea culpa - are you part of the OpenBSD group?
Because this sounds suspiciously like the kind of observation, albeit
justified, that would be posted by them. No slander intended, just
curious.

Second, I disagree, and here's why:

TTTT, regardless of what language/tool the OS is written in, whether it be
assembler (and I know because I've written several KLOC of it) or C or
whatever-your-strong-typed-language-of-choice-is, if the programmer didn't
have security in their head (and whom among us did, BITD), then the code
will be rife with whatever race conditions or string formatting errors or
buffer overflows that might have unconsciously crept in because we were
busy trying to get it to work and get it out the door.

Some people will argue that a strong typed programming language will 
prohibit the kind of boundary and buffer overflow conditions that are so 
prevalent in today's vulnerabilities. My response to that is two words: 
JAVA beans. Strong typing is no guarantee that the tool/language prohibits
any sort of out-of-band behavior, mostly because time-to-market was the
rule and there still is no such thing as "thorough testing".

Now, I could see an argument being made for non-disclosure of OS source 
code (IBM has yet to release the source code for VM or MVS or RACF - who 
*knows* what security vulnerabilities lurk beneath the skin of those
behemoths) along these lines. However we've beaten the non-disclosure
horse to death several times here and elsewhere, so please let us not
be bogged down once again. Full disclosure, period. Next.

My personal preference is what has and will continue to happen - namely 
distributed code audits courtesy of amateur and professional security
experts. Mudge and Aleph1 found buffer overflows BITD. Route discovered
SYN flooding. No idea who claims credit for the first race condition - 
any takers? Point is, software comes out of the box and gets reviewed
and gets improved and feedback is generated. This has worked for years - 
I see no reason why it should fail to work. UNLESS...unless the community
attempts to implement artificial barriers, namely restriction of posting
of vulnerabilities and information hiding and partial or no disclosure.
Notice where a significant number of the new "threats" originate - Russia
and Eastern Europe. No restrictions on full disclosure there. R&D for free.
That's what has worked, and that is what will continue to work, IMHBAO.

G

On or about 2003.10.26 12:45:36 +0000, Bill Royds (full-disclosure () royds net) said:

> Actually there is a significant difference between OS that get a large
> number of vulnerabilities released like Windows, Linux etc. and those OS
> like VMS and OS/400 that do not.
> The real difference is the programming language used to write the code. The
> C programming language used for Windows, Linux etc. is inherently insecure.
> The C string is an invitation to a buffer overflow. It has no bounds
> checking by default so each use of it (copy, string search ...)  must be
> checked for a buffer overflow.
> A Pascal string has an explicit length associated with it so buffer
> overflows are much less likely (there are still the problems of the
> underlying OS written in C).
>  Another problem with C is that there is not an inherent mechanism to match
> the types of parameters in a function call with the types of the actual
> parameters used, especially when calling with arrays or pointers. A pointer
> argument is inherently insecure because it could point to anything. The only
> mechanism for passing parameters that need to be changed by a function is a
> pointer in C (others have value/result where the subroutine makes a local
> copy modifies that then returns the modified value for caller to use).
>     If we really want to have more secure software we need to look at the
> tools we use to write it, not just at the platforms it runs on.

-- 
Gregory A. Gilliss, CISSP                             Telephone: 1 650 872 2420
Computer Engineering                                   E-mail: greg () gilliss com
Computer Security                                                ICQ: 123710561
Software Development                          WWW: http://www.gilliss.com/greg/
PGP Key fingerprint 2F 0B 70 AE 5F 8E 71 7A 2D 86 52 BA B7 83 D9 B4 14 0E 8C A3

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html