Bug 14494 - dbus new security issue CVE-2014-7824
Summary: dbus new security issue CVE-2014-7824
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 4
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/620967/
Whiteboard: MGA3TOO mga3-32-ok mga3-64-ok MGA4-32...
Keywords: validated_update
Depends on:
Blocks:
 
Reported: 2014-11-10 18:19 CET by David Walser
Modified: 2014-11-18 12:31 CET (History)
7 users (show)

See Also:
Source RPM: dbus-1.8.8-4.mga5.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2014-11-10 18:19:40 CET
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:
David Walser 2014-11-10 18:20:04 CET

Whiteboard: (none) => MGA4TOO, MGA3TOO

Comment 1 Thomas Backlund 2014-11-10 21:47:19 CET
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) => tmb
Hardware: i586 => All
Version: Cauldron => 4
Assignee: tmb => qa-bugs
Whiteboard: MGA4TOO, MGA3TOO => MGA3TOO

Comment 2 Thomas Andrews 2014-11-11 02:05:50 CET
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

Comment 3 Herman Viaene 2014-11-11 15:36:22 CET
Tested on MGA4-64 on HP Probook 6555b AMD Quadcore.
I did 5 reboots and all went smoothly.

CC: (none) => herman.viaene

Comment 4 José Jorge 2014-11-11 22:43:05 CET
Tested OK mga4_i586. The 30s setting seems the good way.

CC: (none) => lists.jjorge

José Jorge 2014-11-11 22:45:05 CET

Whiteboard: MGA3TOO => MGA3TOO MGA4-32-OK

Comment 5 claire robinson 2014-11-12 11:24:37 CET
I believe the reduced timeout was an upstream CVE fix so we'll have to note it's removal in the advisory.
Comment 6 Thomas Andrews 2014-11-12 16:02:12 CET
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."
Comment 7 claire robinson 2014-11-13 09:30:20 CET
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

Comment 8 claire robinson 2014-11-13 09:35:54 CET
Testing complete mga3 32

Whiteboard: MGA3TOO MGA4-32-OK mga4-64-ok => MGA3TOO mga3-32-ok MGA4-32-OK mga4-64-ok

Comment 9 claire robinson 2014-11-13 10:02:26 CET
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

Comment 10 Thomas Backlund 2014-11-13 21:00:07 CET
(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.
Comment 11 Thomas Backlund 2014-11-13 21:00:54 CET
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.
Comment 12 olivier charles 2014-11-13 23:04:42 CET
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

Comment 13 Rémi Verschelde 2014-11-14 13:10:00 CET
Validating, advisory uploaded.

Keywords: (none) => validated_update
Whiteboard: 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 advisory
CC: (none) => sysadmin-bugs

Comment 14 Mageia Robot 2014-11-15 19:32:33 CET
An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGASA-2014-0457.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 15 José Jorge 2014-11-16 12:16:10 CET
Unfortunately, I had a wrong boot even with this last update that brought the 30s delay back. As always, a reboot fixed the problem....
Comment 16 Thomas Andrews 2014-11-16 16:39:02 CET
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.
David Walser 2014-11-17 18:39:26 CET

URL: (none) => http://lwn.net/Vulnerabilities/620967/

Comment 17 Simon McVittie 2014-11-18 00:24:07 CET
> 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

Comment 18 David Walser 2014-11-18 00:31:07 CET
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
Comment 19 Thomas Andrews 2014-11-18 04:29:00 CET
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
Comment 20 Simon McVittie 2014-11-18 12:31:57 CET
Thanks, I have opened https://bugs.freedesktop.org/show_bug.cgi?id=86431 upstream to track the regressions apparently caused by reducing auth_timeout.

Note You need to log in before you can comment on or make changes to this bug.