An advisory has been issued today (November 10): http://openwall.com/lists/oss-security/2014/11/10/2 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. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA4TOO, MGA3TOO
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 Mga4: SRPM: dbus-1.6.18-1.8.mga4.src.rpm i586: dbus-1.6.18-1.8.mga4.i586.rpm dbus-doc-1.6.18-1.8.mga4.noarch.rpm dbus-x11-1.6.18-1.8.mga4.i586.rpm libdbus1_3-1.6.18-1.8.mga4.i586.rpm libdbus-devel-1.6.18-1.8.mga4.i586.rpm x86_64: dbus-1.6.18-1.8.mga4.x86_64.rpm dbus-doc-1.6.18-1.8.mga4.noarch.rpm dbus-x11-1.6.18-1.8.mga4.x86_64.rpm lib64dbus1_3-1.6.18-1.8.mga4.x86_64.rpm lib64dbus-devel-1.6.18-1.8.mga4.x86_64.rpm Mga3: SRPM: dbus-1.6.8-4.8.mga3.src.rpm i586: dbus-1.6.8-4.8.mga3.i586.rpm dbus-doc-1.6.8-4.8.mga3.noarch.rpm dbus-x11-1.6.8-4.8.mga3.i586.rpm libdbus1_3-1.6.8-4.8.mga3.i586.rpm libdbus-devel-1.6.8-4.8.mga3.i586.rpm x86_64: dbus-1.6.8-4.8.mga3.x86_64.rpm dbus-doc-1.6.8-4.8.mga3.noarch.rpm dbus-x11-1.6.8-4.8.mga3.x86_64.rpm lib64dbus1_3-1.6.8-4.8.mga3.x86_64.rpm lib64dbus-devel-1.6.8-4.8.mga3.x86_64.rpm
CC: (none) => tmbHardware: i586 => AllVersion: Cauldron => 4Assignee: tmb => qa-bugsWhiteboard: MGA4TOO, MGA3TOO => 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.
CC: (none) => andrewsfarm
Tested on MGA4-64 on HP Probook 6555b AMD Quadcore. I did 5 reboots and all went smoothly.
CC: (none) => herman.viaene
Tested OK mga4_i586. The 30s setting seems the good way.
CC: (none) => lists.jjorge
Whiteboard: MGA3TOO => MGA3TOO MGA4-32-OK
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.
Whiteboard: MGA3TOO MGA4-32-OK => MGA3TOO MGA4-32-OK mga4-64-ok
Testing complete mga3 32
Whiteboard: MGA3TOO MGA4-32-OK mga4-64-ok => MGA3TOO mga3-32-ok MGA4-32-OK mga4-64-ok
Testing complete mga3 64
Whiteboard: 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.
advisory: 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 : - dbus-1.6.8-4.8.mga3.x86_64 - dbus-x11-1.6.8-4.8.mga3.x86_64 - lib64dbus-devel-1.6.8-4.8.mga3.x86_64 - lib64dbus1_3-1.6.8-4.8.mga3.x86_64 Rebooted fine, will report any problem arising in the next days.
CC: (none) => olchal
Validating, advisory uploaded.
Keywords: (none) => validated_updateWhiteboard: 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: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2014-0457.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
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.
URL: (none) => http://lwn.net/Vulnerabilities/620967/
> 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? Thanks, smcv
CC: (none) => simon.mcvittie
Simon, these would be the most relevant bugs: https://bugs.mageia.org/show_bug.cgi?id=14251 https://bugs.mageia.org/show_bug.cgi?id=14249
Simon, FWIW there is also a rather lengthy discussion which included several users experiencing the problem (including me) at: https://forums.mageia.org/en/viewtopic.php?f=7&t=8564
Thanks, I have opened https://bugs.freedesktop.org/show_bug.cgi?id=86431 upstream to track the regressions apparently caused by reducing auth_timeout.