Debian has issued an advisory on April 9: https://www.debian.org/security/2014/dsa-2899 The issue is fixed upstream in 1.6.7: http://www.openafs.org/security/OPENAFS-SA-2014-001.txt http://www.openafs.org/dl/openafs/1.6.7/RELNOTES-1.6.7 http://www.openafs.org/pipermail/openafs-announce/2014/000460.html We should update all affected releases to 1.6.7, for this reason, and to ensure that their libafs module will still compile with newer kernels. However, updating this package for stable releases continues to be blocked by packaging issues, as documented in Bug 7085 Comment 27 and onward. I've updated to 1.6.7 in Cauldron. Reproducible: Steps to Reproduce:
Blocks: (none) => 7085Whiteboard: (none) => MGA3TOO
Blocks: (none) => 12201
Upstream has issued an advisory on June 12, fixing a new security issue: http://www.openafs.org/security/OPENAFS-SA-2014-002.txt http://www.openafs.org/dl/openafs/1.6.9/RELNOTES-1.6.9 http://www.openafs.org/pipermail/openafs-announce/2014/000468.html
Summary: openafs new security issue CVE-2014-0159 => openafs new security issues CVE-2014-0159 and CVE 2014-4044
Status: NEW => ASSIGNEDCC: (none) => thomasAssignee: bugsquad => thomas
This bugs have been fixed with versions 1.6.9 or higher. I have put version 1.6.10 in mga4 updates_testing. I have done some preliminary testing: The package installs, the dkms bulds (be patient, it takes a while), the server and the client start, restarts and stops w/o error messages. The following packages are in updates_testing: openafs-1.6.10-1.1.mga4.src.rpm openafs-1.6.10-1.1.mga4.x86_64.rpm openafs-client-1.6.10-1.1.mga4.x86_64.rpm openafs-server-1.6.10-1.1.mga4.x86_64.rpm lib64openafs1-1.6.10-1.1.mga4.x86_64.rpm lib64openafs-devel-1.6.10-1.1.mga4.x86_64.rpm lib64openafs-static-devel-1.6.10-1.1.mga4.x86_64.rpm dkms-libafs-1.6.10-1.1.mga4.noarch.rpm openafs-doc-1.6.10-1.1.mga4.noarch.rpm openafs-debuginfo-1.6.10-1.1.mga4.x86_64.rpm and i586 versions Assigning this to QA
Hardware: i586 => AllQA Contact: security => qa-bugs
Actually assigning to QA. Removing Mageia 3 from the whiteboard due to EOL. I'll write an advisory tomorrow, but the references for the security issues are in Comment 0 and Comment 1. We tried to update this in the past, but it was rejected by QA due to packaging issues. I believe Thomas has addressed these issues now and that we should be able to actually update this.
Assignee: thomas => qa-bugsQA Contact: qa-bugs => securityWhiteboard: MGA3TOO => (none)
Advisory: ======================== Updated openafs packages fix security vulnerabilities: Buffer overflow in the GetStatistics64 remote procedure call (RPC) in OpenAFS before 1.6.7 allows remote attackers to cause a denial of service (crash) via a crafted statsVersion argument (CVE-2014-0159). OpenAFS before 1.6.7 delays the listen thread when an RXS_CheckResponse fails, which allows remote attackers to cause a denial of service (performance degradation) via an invalid packet (CVE-2014-2852). OpenAFS 1.6.8 does not properly clear the fields in the host structure, which allows remote attackers to cause a denial of service (uninitialized memory access and crash) via unspecified vectors related to TMAY requests (CVE-2014-4044). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0159 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2852 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4044 http://www.openafs.org/security/OPENAFS-SA-2014-001.txt http://www.openafs.org/dl/openafs/1.6.7/RELNOTES-1.6.7 http://www.openafs.org/pipermail/openafs-announce/2014/000460.html http://www.openafs.org/security/OPENAFS-SA-2014-002.txt http://www.openafs.org/dl/openafs/1.6.9/RELNOTES-1.6.9 http://www.openafs.org/pipermail/openafs-announce/2014/000468.html https://www.debian.org/security/2014/dsa-2899
Advisory: ======================== Updated openafs packages fix security vulnerabilities: Buffer overflow in the GetStatistics64 remote procedure call (RPC) in OpenAFS before 1.6.7 allows remote attackers to cause a denial of service (crash) via a crafted statsVersion argument (CVE-2014-0159). OpenAFS before 1.6.7 delays the listen thread when an RXS_CheckResponse fails, which allows remote attackers to cause a denial of service (performance degradation) via an invalid packet (CVE-2014-2852). OpenAFS 1.6.8 does not properly clear the fields in the host structure, which allows remote attackers to cause a denial of service (uninitialized memory access and crash) via unspecified vectors related to TMAY requests (CVE-2014-4044). The OpenAFS package has been updated to version 1.6.10, fixing these issues and other bugs, as well as providing support for newer kernel versions. References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0159 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2852 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4044 http://www.openafs.org/security/OPENAFS-SA-2014-001.txt http://www.openafs.org/security/OPENAFS-SA-2014-002.txt http://www.openafs.org/dl/openafs/1.6.7/RELNOTES-1.6.6 http://www.openafs.org/dl/openafs/1.6.7/RELNOTES-1.6.7 http://www.openafs.org/dl/openafs/1.6.7/RELNOTES-1.6.8 http://www.openafs.org/dl/openafs/1.6.9/RELNOTES-1.6.9 http://www.openafs.org/dl/openafs/1.6.7/RELNOTES-1.6.10 https://lists.openafs.org/pipermail/openafs-announce/2014/000455.html https://lists.openafs.org/pipermail/openafs-announce/2014/000460.html https://lists.openafs.org/pipermail/openafs-announce/2014/000467.html https://lists.openafs.org/pipermail/openafs-announce/2014/000468.html https://lists.openafs.org/pipermail/openafs-announce/2014/000472.html https://www.debian.org/security/2014/dsa-2899
openafs-debuginfo not in core/updates-testing??
CC: (none) => herman.viaene
(In reply to Herman Viaene from comment #6) > openafs-debuginfo not in core/updates-testing?? -debuginfo packages are in "Debug" repos, but we don't test them. They only contain debugging info (hence the name) needed to diagnose software issues involving the concerned library/package (e.g. if a software uses libopenafs1 and crashes because of it, you need openafs-debuginfo to get a backtrace using gdb).
CC: (none) => remi
Testing MGA4-64 on HP Probook 6555b. Installed without problems. Server service could be stopped/started in MCC. As root at the CLI: systemctl restart openafs-server.service just returns, seems OK and systemctl status openafs-server.service openafs-server.service - OpenAFS Server Service Loaded: loaded (/usr/lib/systemd/system/openafs-server.service; enabled) Active: active (running) since Sat 2014-12-06 10:45:33 CET; 19s ago Process: 10154 ExecStop=/usr/bin/bos shutdown localhost -wait -localauth (code=exited, status=0/SUCCESS) Main PID: 10158 (bosserver) CGroup: /system.slice/openafs-server.service ââ10158 /usr/sbin/bosserver -nofork Dec 06 10:45:33 localhost.localdomain systemd[1]: Started OpenAFS Server Serv... Hint: Some lines were ellipsized, use -l to show in full. I did not venture into setting up a real server configuration.
Whiteboard: (none) => MGA4-64-OK
I didn't change a lot besides the service files. I think, if it worked before it should work now. So for the security upgrade, it wouldn't be a regression if the server doesn't run correctly. But if someone is familiar with the server (I just did the security upgrade since the package doesn't have a maintainer) it wouldn't hurt to check it out.
Testing complete mga4 32 Before ------ (bad exit status: 1) Error! Bad return status for module build on kernel: 3.12.21-desktop586-2.mga4 (i586) Consult the make.log in the build directory /var/lib/dkms/libafs/1.6.5.1-2.mga4/build/ for more information. Error! Could not locate libafs.ko.xz for module libafs in the DKMS tree. You must run a dkms build for kernel 3.12.21-desktop586-2.mga4 (i586) first. warning: %post(dkms-libafs-1.6.5.1-2.mga4.noarch) scriptlet failed, exit status 4 ERROR: 'script' failed for dkms-libafs-1.6.5.1-2.mga4.noarch: # systemctl start openafs-server.service [root@russpooter ~]# systemctl status openafs-server.service openafs-server.service - OpenAFS Server Service Loaded: loaded (/usr/lib/systemd/system/openafs-server.service; enabled) Active: inactive (dead) since Mon 2014-12-08 14:54:01 GMT; 7s ago Process: 15154 ExecStop=/usr/bin/bos shutdown localhost -wait -localauth (code=exited, status=0/SUCCESS) Process: 15151 ExecStart=/usr/sbin/bosserver $BOSSERVER_ARGS (code=exited, status=0/SUCCESS) Main PID: 15151 (code=exited, status=0/SUCCESS) # systemctl start openafs-client.service Job for openafs-client.service failed. See 'systemctl status openafs-client.service' and 'journalctl -xn' for details. # journalctl -xn ...etc -- Unit openafs-client.service has begun starting up. modprobe[15196]: modprobe: FATAL: Module libafs not found. After ----- Building module: cleaning build area....(bad exit status: 2) It takes a long time but the build does complete ok DKMS: build Completed. libafs.ko.xz: - Installation - Installing to /lib/modules/3.12.21-desktop586-2.mga4/dkms/3rdparty/libafs// # systemctl start openafs-server.service # systemctl status openafs-server.service openafs-server.service - OpenAFS Server Service Loaded: loaded (/usr/lib/systemd/system/openafs-server.service; enabled) Active: active (running) since Mon 2014-12-08 15:02:10 GMT; 3s ago # systemctl start openafs-client.service # systemctl status openafs-client.service openafs-client.service - OpenAFS Client Service Loaded: loaded (/usr/lib/systemd/system/openafs-client.service; enabled) Active: active (running) since Mon 2014-12-08 15:02:21 GMT; 5s ago Well done Thomas, this has been broken for some time IIRC.
Whiteboard: MGA4-64-OK => MGA4-64-OK mga4-32-ok has_procedure
(In reply to claire robinson from comment #10) > > libafs.ko.xz: > - Installation > - Installing to > /lib/modules/3.12.21-desktop586-2.mga4/dkms/3rdparty/libafs// > Has anyone confirmed it builds against 3.14 series kernels that we now use in mga4?
CC: (none) => tmb
hrmmm well spotted. Not sure why, this box isn't even listing the newer desktop586 kernels in grub. I'll remove them and reinstall, should correct things.
(In reply to Thomas Backlund from comment #11) > Has anyone confirmed it builds against 3.14 series kernels that we now use > in mga4? It's the newest current version; it is documented to support 3.14, so it should. It does not support 3.18, so we will need to update it in Cauldron again when the next version is finalized (it's in pre-release status right now) before mga5.
I dropped it from cauldron - is Thomas planning to bring it back?
CC: (none) => mageia
(In reply to Sander Lepik from comment #14) > I dropped it from cauldron - is Thomas planning to bring it back? I believe that Thomas has fixed the packaging issues that kept us from being able to issue updates for it in the past. If that's indeed the case and this update passes QA, there's no reason not to bring it back. It'll be trivial to maintain (just update the tarball for newer versions). I can handle that.
Testing in mga4 32 vbox client until I fix the other box Some transactional ordering issues installing the kernel-devel packages, plus it doesn't require lib64openafs1 which seems odd. # urpmi openafs openafs-client openafs-server Preparing... ############################################# 1/9: libncurses-devel ############################################# 2/9: kernel-desktop-devel-3.14.25-1.mga4 ############################################# 3/9: dkms ############################################# 4/9: dkms-libafs ############################################# Creating symlink /var/lib/dkms/libafs/1.6.10-1.1.mga4/source -> /usr/src/libafs-1.6.10-1.1.mga4 DKMS: add Completed. Error! Your kernel devel files for kernel 3.14.24-desktop-1.mga4 cannot be found at /lib/modules/3.14.24-desktop-1.mga4/build or /lib/modules/3.14.24-desktop-1.mga4/source. You can use the --kernelsourcedir option to tell DKMS where it's located. Error! Could not locate libafs.ko.xz for module libafs in the DKMS tree. You must run a dkms build for kernel 3.14.24-desktop-1.mga4 (i586) first. warning: %post(dkms-libafs-1.6.10-1.1.mga4.noarch) scriptlet failed, exit status 4 ERROR: 'script' failed for dkms-libafs-1.6.10-1.1.mga4.noarch: 5/9: openafs ############################################# 6/9: openafs-client ############################################# 7/9: kernel-desktop-devel-latest ############################################# 8/9: kernel-desktop-devel-3.14.24-1.mga4 ############################################# $MIRRORLIST: media/core/updates_testing/openafs-server-1.6.10-1.1.mga4.i586.rpm installing openafs-server-1.6.10-1.1.mga4.i586.rpm from /var/cache/urpmi/rpms Preparing... ############################################# 9/9: openafs-server #############################################
doesn't require libopenafs1 i mean. It's a 32bit VM.
(In reply to Thomas Backlund from comment #11) > (In reply to claire robinson from comment #10) > > > > > libafs.ko.xz: > > - Installation > > - Installing to > > /lib/modules/3.12.21-desktop586-2.mga4/dkms/3rdparty/libafs// > > > > > Has anyone confirmed it builds against 3.14 series kernels that we now use > in mga4? It should work with 3.14. as I built it locally with this Kernel. But I will check if it builds with mga5/cauldron From upstream: Linux clients * Support kernels up to 3.16 (11308 11309)
The module does build at reboot with 3.14.24. It takes an eternity to do so (~20 minutes!) but it does and services start ok.
Any objections to validating?
(In reply to Thomas Spuhler from comment #18) > It should work with 3.14. as I built it locally with this Kernel. But I will > check if it builds with mga5/cauldron > > From upstream: > > Linux clients > > * Support kernels up to 3.16 (11308 11309) Right, and the 1.6.11 release candidate announcement says it'll support 3.17 and probably 3.18: https://lists.openafs.org/pipermail/openafs-announce/2014/000476.html
(In reply to claire robinson from comment #20) > Any objections to validating? Have we confirmed that the issues documented in Bug 7085 Comment 27 and onward have been resolved? I believe they should be, but just want to be sure. It wouldn't hurt to let treegazer have a look at this either.
dkms module builds which it didn't before. Server and client services both start, which they didn't before..
(In reply to David Walser from comment #22) > (In reply to claire robinson from comment #20) > > Any objections to validating? > > Have we confirmed that the issues documented in Bug 7085 Comment 27 and > onward have been resolved? I believe they should be, but just want to be > sure. It wouldn't hurt to let treegazer have a look at this either. Bug 7085 Comment 27 we now have /afs:/var/cache/openafs:100000 But I agree, if someone who uses it could do some testing would be very valuable.
CC: (none) => paul.blackburn
(In reply to claire robinson from comment #23) > dkms module builds which it didn't before. Server and client services both > start, which they didn't before.. OK, I believe all of the previous issues have been addressed. We'll see if Paul is interested in having a look at it.
Validating. Advisory uploaded. Please push to updates Thanks
Keywords: (none) => validated_updateWhiteboard: MGA4-64-OK mga4-32-ok has_procedure => MGA4-64-OK mga4-32-ok has_procedure advisoryCC: (none) => sysadmin-bugs
testing on Mageia release 4 (Official) for i586
I don't have a local cell available to test so I tried defining client as a client of the public grand.central.org cell: # cat /etc/openafs/ThisCell grand.central.org attempted to start OpenAFS client using systemd: # systemctl -a | grep openafs openafs-client.service loaded failed failed OpenAFS Client Service # systemctl status openafs-client.service openafs-client.service - OpenAFS Client Service Loaded: loaded (/usr/lib/systemd/system/openafs-client.service; enabled) Active: inactive (dead) # systemctl enable openafs-client.service ln -s '/usr/lib/systemd/system/openafs-client.service' '/etc/systemd/system/remote-fs.target.wants/openafs-client.service' # systemctl start openafs-client.service Job for openafs-client.service failed. See 'systemctl status openafs-client.service' and 'journalctl -xn' for details. [root@dhcp-192-168-101-127 openafs]# systemctl status openafs-client.service openafs-client.service - OpenAFS Client Service Loaded: loaded (/usr/lib/systemd/system/openafs-client.service; enabled) Active: failed (Result: exit-code) since Tue 2014-12-09 17:30:57 GMT; 12s ago Process: 16608 ExecStart=/sbin/afsd $AFSD_ARGS (code=exited, status=1/FAILURE) Process: 16602 ExecStartPre=/sbin/modprobe libafs (code=exited, status=0/SUCCESS) Process: 16599 ExecStartPre=/bin/chmod 0644 /etc/openafs/CellServDB (code=exited, status=0/SUCCESS) Process: 16597 ExecStartPre=/bin/sed -n w/etc/openafs/CellServDB /etc/openafs/CellServDB.local /etc/openafs/CellServDB.dist (code=exited, status=0/SUCCESS) rebooted and tried again: similar failure Rebooted and tried manual start: # modprobe libafs && echo AFS kernel module loaded || echo Failed to load libafs AFS kernel module loaded # /sbin/afsd -stat 2000 -dcache 800 -daemons 3 -volumes 70 -nosettime -afsdb afsd: All AFS daemons started. afsd: Can't mount AFS on /afs(22) Not sure why we are getting "afsd: Can't mount AFS on /afs(22)". Will continue to investigate
Tried again, this time changing the config to be a client of slackers.net # cat /etc/openafs/ThisCell slackers.net Manual start: # modprobe libafs && echo AFS kernel module loaded || echo Failed to load libafs AFS kernel module loaded # /sbin/afsd -stat 2000 -dcache 800 -daemons 3 -volumes 70 -nosettime -afsdb afsd: All AFS daemons started. # df | grep afs AFS 2.0T 0 2.0T 0% /afs # ls /afs/slackers.net projects/ software/ users/
Tried again with systemd. # systemctl status openafs-client.service openafs-client.service - OpenAFS Client Service Loaded: loaded (/usr/lib/systemd/system/openafs-client.service; disabled) Active: inactive (dead) # systemctl enable openafs-client.service ln -s '/usr/lib/systemd/system/openafs-client.service' '/etc/systemd/system/multi-user.target.wants/openafs-client.service' ln -s '/usr/lib/systemd/system/openafs-client.service' '/etc/systemd/system/remote-fs.target.wants/openafs-client.service reboot # systemctl status openafs-client.service openafs-client.service - OpenAFS Client Service Loaded: loaded (/usr/lib/systemd/system/openafs-client.service; enabled) Active: active (running) since Tue 2014-12-09 18:22:39 GMT; 33s ago Process: 4760 ExecStart=/sbin/afsd $AFSD_ARGS (code=exited, status=0/SUCCESS) Process: 4718 ExecStartPre=/sbin/modprobe libafs (code=exited, status=0/SUCCESS) Process: 4706 ExecStartPre=/bin/chmod 0644 /etc/openafs/CellServDB (code=exited, status=0/SUCCESS) Process: 4677 ExecStartPre=/bin/sed -n w/etc/openafs/CellServDB /etc/openafs/CellServDB.local /etc/openafs/CellServDB.dist (code=exited, status=0/SUCCESS) Main PID: 4777 (afsd) CGroup: /system.slice/openafs-client.service ââ4777 /sbin/afsd -stat 2000 -dcache 800 -daemons 3 -volumes 70 -nosettime -afsdb Dec 09 18:22:35 dhcp-192-168-101-127.home systemd[1]: Starting OpenAFS Client Service... Dec 09 18:22:37 dhcp-192-168-101-127.home afsd[4760]: afsd: All AFS daemons started. Dec 09 18:22:39 dhcp-192-168-101-127.home afsd[4760]: afsd: All AFS daemons started. Dec 09 18:22:39 dhcp-192-168-101-127.home systemd[1]: Started OpenAFS Client Service. # df | grep afs AFS 2.0T 0 2.0T 0% /afs # ls -l /afs/slackers.net/ total 8 drwxrwxr-x 2 502 502 2048 Nov 7 2008 projects/ drwxrwxrwx 2 root root 2048 Jan 11 2006 software/ drwxrwxr-x 2 2572 root 4096 Jul 9 21:50 users/ Woohoo! it worked with systemd on 32-bit Mageia 4 Will try on 64-bit next.
Thanks for testing Paul! Also thank you Thomas for the packaging work! I've synced the update back into Cauldron and it's built now.
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2014-0515.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
LWN reference for CVE-2014-2852 and CVE-2014-4044: http://lwn.net/Vulnerabilities/625503/