System bus denial-of-service
Havoc Pennington
hp at redhat.com
Tue Jun 21 16:28:58 PDT 2005
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.
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.
> 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
More information about the dbus
mailing list