Bell Labs or Microsoft security?

Thu Jan 30 16:15:43 UTC 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
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 at brics.com>
To: blacklist at 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 at brics.com>, or you are likely to
be blocked.