System bus denial-of-service

[Sean Meiners]

On Tuesday 21 June 2005 04:28 pm, Havoc Pennington wrote:
> Hi,
>
> FWIW it would be better to send possible security flaws to a few of the
> maintainers in private, rather than releasing the info publicly. I'm not
> sure whether this is an issue we'd want to do errata for, but if it is
> it would have been better to embargo.

My apologies, this was just the first place I thought of to send this.

>
> On Mon, 2005-06-20 at 15:22 -0700, Sean Meiners wrote:
> > While attempting to track down some memory leaks in my application I
> > found something that you may agree is a bit worrisome.  It seems that
> > it's relatively easy to cause a denial-of-service attack on the system
> > bus.  With a small amount of code (see attached) I can cause method calls
> > made by other apps on the same bus to fail with this error: 'The maximum
> > number of pending replies per connection has been reached' until the
> > attack is stopped.  On a multi-user system this could be a big problem.
>
> This is intended behavior, i.e. the max number of pending replies is a
> deliberate limit in the code.
>
> There's an inherent max number, which is the amount of memory the system
> has to store pending replies. So in a theoretical sense this limit is
> not removable.
>
> We could change the limit to any number we want though (potentially a
> much larger one) or we could have the limit be "memory exhaustion"
>
> Another possibility might be to cancel a random existing pending reply
> when the limit has been reached (so we always allow the new method
> call). For an attack like this we'd have a 99% chance of canceling some
> meaningless pending reply.

It's a hard problem to solve.  I fully support the max-connections limit, but 
what if you added a per-connection limit as well so that one connection could 
not adversely affect another?

>
> > PS: There is also an interesting side-effect in that the dbus-daemon
> > quickly jumps to using ~76MiB of resident memory and stays there, even
> > after the attack has ended.  While it's great that the daemon caps it's
> > own memory usage, it would be even better if it released it as well.
>
> It probably does call free(), but libc doesn't always unmap memory when
> you do that. i.e most likely not a bug, libc would recycle that memory
> if someone tried to use it again, and the kernel will swap it out if
> nobody ever does.
>
> Havoc

-- 
Sean Meiners
Sean.Meiners at LinspireInc.com


Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;