Bell Labs or Microsoft security?

Mailman List Mirror (Read Only)
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net>

> No, it isn't, as is doing buf_t rather than pointer

True. I just like having a struct so I may pass a single
variable in function calls instead of a whole mess of them.

The problem is not pointers, it is pointers pointing at things that don't belong to them or that they don't understand.

Is it unreasonable to ask that programmers not assume memory is
initialized, to check bounds as needed, and to realize that
operations are NOT atomic without special protection[*]?

40 years of experience says it is unreasonable to expect the programmer to get it right 100% of the time.

A modern server or Desktop OS is measured in hundreds of millions of lines of code, what is an acceptable error rate per line of code?

Last time I looked the average C programmer was running at about 1 "error" every 10 lines. Errors of this specific type in mature code probably running a lot less, but we are probably talking about ~100,000's of such issues in a typical Unix box.

- From a NANOG perspective it only really matters if they are in a network service, but from a cracking perspective any program you can feed, or get the user to feed corrupted input into will do fine.

I don't think so.

Be assured it is. Programmers even the best make mistakes.

Sure, it's extra work; put it in a library.

Precisely, most advocating change want an automated system, ideally something that lets us use all the many millions of lines of existing C code without too much aggrevation or performance hit. Most people here don't actually care "that" much if a specific program operates 100% correctly, only if it is subverted by worms or crackers to affect the integrity of the host system and/or network - in which case something like StackGuard is appropriate.

However fixes like StackGuard don't really remove the problem, they just mitigate the effects. My first experience of a big project in Java was such a relief to have a programming language where nearly all the errors either didn't compile, or were obviously and logically related to the bit that had just been altered.

This is way off topic for NANOG. I guess the lesson for NANOG that it is quite easy if you have the source code to mitigate the effects of these kind of problems, such that failure to patch will result in nothing more than a DoS at worst. Although these issues have been less of a problem on systems based on free (and open source) software, although I suspect the principal(*) reason for that is diversity in architecture and compiler meaning exploiting the weaknesses is harder, even if they are there.

Simon

* A secondary reason could be in the e-mails from David Wheeler saying "fix this" (in the nicest possible way).

2

40 years of experience says it is unreasonable to expect the programmer to

get it right 100% of the time.

A modern server or Desktop OS is measured in hundreds of millions of lines

of code, what is an acceptable error rate per line of code?

Perhaps I'm missing it, but is it unreasonable to have a tool that does
buffer checks? Obviously, the issue comes a lot of times when code is past
to outside sources that the compiler may not know about the handling of
code. However, it isn't hard to flag such calls as possible sources of
overflow if unknown, or continue the checks based on the debugger known that
particular routine and what it's data manipulation consists of. The idea of
hand checking code for mistakes is unreasonable. As you say, mistakes will
happen. Yet buffer overflows are mathematically seeable. If all api's are
handed out with proper specs of data handling, then verifying the integrity
of pointer usage could be guaranteed.

Am I missing something?

-Jack

3

Date: Thu, 30 Jan 2003 11:36:42 +0000
From: Simon Waters

The problem is not pointers, it is pointers pointing at
things that don't belong to them or that they don't
understand.

Hence why I proposed (and myself use) a struct that stores bounds
as well as the desired pointer. I don't want to check bounds
each time I access the buffer, so I put that in macros/functions
and use those. Using said buffer manipulation functions is no
more difficult than using dangerous functions.

That is not an unreasonable expectation. Yes, I think such
functionality should be part of libc or equivalent... but I
also think any programmer unaware of overruns should not be
using C, period. Such code isn't yet part of libc; workarounds
are necessary.

40 years of experience says it is unreasonable to expect the
programmer to get it right 100% of the time.

Yes, but we're not dealing with anything near 100% of the time.
We're talking about taking simple steps to rectify problems that
have been exploited and heavily publicized for a long time.

A modern server or Desktop OS is measured in hundreds of
millions of lines of code, what is an acceptable error rate
per line of code?

Difficult to answer. However, I'm approaching this from the
"minimal effort to produce significant benefit" perspective.

Last time I looked the average C programmer was running at
about 1 "error" every 10 lines. Errors of this specific type
in mature code probably running a lot less, but we are
probably talking about ~100,000's of such issues in a typical
Unix box.

One per ten lines? Yikes. Have you a citation? I recall
reading par was an order of magnitude lower than what you state;
alas, I cannot cite. I probably should dig through Jones'
_Estimating Software Costs_, which I have sitting but feet away.

- From a NANOG perspective it only really matters if they are
in a network service, but from a cracking perspective any
program you can feed, or get the user to feed corrupted input
into will do fine.

Correct.

> I don't think so.

Be assured it is. Programmers even the best make mistakes.

Yes.

> Sure, it's extra work; put it in a library.

Precisely, most advocating change want an automated system,
ideally something that lets us use all the many millions of
lines of existing C code without too much aggrevation or
performance hit. Most people here don't actually care "that"
much if a specific program operates 100% correctly, only if

Hence why I'm focusing on specific problems, not achieving "100%
bug-free" status.

it is subverted by worms or crackers to affect the integrity
of the host system and/or network - in which case something
like StackGuard is appropriate.

However fixes like StackGuard don't really remove the
problem, they just mitigate the effects. My first experience

And what's too say an overrun would trash return %eip?

  typedef u_int32_t uid_t ;
  uid_t run_as_this_user = UID_NOBODY ;
  char buf[256] ;
  bzero(buf, 260) ;

A bit contrived, but you see the problem.

of a big project in Java was such a relief to have a
programming language where nearly all the errors either
didn't compile, or were obviously and logically related to
the bit that had just been altered.

Yes, 'C' typing is a bit weak. It'd be interesting to see
statistics on defects per function point for C versus Java.

This is way off topic for NANOG. I guess the lesson for NANOG

Although several NANOGers sling code... you're probably right...

that it is quite easy if you have the source code to mitigate
the effects of these kind of problems, such that failure to
patch will result in nothing more than a DoS at worst.
Although these issues have been less of a problem on systems
based on free (and open source) software, although I suspect
the principal(*) reason for that is diversity in architecture
and compiler meaning exploiting the weaknesses is harder,
even if they are there.

...except we're the ones forced to deal with the effects of
software problems. AOL writes much (all?) of their own server
software; perhaps others need to take greater interest. Of
course, I suppose that's engineering instead of operations, and
thus still OT...

Eddy