North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Bell Labs or Microsoft security?
- From: E.B. Dreger
- Date: Thu Jan 30 11:24:43 2003
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
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
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.
SW> > I don't think so.
SW> Be assured it is. Programmers even the best make mistakes.
SW> > Sure, it's extra work; put it in a library.
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%
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> 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 ;
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...
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 <email@example.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 <firstname.lastname@example.org>, or you are likely to