linux-kernel - Re: [PATCH 1/3] epoll: increase default max_user

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Jan 2009 00:28:29 +1100
From:	Bron Gondwana <brong@...tmail.fm>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Bron Gondwana <brong@...tmail.fm>, Ray Lee <ray-lk@...rabbit.org>,
	Davide Libenzi <davidel@...ilserver.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 1/3] epoll: increase default max_user_instances to 1024

On Wed, Jan 28, 2009 at 11:36:40AM +0000, Alan Cox wrote:
> > > "A kernel upgrade in a -stable series point release fixed a security DoS"
> > 
> > Alan, that's a complete load of bollocks.  It broke common configurations 
> > of java, postfix and apache on real-world machines, causing significant
> > actual denials of service in previously reliable configurations.
> 
> It fixed a security DoS. I was merely pointing out that the description
> provided before was bogus, incomplete and loaded.

Not allowing user logins would have fixed that particular security DoS
too.  There's a range of pretty destructive things that can "fix" one 
issue at the expense of creating others.

This particular choice of fix just happens to have caused at least three
reported (though not to LKML, but I'll post the URLs for the other two
again in a sec) commonly used applications issues.  These applications
were using the published API in a way which used to work perfectly
well, and not DoSing the system.

How would you define a regression otherwise?  A public and commonly used
API had a new user-space visable error code added that it had never
returned before, and a low enough limit set that this error was seen in
practice by multiple sites.

http://marc.info/?l=fedora-devel-list&m=123134150926934&w=2

http://pero.blogs.aprilmayjune.org/2009/01/22/hadoop-and-linux-kernel-2627-epoll-limits/

> > viable within the code.  The DoS works by creating epoll descriptors
> > watching other epoll descriptors, which strikes me as a much less
> > real-world actual use pattern than a bunch of separate daemons with an
> > epoll watcher each.
> 
> Deliberate attackers don't have to follow typical usage patterns.

Sure, but if typical usage patterns hit your sensor, then you have false
positives.  Adding a DoS sensor that gets false positives is a regression, 
and whitewashing it as "fixed a security DoS" is bogus.  It did that, but
also more than that, and the more was/is sucky.

> > If it's possible to count watches only if they're added to another epoll
> > instance, then we'd have a metric that still catches the N^2 attack, but
> > doesn't interact with the common non-attacky use-case.
> 
> Agreed entirely.

Yeah, enough arguing hey.  Let's come up with a real fix that doesn't
give sites the ugly choice between remaining vulnerable to a known DoS
attack or hobbling common programs that aren't actually using that many
resources.

Bron.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/