Re: INFO#97.27047Re: Denial-of-service attack against INETD.

[David Holland <dholland@hcs.harvard.edu>]

 > A couple of weeks ago, we 'pinged' this group for feedback on
 > the inetd vul that Richard Hipp reported:

Ok, here's what I know. (I'm not directly connected to this problem
any more; I have handed most of my Linux responsibilities on to
others.)

The original report by Richard Hipp was not very helpful and somewhat
inflammatory. He presented a new modified copy of inetd without
specifying what he'd changed, and reformatted the source to make
automatic comparisons difficult. I (and other people) did comparisons
anyway, which turned up issue #1, but we could have missed something.

There appear to be four related but distinct issues here, as follows:

	1. There was a set of missing { } in the inetd source after
	the call to select(), causing under certain circumstances 
	(when select fails with EINTR, such as after the delivery 
	of a signal) an unwanted sleep(1). This was found to affect
	virtually all the public versions of inetd, so it probably
	affects vendor versions as well. It is, however, not a
	security problem.

	2. Inetd shuts off services that receive too many connection
	requests. There have been reports (I don't know to what extent
	this is true, or on what platforms) that while it claims to
	turn things back on after some interval (usually ten minutes),
	it never actually does. I'm not sure if this is a real bug or
	not. I've been told that it isn't. If this behavior exists,
	however, it is a security issue.

	3. Inetd's mechanism for deciding what constitutes too many
	connection requests is too sensitive. There are reports that
	normal usages in some contexts exceed the limits built into
	inetd, causing it to shut down due to "overload" under
	perfectly normal operating conditions. This is because
	connection rates that would have killed a VAX are nothing to a
	Pentium, never mind an Ultrasparc. This *is* a problem, but
	it's not clear that it's a security problem.

	4. The very fact that inetd will shut off services is,
	technically, a denial-of-service vulnerability. This, I
	believe, was the main thrust of Richard Hipp's mail. If you
	flood inetd with connection attempts faster than it can
	process them, it will eventually shut off the service for a
	while. The problem here (and Mr. Hipp doesn't seem to realize
	it) is that there's no way to prevent this.

	If you send connects faster than inetd can accept and process
	them, eventually the people connecting will get "Connection
	refused", because even if inetd doesn't shut down the service,
	eventually the kernel's listen queue will fill up and further
	connections will fail.

	The only way I can think of to address this problem is to
	create some kind of automatic filter to firewall off problem
	sites (or whole nets) when they start connecting too much.
	This is difficult, even if you couldn't spoof source
	addresses, and I'd say it's an open research issue and not
	something we can expect to see available as a security patch
	anytime soon.

So, I'd say the reason there hasn't been any activity is that the
security problem is essentially unsolvable and the other problems
aren't security-related. 

Regarding whether it's Linux-specific... #1 isn't; #2, if it exists,
probably isn't either; #3 might or might not be; #4 is universal.

-- 
   - David A. Holland          | Number of words in the English language that
     dholland@eecs.harvard.edu | exist because of typos or misreadings: 381


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .