Re: Bell Labs or Microsoft security?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net>
ML> No, it isn't, as is doing buf_t[x] 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). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+OQ5HGFXfHI9FVgYRAgENAKC4TqEqtYO9mOzC7GUFZL0yUXxkugCfd0as cV4IA/+PHmi26hGwzPwWP5M= =DJjK -----END PGP SIGNATURE-----
From: "Simon Waters"
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
SW> Date: Thu, 30 Jan 2003 11:36:42 +0000 SW> From: Simon Waters SW> The problem is not pointers, it is pointers pointing at SW> things that don't belong to them or that they don't SW> 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. SW> 40 years of experience says it is unreasonable to expect the SW> 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. SW> A modern server or Desktop OS is measured in hundreds of SW> millions of lines of code, what is an acceptable error rate SW> per line of code? Difficult to answer. However, I'm approaching this from the "minimal effort to produce significant benefit" perspective. SW> Last time I looked the average C programmer was running at SW> about 1 "error" every 10 lines. Errors of this specific type SW> in mature code probably running a lot less, but we are SW> probably talking about ~100,000's of such issues in a typical SW> 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. SW> - From a NANOG perspective it only really matters if they are SW> in a network service, but from a cracking perspective any SW> program you can feed, or get the user to feed corrupted input SW> into will do fine. Correct. SW> > I don't think so. SW> SW> Be assured it is. Programmers even the best make mistakes. Yes. SW> > Sure, it's extra work; put it in a library. SW> SW> Precisely, most advocating change want an automated system, SW> ideally something that lets us use all the many millions of SW> lines of existing C code without too much aggrevation or SW> performance hit. Most people here don't actually care "that" SW> much if a specific program operates 100% correctly, only if Hence why I'm focusing on specific problems, not achieving "100% bug-free" status. SW> it is subverted by worms or crackers to affect the integrity SW> of the host system and/or network - in which case something SW> like StackGuard is appropriate. SW> SW> However fixes like StackGuard don't really remove the SW> 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. SW> of a big project in Java was such a relief to have a SW> programming language where nearly all the errors either SW> didn't compile, or were obviously and logically related to SW> 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. SW> This is way off topic for NANOG. I guess the lesson for NANOG Although several NANOGers sling code... you're probably right... SW> that it is quite easy if you have the source code to mitigate SW> the effects of these kind of problems, such that failure to SW> patch will result in nothing more than a DoS at worst. SW> Although these issues have been less of a problem on systems SW> based on free (and open source) software, although I suspect SW> the principal(*) reason for that is diversity in architecture SW> and compiler meaning exploiting the weaknesses is harder, SW> 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 -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
participants (3)
-
E.B. Dreger -
Jack Bates -
Simon Waters