full-disclosure - [inbox] Re: RE: Linux (in)security

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1098519357.1067184921@[192.168.2.119]>
From: pauls at utdallas.edu (Paul Schmehl)
Subject: [inbox] Re: RE: Linux (in)security

--On Sunday, October 26, 2003 12:45 PM -0500 Bill Royds 
<full-disclosure@...ds.net> wrote:

> 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.

You mean, as a programmer, it's not possible to write a library function 
that checks string lengths and simply call it for every buffer?

Like (in pseudocode)?

chk_str_len(buf) {
  if (buf>256) {
    print "Error!  Input larger than allocated buffer!"
    return err_num
  }else{
    return 0
  }

Granted you probably want to be more gracious handling errors than an 
abrupt exit and you'd probably want to use a case statement to allow for 
checking numerous different allowed lengths, but seriously - is a language 
supposed to be goof proof?  Or are programmers supposed to learn how to do 
it right?

How hard is it, really, to add a couple of lines to each input call - ok = 
chk_str_len(buf), if {ok == 0} continue}else{ handle_error(ok)}?

(I'm sure there are more efficient ways to handle this than my simplistic 
suggestion, but the point remains - handling buffer overflows should be 
trivial to write in C.  The problem is that programmers simply don't think 
about it (or don't even know about it) when they're writing the code.

>  Another problem with C is that there is not an inherent mechanism to
> match the types of parameters in a fnction 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.
>
Isn't it the programmer's job to *know* what types he's using and what his 
pointers refer to?  And if he can't know, to error check?  It think we'd be 
vastly better off teaching how to program properly than we would be trying 
to devise a language that is idiot-proof. b

Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu