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:
Whiteboard: (none) => MGA4TOO
Please hold of a little on this so I can confirm it builds with kernel-4.1
CC: (none) => tmb
ok, it builds properly for kernel 4.1.3+ ... go ahead and test
Adding some AFS users to CC, please help with testing. Thanks.
CC: (none) => goetz.waschk, paul.blackburn
Whiteboard: MGA4TOO => MGA4TOO advisoryCC: (none) => davidwhodgins
Sorry, I cannot test this at the moment. My Mageia machine gave up the ghost.
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
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
Just ensure the dkms module builds against the current kernel Brian with the relevant kernel-*-devel installed.
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--
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
For openafs, if with dkms-afs the kernel module builds fine, that's sufficient to OK this.
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
(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.
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
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.
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
(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
(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.
(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?
(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.
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.
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.
(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
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
Whiteboard: MGA4TOO advisory MGA4-64-OK MGA5-64-OK => MGA4TOO MGA4-64-OK MGA5-64-OK
Validating. Advisory uploaded. Please push to 4 & 5 updates Thanks
Keywords: (none) => validated_updateWhiteboard: MGA4TOO MGA4-64-OK MGA5-64-OK => MGA4TOO has_procedure advisory MGA4-64-OK MGA5-64-OKCC: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2015-0337.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
LWN reference for CVE-2015-6587: http://lwn.net/Vulnerabilities/656899/