An advisory has been issued today (November 10):
The issue is fixed upstream in 1.6.26 and 1.8.10. The patch for 1.6.x is also included in the above message.
Mageia 3 and Mageia 4 are also affected.
Steps to Reproduce:
Cauldron bumped to 1.8.10
Mga4 and Mga3 patched.
I have also bumped default auth_timeout back to 30s as some systems still have issues with 20s
MGA4TOO, MGA3TOO =>
So far, so good on the first boot - but then the 1.7 version worked OK on the first boot, too. It took several days and several boots for the problem to show up with 1.7, so it'll be several days before I can be sure this one is working. Will report back once that happens, sooner if I see the problem again.
Tested on MGA4-64 on HP Probook 6555b AMD Quadcore.
I did 5 reboots and all went smoothly.
Tested OK mga4_i586. The 30s setting seems the good way.
I believe the reduced timeout was an upstream CVE fix so we'll have to note it's removal in the advisory.
If the reduced timeout is an upstream fix, it would seem to me that other distros would be seeing the same problem we are with some machines. Is this happening?
If not, then perhaps there's something unique about Mageia that makes it show up, and lengthening the timeout back out again is really more of a workaround than a "fix."
Adding mga4 64 ok from Herman's comment
We need an advisory for this one please.
MGA3TOO MGA4-32-OK =>
MGA3TOO MGA4-32-OK mga4-64-ok
Testing complete mga3 32
MGA3TOO MGA4-32-OK mga4-64-ok =>
MGA3TOO mga3-32-ok MGA4-32-OK mga4-64-ok
Testing complete mga3 64
MGA3TOO mga3-32-ok MGA4-32-OK mga4-64-ok =>
MGA3TOO mga3-32-ok mga3-64-ok MGA4-32-OK mga4-64-ok
(In reply to claire robinson from comment #5)
> I believe the reduced timeout was an upstream CVE fix so we'll have to note
> it's removal in the advisory.
It wasn't a CVE fix as such, it was part of one with the comment:
"So the patch reduces the harm of the attack from a DoS (the new connection fails) to a slow connection at startup (up to auth_timeout)."
but setting it too low will pretty much be a local DOS too :)
The auth_timeout setting in the code has this comment:
/* Making this long risks making a DOS attack easier, but too short
* and legitimate auth will fail. If interactive auth (ask user for
* password) is allowed, then potentially it has to be quite long.
Wich is why we go back to 30s that we know works.
The patch issued by the D-Bus maintainers for CVE-2014-3636 was based on
incorrect reasoning, and does not fully prevent the attack described as
"CVE-2014-3636 part A", which is repeated below. Preventing that attack
requires raising the system dbus-daemon's RLIMIT_NOFILE (ulimit -n) to
a higher value.
By queuing up the maximum allowed number of fds, a malicious sender
could reach the system dbus-daemon's RLIMIT_NOFILE (ulimit -n, typically
1024 on Linux). This would act as a denial of service in two ways:
* new clients would be unable to connect to the dbus-daemon
* when receiving a subsequent message from a non-malicious client that
contained a fd, dbus-daemon would receive the MSG_CTRUNC flag,
indicating that the list of fds was truncated; kernel fd-passing APIs
do not provide any way to recover from that, so dbus-daemon responds
to MSG_CTRUNC by disconnecting the sender, causing denial of service
to that sender.
This update resolves the issue (CVE-2014-7824).
Also default auth_timeout that was changed from 30s to 5s in MGASA-2014-0395,
and raised to 20s in MGAA-2014-0182 is now changed back to 30s as there
still are reports about failing dbus connections.
Testing on Mageia 3-64, real hardware
Installed following update-testing packages :
Rebooted fine, will report any problem arising in the next days.
Validating, advisory uploaded.
MGA3TOO mga3-32-ok mga3-64-ok MGA4-32-OK mga4-64-ok =>
MGA3TOO mga3-32-ok mga3-64-ok MGA4-32-OK mga4-64-ok advisoryCC:
An update for this issue has been pushed to Mageia Updates repository.
Unfortunately, I had a wrong boot even with this last update that brought the 30s delay back. As always, a reboot fixed the problem....
No problems here yet, so I'm cautiously optimistic. I must note, though, that there have only been a few boots on my problem machine since the latest kernel update.
> I have also bumped default auth_timeout back to 30s as some systems still
> have issues with 20s
Hello Mageia security and/or D-Bus maintainers,
I released this D-Bus update upstream, and happened to see details of it on LWN.
If you hit regressions in a D-Bus update, *please* report them upstream. We can't fix regressions in other distributions, offer advice on whether workarounds are correct, or anything useful like that if we never find out about the regression.
If you hit regressions in a stable branch, or particularly in a security update, doubly so.
I realise a certain amount of triaging and confirmation needs to happen to determine the cause of an intermittent failure, but if you're sure enough about the cause to do an update release with the change reverted, then you're sure enough about the cause that we would like to know about it.
Is there somewhere I can read the full details of the regression report?
Simon, these would be the most relevant bugs:
Simon, FWIW there is also a rather lengthy discussion which included several users experiencing the problem (including me) at:
Thanks, I have opened https://bugs.freedesktop.org/show_bug.cgi?id=86431 upstream to track the regressions apparently caused by reducing auth_timeout.