Privilege-escalation attacks on NT-based Windows are unfixable 
Author Message
 Privilege-escalation attacks on NT-based Windows are unfixable

[fu-t set]

in comp.security.misc i read:

[a discussion about the problems, particularly security related, inherent
in the use of strings in c, in which it is suggested that some features or
library routines be eliminated or revised]

Quote:
>I'm not a language designer; I have neither the interest nor the
>education to do this.

and yet you are making suggestions as if you were one.

if all that you really want done is that programmers be warned about the
use of some features of the language or functions in the standard library
then lobby schools and teachers, and book, compiler and library writers to
do something appropriate, e.g., compilers could issue a diagnostic, books
and classes could eschew their use and perhaps even have a significant
chapter or course time devoted to describing the pitfalls, even libraries
might produce diagnostics.

--
bringing you boring signatures for 17 years



Sun, 13 Feb 2005 02:55:56 GMT  
 Privilege-escalation attacks on NT-based Windows are unfixable
On Tue, 27 Aug 2002 14:55:56 -0400, those who know me have no need of my

Quote:

> in comp.security.misc i read:

> [a discussion about the problems, particularly security related,
> inherent in the use of strings in c, in which it is suggested that
> some features or library routines be eliminated or revised]

>>I'm not a language designer; I have neither the interest nor the
>>education to do this.

> and yet you are making suggestions as if you were one.

Revising certain features of a language is a far cry from designing one
from scratch.  I certainly am qualified to do the former.

Quote:
> if all that you really want done is that programmers be warned about
> the use of some features of the language or functions in the standard
> library then lobby schools and teachers, and book, compiler and
> library writers to do something appropriate, e.g., compilers could
> issue a diagnostic, books and classes could eschew their use and
> perhaps even have a significant chapter or course time devoted to
> describing the pitfalls, even libraries might produce diagnostics.

Some constructs are so dangerous it's hard or impossible to use them
properly.  Take gets for example, there is absolutely no way to prevent
a buffer overflow if you call gets.  Education is not enough; these
functions should be removed from the language entirely.  There are
safer alternatives that accomplish the same thing, i.e. fgets.

--
Edward Elliott



Sun, 13 Feb 2005 04:36:21 GMT  
 Privilege-escalation attacks on NT-based Windows are unfixable

Quote:


> > in comp.security.misc i read:

> > [a discussion about the problems, particularly security related,
> > inherent in the use of strings in c, in which it is suggested that
> > some features or library routines be eliminated or revised]

> >>I'm not a language designer; I have neither the interest nor the
> >>education to do this.

> > and yet you are making suggestions as if you were one.

> Revising certain features of a language is a far cry from designing one
> from scratch.  I certainly am qualified to do the former.

    The best way to support the assertion is by direct demonstration.
The body that writes and maintains the C Standard appears to be more
strongly influenced by actual implementations of proposed features than
by theoretical arguments for and against.  If you're interested in
revising C to make it safer/better/sexier, a practical starting point
would be to get hold of the gcc and glibc source and start implementing
your revisions.  If you're advocating removal or change of existing
features, I suppose the acid test would be to pass a large body of
pre-existing source code through your new compiler to demonstrate
that identifying and fixing the breakage is relatively painless --
and if the process exposed long-hidden latent bugs in popular programs,
that might also argue in favor of the changes you propose.

Quote:
> Some constructs are so dangerous it's hard or impossible to use them
> properly.  Take gets for example, there is absolutely no way to prevent
> a buffer overflow if you call gets.  Education is not enough; these
> functions should be removed from the language entirely.  There are
> safer alternatives that accomplish the same thing, i.e. fgets.

    A practical difficulty: The Standard defines the language, but
cannot require conformance.  Compiler vendors are under considerable
pressure not to fix what ain't (believed to be) broken.  For example,
a <math.h> that defines the macro M_PI is non-conforming -- but take
it away at your peril; the math mobsters will want your {*filter*} ...

    The case of gets() is particularly sad, because the Standard
requires implementations to provide it.  But if the Standard suddenly
redefined gets() as an alias for abort(), would the implementors go
ahead and do it?  I rather suspect that any who actually did so would
also find it necessary to offer special switches or whatever to allow
gets() to function just as it always has, despite what the Standard
might say.  Meaning, in effect, that the Standard's ban on gets()
would be entirely ineffectual.

    Data point: The company I work for offers implementations of
several languages, one of which (not C) relatively recently adopted
its first official Standard.  In due time, we produced a version
implementing the newly-adopted Standard -- and we've been taking flak
ever since for breaking people's "perfectly good" pre-Standard non-
Standard programs.

--



Sun, 13 Feb 2005 05:52:08 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. SetLocalTime() privilege problem in NT

2. SetLocalTime() privilege problem under NT

3. API (NT Server 4.0): How to get privileges?

4. NT privileges

5. Connection points between a VB COM-based and ATL COM-based (NT Service) MTA

6. Unfixable warnings with Lint

7. Getting MAC Address in WIndows 98 and NT/2000/NT

8. Determine resource used by Windows NT / System, when device is not registered in NT

9. Windows NT and X-Windows/Motif

10. COM in Windows NT 4 vs. Windows 2000

11. DLL loading (Windows NT vs Windows 98)

12. Windows 98 Windows NT Visual C++ V1.52 and low level graphics

 

 
Powered by phpBB® Forum Software