Bug 16515 - openafs new security issues CVE-2015-328[2-5] and CVE-2015-6587
Summary: openafs new security issues CVE-2015-328[2-5] and CVE-2015-6587
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 5
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/653063/
Whiteboard: MGA4TOO has_procedure advisory MGA4-6...
Keywords: validated_update
Depends on:
Blocks:
 
Reported: 2015-07-31 23:33 CEST by David Walser
Modified: 2015-09-08 21:42 CEST (History)
8 users (show)

See Also:
Source RPM: openafs-1.6.11-1.mga5.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2015-07-31 23:33:45 CEST
Debian has issued an advisory on July 30:
https://www.debian.org/security/2015/dsa-3320

The issues are fixed upstream in 1.6.13.

Mageia 4 and Mageia 5 are also affected.

CVE-2015-3287 has a separate LWN reference:
http://lwn.net/Vulnerabilities/653064/

Updated packages uploaded for Mageia 4, Mageia 5, and Cauldron.

Advisory:
========================

Updated openafs packages fix security vulnerabilities:

Memory allocated by vos for VLDB entry structures was not cleared prior to
use, meaning stack data could be sent over the network, possibly in the clear
if crypt mode was not in use (CVE-2015-3282).

The default use by bos of clear rather than crypt mode can allow spoofing
commands, including some which modify server state if restricted mode was not
enabled (CVE-2015-3283).

A local user executing commands which make pioctl calls to the kernel will
have some contents of kernel memory leaked when buffers used are larger than
data being returned (CVE-2015-3284).

A local user executing the OSD FS command pioctl can trigger a panic due to
an incorrect buffer being used for return status of the command
(CVE-2015-3285).

The vlserver allows pattern matching on volume names via regular expressions
when listing attributes. Because the regular expression is not checked for
situations which can overflow the buffers used, an attack is possible which
reads arbitrary memory beyond the end of the buffer and can act on it as part
of the expression evaluation, potentially crashing the process
(CVE-2015-3287).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3282
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3283
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3284
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3285
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3287
http://www.openafs.org/pages/security/OPENAFS-SA-2015-001.txt
http://www.openafs.org/pages/security/OPENAFS-SA-2015-002.txt
http://www.openafs.org/pages/security/OPENAFS-SA-2015-003.txt
http://www.openafs.org/pages/security/OPENAFS-SA-2015-004.txt
http://www.openafs.org/pages/security/OPENAFS-SA-2015-006.txt
http://www.openafs.org/dl/openafs/1.6.13/RELNOTES-1.6.13
http://www.openafs.org/pipermail/openafs-announce/2015/000486.html
https://www.debian.org/security/2015/dsa-3320
========================

Updated packages in core/updates_testing:
========================
openafs-1.6.13-1.mga4
openafs-client-1.6.13-1.mga4
openafs-server-1.6.13-1.mga4
libopenafs1-1.6.13-1.mga4
libopenafs-devel-1.6.13-1.mga4
libopenafs-static-devel-1.6.13-1.mga4
dkms-libafs-1.6.13-1.mga4
openafs-doc-1.6.13-1.mga4
openafs-1.6.13-1.mga5
openafs-client-1.6.13-1.mga5
openafs-server-1.6.13-1.mga5
libopenafs1-1.6.13-1.mga5
libopenafs-devel-1.6.13-1.mga5
libopenafs-static-devel-1.6.13-1.mga5
dkms-libafs-1.6.13-1.mga5
openafs-doc-1.6.13-1.mga5

from SRPMS:
openafs-1.6.13-1.mga4.src.rpm
openafs-1.6.13-1.mga5.src.rpm

Reproducible: 

Steps to Reproduce:
David Walser 2015-07-31 23:33:56 CEST

Whiteboard: (none) => MGA4TOO

Comment 1 Thomas Backlund 2015-07-31 23:35:42 CEST
Please hold of a little on this so I can confirm it builds with kernel-4.1

CC: (none) => tmb

Comment 2 Thomas Backlund 2015-08-01 00:31:51 CEST
ok, it builds properly for kernel 4.1.3+ ... go ahead and test
Comment 3 claire robinson 2015-08-01 18:56:05 CEST
Adding some AFS users to CC, please help with testing.

Thanks.

CC: (none) => goetz.waschk, paul.blackburn

Dave Hodgins 2015-08-04 23:36:14 CEST

Whiteboard: MGA4TOO => MGA4TOO advisory
CC: (none) => davidwhodgins

Comment 4 Götz Waschk 2015-08-07 18:52:05 CEST
Sorry, I cannot test this at the moment. My Mageia machine gave up the ghost.
Comment 5 Brian Rockwell 2015-08-08 23:37:26 CEST
I'm giving it a try.  No guarantees.  I am following the instructions from the Mageia WIKI

https://wiki.mageia.org/en/Installing_OpenAFS_Client

CC: (none) => brtians1

Comment 6 Brian Rockwell 2015-08-08 23:54:09 CEST
okay - installed the client and run through the commands in the client.  Unfortunately, I do not have nay openafs hosts.  If anyone has a recommendation post or Email me along with the authentication or how to get an authenticated ID.

All of the commands seems to be working and it installed properly from what I can see.

Next steps?

Thanks,
Brian
Comment 7 claire robinson 2015-08-09 03:27:57 CEST
Just ensure the dkms module builds against the current kernel Brian with the relevant kernel-*-devel installed.
Comment 8 Brian Rockwell 2015-08-11 15:55:05 CEST
It did install and commands worked.  I haven't built out the server part and don't have the bandwidth.

From what I can tell, the client is working properly and installed properly.

--if anyone else can test please confirm my results--
Comment 9 Herman Viaene 2015-08-19 16:05:24 CEST
MGA4-32 on Acer D620 Xfce.
No installation issues.
Tried to follow instructions as per Comment 5, but I get lost at the step "Configure Kerberos client", there is a file with ref to example.com. I replaced these by "localhost"
and subsequently at CLI:
# kinit
kinit: Invalid argument while getting initial credentials

CC: (none) => herman.viaene

Comment 10 David Walser 2015-08-27 21:26:26 CEST
For openafs, if with dkms-afs the kernel module builds fine, that's sufficient to OK this.
Comment 11 Lewis Smith 2015-08-28 21:51:26 CEST
Testing MGA4 x64 (real EFI h/w)

Installed from normal repos:
 dkms-libafs-1.6.11-1.mga4
 lib64openafs1-1.6.11-1.mga4
 openafs-1.6.11-1.mga4
 openafs-client-1.6.11-1.mga4
 openafs-doc-1.6.11-1.mga4
 openafs-server-1.6.11-1.mga4
The DKMS business took 10m; os-prober again?
Re-booted. Checked that both client & server were running & marked to start at boot.

The kernel is 3.14.43-desktop-1.mga4

Updated the packages from Updates Testing to:
 dkms-libafs-1.6.13-1.mga4
 lib64openafs1-1.6.13-1.mga4
 openafs-1.6.13-1.mga4
 openafs-client-1.6.13-1.mga4
 openafs-doc-1.6.13-1.mga4
 openafs-server-1.6.13-1.mga4
Again the DKMS business took 10m.
Checked that both client & server are running & ticked to start at boot.
Will re-boot to ensure the kernel still works.

CC: (none) => lewyssmith

Comment 12 David Walser 2015-08-28 21:55:08 CEST
(In reply to Lewis Smith from comment #11)
> The DKMS business took 10m; os-prober again?

Unlikely os-prober related.  DKMS can take a while depending on the package and your hardware, as it is compiling something.
Comment 13 Lewis Smith 2015-08-28 22:00:44 CEST
OK, it seems to. And both Openafs Client & Server are up & running.

So... This update is OK'd on the basis that it seems to install cleanly, without any real *use* of the software before or after the update.

Whiteboard: MGA4TOO advisory => MGA4TOO advisory MGA4-64-OK

Comment 14 Lewis Smith 2015-08-30 20:50:47 CEST
Trying MGA5 x64

Not so smooth. Installed from normal repos:
 dkms-libafs-1.6.11-1.mga5
 lib64openafs1-1.6.11-1.mga5
 openafs-1.6.11-1.mga5
 openafs-client-1.6.11-1.mga5
 openafs-doc-1.6.11-1.mga5
 openafs-server-1.6.11-1.mga5
This installed much quicker than for Mageia 4. MCC/Services & Daemons showed both openafs Client & Server *not* running, but to start at reboot; which I see as correct, because on re-booting

 kernel-desktop-4.1.6-4.mga5-1-1.mga5
 kernel-desktop-devel-4.1.6-4.mga5-1-1.mga5

it started doing its dkms stuff for libafs [?] which after a few minutes FAILED exit code 10 (could not capture the console O/P, & nothing for dkms or libafs in dmesg). Booting continued to normal desktop.
MCC/Services showed the openafs Client suspended, but the Server running.

This behaviour is different from Mageia 4. I refrain from applying the update until this installation issue is sorted.
Comment 15 Thomas Backlund 2015-08-30 21:12:01 CEST
You need 1.6.13 (the one in testing) if you want to test with the 4.1 series kernels.... 1.6.11 does not support that kernel
Comment 16 Lewis Smith 2015-09-01 10:49:24 CEST
(In reply to Thomas Backlund from comment #15)
> You need 1.6.13 (the one in testing) if you want to test with the 4.1 series
> kernels.... 1.6.11 does not support that kernel
If this means that users must already be running 4.1 kernel to apply this update, is that certain? Or can it be made certain?

Testing MGA5 x64 real EFI hardware.
Kernel 4.1.6-desktop-4.mga5

Having previously failed to install openafs (Comment 14), I applied the update:
 dkms-libafs-1.6.13-1.mga5
 lib64openafs1-1.6.13-1.mga5
 openafs-1.6.13-1.mga5
 openafs-client-1.6.13-1.mga5
 openafs-doc-1.6.13-1.mga5
 openafs-server-1.6.13-1.mga5
Installing the dkms pkg took >10m. I suspect os-prober (alone took 9m later) or Grub2-efi; in any case, the result is *not* put into NVRAM, which holds the last actual Mageia *installation* I did. This does not seem right. A side-track.

openafs Client was left *not* running, the Server running. Both to start at boot.
Re-booted. It recognised that libafs was already built. Both Client & Server were up & running. With NO testing of their functionality, this update looks MGA5-64-OK *if* my worry that the kernel must be 4.1 for it to work is unfounded.

@tmb
If this last point is sure, please OK this on the whiteboard. TIA
Comment 17 David Walser 2015-09-01 12:52:19 CEST
(In reply to Lewis Smith from comment #16)
> If this means that users must already be running 4.1 kernel to apply this
> update, is that certain? Or can it be made certain?

No, you got that backwards.

In comment 14, you tried testing the current version 1.6.11 with the updates_testing 4.1.6 kernel.  That won't work.  If you're testing with the 4.1.6 kernel, you need to use the 1.6.13 openafs in updates_testing.  Either openafs version should work fine with the 3.19.8 kernel.
Comment 18 Lewis Smith 2015-09-01 16:15:57 CEST
(In reply to David Walser from comment #17)
> In comment 14, you tried testing the current version 1.6.11 with the
> updates_testing 4.1.6 kernel.  That won't work.  If you're testing with the
> 4.1.6 kernel, you need to use the 1.6.13 openafs in updates_testing.
[As Comment 15]
Which I did; and it seemed OK.

>  Either openafs version should work fine with the 3.19.8 kernel.
Does this mean the update should be tried against a 3.19.8 kernel? I doubt whether I have one (I can only see 4.1.6 in /boot).
Should we try that, or just let this go?
Comment 19 Rémi Verschelde 2015-09-01 16:20:52 CEST
(In reply to Lewis Smith from comment #18)
> >  Either openafs version should work fine with the 3.19.8 kernel.
> Does this mean the update should be tried against a 3.19.8 kernel? I doubt
> whether I have one (I can only see 4.1.6 in /boot).
> Should we try that, or just let this go?

If we want to be thorough, we should yes. AFAIK, the 4.1.6 kernel is still in updates_testing, so most users are using kernel 3.19.8 currently, and will therefore get openafs 1.6.13 together with kernel 3.19.8.
Comment 20 Lewis Smith 2015-09-01 21:41:25 CEST
Testing Mageia 5 x64 with kernel 3.19.8-desktop-3.mga5

BEFORE
Installed the kernel above (remember the devel version also; I did not). Removed all openafs &  libafs pkgs. Re-installed all the openafs released pkgs:
 dkms-libafs-1.6.11-1.mga5
 lib64openafs1-1.6.11-1.mga5
 openafs-1.6.11-1.mga5
 openafs-client-1.6.11-1.mga5
 openafs-doc-1.6.11-1.mga5
 openafs-server-1.6.11-1.mga5
This went quickly because, I quess, the lack of the devel kernel (I added it subsequently) prevented any attempt to make the libafs module at this stage. MCC Services showed both Client & Server stopped but to start at re-boot.

Re-booted with this kernel+devel, it did its dkms libafs build thing: 13 minutes! Continued to a normal desktop. MCC Services shows both Client & Server running.
So far so good. This is the upgrade start point. To continue.
Comment 21 Lewis Smith 2015-09-01 21:57:46 CEST
Testing Mageia 5 x64 with kernel 3.19.8-desktop-3.mga5 [continued]

AFTER
From Updates Testing, updated openafs to:
 dkms-libafs-1.6.13-1.mga5
 lib64openafs1-1.6.13-1.mga5
 openafs-1.6.13-1.mga5
 openafs-client-1.6.13-1.mga5
 openafs-doc-1.6.13-1.mga5
 openafs-server-1.6.13-1.mga5
This time the libafs build happened when that pkg was installed; 13 minutes again!
That apart, the update went without problems, & left both the Client & Server running. Whether left over from before the update, or re-started with it, I know not.

Re-booting, it recognised that libafs was already built & continued at normal speed to the desktop. Both openafs Client & Server, definitely updated, were running.

So the MGA4-64-OK is confirmed re Comment 19.
Comment 22 Lewis Smith 2015-09-01 21:59:30 CEST
(In reply to Lewis Smith from comment #21)
> Testing Mageia 5 x64 with kernel 3.19.8-desktop-3.mga5 [continued]
> So the MGA4-64-OK is confirmed re Comment 19.
Sorry, read MGA5-64-OK.

Whiteboard: MGA4TOO advisory MGA4-64-OK => MGA4TOO advisory MGA4-64-OK MGA5-64-OK

Comment 23 David Walser 2015-09-02 15:19:00 CEST
OpenAFS apparently used CVE-2015-3287 without permission, so it's been rejected and renamed to CVE-2015-6587:
http://openwall.com/lists/oss-security/2015/09/02/2

Advisory:
========================

Updated openafs packages fix security vulnerabilities:

Memory allocated by vos for VLDB entry structures was not cleared prior to
use, meaning stack data could be sent over the network, possibly in the clear
if crypt mode was not in use (CVE-2015-3282).

The default use by bos of clear rather than crypt mode can allow spoofing
commands, including some which modify server state if restricted mode was not
enabled (CVE-2015-3283).

A local user executing commands which make pioctl calls to the kernel will
have some contents of kernel memory leaked when buffers used are larger than
data being returned (CVE-2015-3284).

A local user executing the OSD FS command pioctl can trigger a panic due to
an incorrect buffer being used for return status of the command
(CVE-2015-3285).

The vlserver allows pattern matching on volume names via regular expressions
when listing attributes. Because the regular expression is not checked for
situations which can overflow the buffers used, an attack is possible which
reads arbitrary memory beyond the end of the buffer and can act on it as part
of the expression evaluation, potentially crashing the process
(CVE-2015-6587).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3282
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3283
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3284
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3285
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6587
http://www.openafs.org/pages/security/OPENAFS-SA-2015-001.txt
http://www.openafs.org/pages/security/OPENAFS-SA-2015-002.txt
http://www.openafs.org/pages/security/OPENAFS-SA-2015-003.txt
http://www.openafs.org/pages/security/OPENAFS-SA-2015-004.txt
http://www.openafs.org/pages/security/OPENAFS-SA-2015-006.txt
http://www.openafs.org/dl/openafs/1.6.13/RELNOTES-1.6.13
http://www.openafs.org/pipermail/openafs-announce/2015/000486.html
http://openwall.com/lists/oss-security/2015/09/02/2
https://www.debian.org/security/2015/dsa-3320

Summary: openafs new security issues CVE-2015-328[2-5] and CVE-2015-3287 => openafs new security issues CVE-2015-328[2-5] and CVE-2015-6587

David Walser 2015-09-02 15:19:12 CEST

Whiteboard: MGA4TOO advisory MGA4-64-OK MGA5-64-OK => MGA4TOO MGA4-64-OK MGA5-64-OK

Comment 24 claire robinson 2015-09-07 16:50:26 CEST
Validating. Advisory uploaded.

Please push to 4 & 5 updates

Thanks

Keywords: (none) => validated_update
Whiteboard: MGA4TOO MGA4-64-OK MGA5-64-OK => MGA4TOO has_procedure advisory MGA4-64-OK MGA5-64-OK
CC: (none) => sysadmin-bugs

Comment 25 Mageia Robot 2015-09-08 09:21:41 CEST
An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGASA-2015-0337.html

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

Comment 26 David Walser 2015-09-08 21:42:39 CEST
LWN reference for CVE-2015-6587:
http://lwn.net/Vulnerabilities/656899/

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