Re: Privilege-escalation attacks on NT-based Windows are unfixable

From: Alun Jones (alun@texis.com)
Date: 08/23/02 

From: alun@texis.com (Alun Jones)
Date: Fri, 23 Aug 2002 18:15:55 GMT

In article <ak5s74$2t42$2@agate.berkeley.edu>, daw@mozart.cs.berkeley.edu
(David Wagner) wrote:
>Barry Margolin wrote:
>>But given that programmers have *chosen* to program in a language with
>>these known flaws, they are implicitly taking on the resposibility of doing
>>their own checking.
>
>In theory, maybe. In practice, I don't buy it. The alternatives
>have many other disadvantages, which might outweigh the existence of
>buffer overruns. The fact is, the C language and libraries are flawed
>by the fact that the contain such pitfalls. We can give the programmer
>some of the blame for knowingly using a flawed language, but we should
>also pin a good deal of the blame on the flawed language itself, too.

And yet, the language providers will essentially be unable to fix the flaw in
the language, because of the large number of people out there that use strcpy
et al.

Assigning blame is considerably less important than producing and distributing
fixes. If I have a program that doesn't check a buffer passed into strcpy,
then I'm not going to wait for the language standards people to come up with a
library that doesn't include strcpy, then wait for my compiler vendor to obey
that standard and remove backward-compatibility switches, I'm going to fix the
buffer check.

Then, too, there's the argument that strcpy is not a flaw in the language - if
you have a function that's documented to scan for the first null-byte, and
copy everything up to and including that byte into the destination, then you
should, as a secure programmer, be aware that every time you call strcpy, you
must have checked the destination is big enough to hold it! If strcpy didn't
exist, someone would invent it, and the problem would still exist. Trying to
prevent bounds overflow is a Sisyphean task - each time you try to stop it by
preventing the use of one or other function, someone comes up with a new way
to cause it, or rewrites the proscribed function. I've seen a company #define
strcpy as SAFE_STRCPY, and provide a strcpy function that asserted and
terminated when a target string was not big enough, then one of their
employees goes and writes a different SAFE_STRCPY that, well, isn't safe, to
get around an imagined problem, and then leave it there for later programmers
to get into trouble with.

At some point, the application programmers have got to stop saying "the
operating system / programming language _let_ me do something stupid - waah!",
and admit that many of the mistakes we make and inflict on the world are
because we weren't thinking completely at the time of writing the code.

Alun.
~~~~

[Please don't email posters, if a Usenet response is appropriate.] 

-- 
Texas Imperial Software   | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place   | http://www.wftpd.com or email alun@texis.com
Cedar Park TX 78613-1419  | VISA/MC accepted.  NT-based sites, be sure to
Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for XP/2000/NT.

Relevant Pages

  • Re: Privilege-escalation attacks on NT-based Windows are unfixable
    ... the C language and libraries are flawed ... >also pin a good deal of the blame on the flawed language itself, ... If I have a program that doesn't check a buffer passed into strcpy, ... should, as a secure programmer, be aware that every time you call strcpy, you ...
    (comp.security.misc)
  • Re: Python or PHP?
    ... > every language here and there more ways to do something. ... The best the programmer can do, as you imply, is to ... parse out into proper perl expressions. ... > lists, dictionaries, etc. etc. ...
    (comp.lang.python)
  • Re: Python or PHP?
    ... >> every language here and there more ways to do something. ... The best the programmer can do, as you imply, is to ... I am curious of a list of extraneous methods in Perl (more about the ... I just had a glance on Python, ...
    (comp.lang.python)
  • Re: The War On HLA
    ... Take a look at the HLA compile-time language. ... Macros can be abused just like any other language feature. ... I find it amusing, however, that HLL programmers (e.g., Delphi, ... > feature is left to the programmer to invent his own uses for. ...
    (alt.lang.asm)
  • Re: functions as objects
    ... many explicit casts. ... clearly the programmer shall *explicitly* resolve the issue. ... the server end is currently itself written mostly in C, but there was some intention of moving more of it over to script code (hell, theoretically I made the script language for *some* reason...). ... You could say that int inherit "=" from long, ...
    (comp.programming)