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.