Debian has issued an advisory on February 16, 2011: http://www.debian.org/security/2011/dsa-2168 Presumably they have patches for this. Furthermore, an update for Mageia 1 was issued to a newer version that does not appear in Mageia 2. Mageia 1 version: openafs-1.4.14.1-1.1.mga1
CC: (none) => pterjanWhiteboard: (none) => MGA2TOO, MGA1TOO
CC: (none) => dmorganec
CC: (none) => shlomif
CC: (none) => alexander
*** Bug 6182 has been marked as a duplicate of this bug. ***
CC: (none) => stormi
CC: (none) => goetz.waschk
Nicolas has built an update for this in Mageia 2, which I would guess fixes this. If so, this needs to be backported to Mageia 1 as well. Also, Shlomi updated it in Cauldron, so it should be fixed there as well. Minor note to Nicolas, the release tag should be 1, not 0.1, by our policy. Here's what was built in Mageia 2 updates_testing. openafs-1.6.1-0.1.mga2 openafs-client-1.6.1-0.1.mga2 openafs-server-1.6.1-0.1.mga2 libopenafs1-1.6.1-0.1.mga2 libopenafs-devel-1.6.1-0.1.mga2 libopenafs-static-devel-1.6.1-0.1.mga2 dkms-libafs-1.6.1-0.1.mga2 openafs-doc-1.6.1-0.1.mga2 from openafs-1.6.1-0.1.mga2.src.rpm
CC: (none) => nicolas.lecureuilBlocks: (none) => 6008
openafs-1.4.14.1-1.1.mga1 I updated it to 1.6 version because our kernel too fresh for 1.4
(In reply to comment #3) > openafs-1.4.14.1-1.1.mga1 > > I updated it to 1.6 version > because our kernel too fresh for 1.4 It was updated to 1.6 in Mageia 2 updates_testing, but not Mageia 1 yet...
Ping? We still need an update for Mageia 1.
CC: (none) => oe
Nicolas has built the updated for Mageia 1 as well. Advisory pending. openafs-1.6.1-1.1.mga1 openafs-client-1.6.1-1.1.mga1 openafs-server-1.6.1-1.1.mga1 libopenafs1-1.6.1-1.1.mga1 libopenafs-devel-1.6.1-1.1.mga1 libopenafs-static-devel-1.6.1-1.1.mga1 dkms-libafs-1.6.1-1.1.mga1 openafs-doc-1.6.1-1.1.mga1 from openafs-1.6.1-1.1.mga1.src.rpm
The Mageia 2 package was rebuilt to fix the release tag. Assigning to QA. Advisory: ======================== Updated openafs packages fix security vulnerabilities: Double free vulnerability in the Rx server process in OpenAFS 1.4.14, 1.4.12, 1.4.7, and possibly other versions allows remote attackers to cause a denial of service and execute arbitrary code via unknown vectors (CVE-2011-0430). The afs_linux_lock function in afs/LINUX/osi_vnodeops.c in the kernel module in OpenAFS 1.4.14, 1.4.12, 1.4.7, and possibly other versions does not properly handle errors, which allows attackers to cause a denial of service via unknown vectors (CVE-2011-0431). OpenAFS has been upgraded to 1.6.1 to fix these issues. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0430 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0431 http://www.debian.org/security/2011/dsa-2168 ======================== Updated packages in core/updates_testing: ======================== openafs-1.6.1-1.1.mga1 openafs-client-1.6.1-1.1.mga1 openafs-server-1.6.1-1.1.mga1 libopenafs1-1.6.1-1.1.mga1 libopenafs-devel-1.6.1-1.1.mga1 libopenafs-static-devel-1.6.1-1.1.mga1 dkms-libafs-1.6.1-1.1.mga1 openafs-doc-1.6.1-1.1.mga1 openafs-1.6.1-1.1.mga2 openafs-client-1.6.1-1.1.mga2 openafs-server-1.6.1-1.1.mga2 libopenafs1-1.6.1-1.1.mga2 libopenafs-devel-1.6.1-1.1.mga2 libopenafs-static-devel-1.6.1-1.1.mga2 dkms-libafs-1.6.1-1.1.mga2 openafs-doc-1.6.1-1.1.mga2 from SRPMS: openafs-1.6.1-1.1.mga1.src.rpm openafs-1.6.1-1.1.mga2.src.rpm
Version: Cauldron => 2Assignee: tmb => qa-bugsWhiteboard: MGA2TOO, MGA1TOO => MGA1TOO
Quick start quide, here onwards.. http://docs.openafs.org/QuickStartUnix/ch02s11.html (maybe)
No PoC's
Looking for pam_afs.so, according to urpmq, it should be in libopenafs1, but once it's installed, the file is not there. [root@i1v ~]# urpmq -l libopenafs1|grep pam|sort -u /usr/lib/pam_afs.krb.so.1 /usr/lib/pam_afs.so.1 [root@i1v ~]# rpm -q -l libopenafs1 /usr/lib/libafsauthent.so.1 /usr/lib/libafsauthent.so.1.1 /usr/lib/libafsrpc.so.1 /usr/lib/libafsrpc.so.1.5 /usr/lib/libkopenafs.so.1 /usr/lib/libkopenafs.so.1.1 This is on a Mageia 1 i586 system. Any suggestions?
CC: (none) => davidwhodgins
Looks like a problem with the new build. On Mageia 2 x86-64 ... [root@x2 ~]# urpmq -l --media "Core 32bit Release (distrib31)" libopenafs1 /usr/lib/libafsauthent.so.1 /usr/lib/libafsauthent.so.1.1 /usr/lib/libafsrpc.so.1 /usr/lib/libafsrpc.so.1.1 /usr/lib/libafssetpag.so.1 /usr/lib/libafssetpag.so.1.0 /usr/lib/pam_afs.krb.so.1 /usr/lib/pam_afs.so.1 [root@x2 ~]# urpmq -l --media "Core 32bit Updates Testing (distrib35)" libopenafs1 /usr/lib/libafsauthent.so.1 /usr/lib/libafsauthent.so.1.1 /usr/lib/libafsrpc.so.1 /usr/lib/libafsrpc.so.1.5 /usr/lib/libkopenafs.so.1 /usr/lib/libkopenafs.so.1.1 So the pam_afs* modules are in the release version, but not in the update.
Whiteboard: MGA1TOO => MGA1TOO feedback
i take a look ( this affect cauldron too )
The update candidate 1.5.1-1.1.mga2 has this problem: # urpmi openafs-client $MIRRORLIST: media/core/updates_testing/openafs-client-1.6.1-1.1.mga2.x86_64.rpm openafs-client-1.6.1-1.1.mga2.x86_64.rpm von <link:url>/var/cache/urpmi/rpms</link:url> wird installiert Vorbereiten ⦠############################################# 1/1: openafs-client ############################################# Failed to issue method call: Unit openafs.service failed to load: No such file or directory. See system logs and 'systemctl status openafs.service' for details. The postinstall script should be this: /usr/share/rpm-helper/add-service openafs-client $1 openafs-client same for %preun
I have fixed the issue from comment 13 in Cauldron, it just needs to be submitted to 2. Otherwise, at least the AFS client is working fine in 2.
i would like that we fix the pam_ issue too ( would do only one submit for the stable release ). Do you have an idea ? ( comment #10 and #11 )
Assigning Nicolas. Please reassign to QA when you've had a chance to look into this. Thanks!
CC: (none) => qa-bugsAssignee: qa-bugs => nicolas.lecureuilWhiteboard: MGA1TOO feedback => MGA1TOO
Ping. What's the status on this? This is high severity and remotely exploitable according to Debian. We are running out of time to fix this on Mageia 1.
Severity: normal => critical
Removing Mageia 1 from the whiteboard due to EOL. Debian has issued an advisory on March 4: http://www.debian.org/security/2013/dsa-2638 This adds two new security issues, CVE-2013-1794 and CVE-2013-1795. I've added patches for these in Mageia 2 and Cauldron, but we still need to fix the other issues with this so that we can release an update for Mageia 2. from http://lwn.net/Vulnerabilities/541298/
Summary: openafs missing update for security issues CVE-2011-0430 and CVE-2011-0431 => openafs missing update for security issues CVE-2011-043[01] and new security issues CVE-2013-179[45]Whiteboard: MGA1TOO => (none)
The missing pam_afs was simply because it was rm'd in the SPEC. I've reverted that change, and now pam_afs is included. I've also updated it to 1.6.2.1. These fixes are in openafs-1.6.2.1-1.mga3, now uploaded in Cauldron. I've also backported these changes, along with Götz's service fix to Mageia 2. Advisory: ======================== Updated openafs packages fix security vulnerabilities: Double free vulnerability in the Rx server process in OpenAFS 1.4.14, 1.4.12, 1.4.7, and possibly other versions allows remote attackers to cause a denial of service and execute arbitrary code via unknown vectors (CVE-2011-0430). The afs_linux_lock function in afs/LINUX/osi_vnodeops.c in the kernel module in OpenAFS 1.4.14, 1.4.12, 1.4.7, and possibly other versions does not properly handle errors, which allows attackers to cause a denial of service via unknown vectors (CVE-2011-0431). Buffer overflow in certain client utilities in OpenAFS before 1.6.2 allows remote authenticated users to cause a denial of service (crash) and possibly execute arbitrary code via a long fileserver ACL entry (CVE-2013-1794). Integer overflow in ptserver in OpenAFS before 1.6.2 allows remote attackers to cause a denial of service (crash) via a large list from the IdToName RPC, which triggers a heap-based buffer overflow (CVE-2013-1795). OpenAFS has been upgraded to 1.6.2.1 to fix these issues. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0430 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0431 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1794 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1795 http://www.openafs.org/dl/openafs/1.6.2.1/RELNOTES-1.6.2.1 http://www.openafs.org/dl/openafs/1.6.2/RELNOTES-1.6.2 http://www.openafs.org/dl/openafs/1.6.1/RELNOTES-1.6.1 http://www.openafs.org/dl/openafs/1.6.0/RELNOTES-1.6.0 http://www.openafs.org/dl/openafs/1.4.14.1/RELNOTES-1.4.14.1 http://www.debian.org/security/2011/dsa-2168 http://www.debian.org/security/2013/dsa-2638 ======================== Updated packages in core/updates_testing: ======================== openafs-1.6.2.1-1.mga2 openafs-client-1.6.2.1-1.mga2 openafs-server-1.6.2.1-1.mga2 libopenafs1-1.6.2.1-1.mga2 libopenafs-devel-1.6.2.1-1.mga2 libopenafs-static-devel-1.6.2.1-1.mga2 dkms-libafs-1.6.2.1-1.mga2 openafs-doc-1.6.2.1-1.mga2 from openafs-1.6.2.1-1.mga2.src.rpm
Assignee: nicolas.lecureuil => qa-bugs
Testing Mageia 2 i586 shortly, using the procedure from https://wiki.mageia.org/en/QA_procedure:Krb5 and the instructions from http://www.ibm.com/developerworks/opensource/library/os-openafs-kerberos5/index.html
(In reply to Paul Blackburn from Bug 6008) > Next problem is that openafs-server and openafs-client startup fails. > These used to be in: /etc/init.d/openafs-server and > /etc/init.d/openafs-client > > I am not quite sure how these are supposed to work with systemd. They work the same as before, even the service command should still work. If you want to use the native systemd command, it's systemctl. However, for the Mageia 2 package, those init scripts shouldn't have been removed, as we still support SysV there. > Anyway, the server and client daemons were not automatically started on > reboot. Are you sure? I do see the scriplet for enabling the client service. The scriptlet for enabling the server service is indeed missing though. > The server should be started before the client. > > I manually started thusly: > > # bosserver # start OpenAFS server daemons > > > # modprobe libafs # load OpenAFS libafs kernel module (for client) > # afsd -nosettime # start OpenAFS Cache Manager > afsd: All AFS daemons started. > > > # df /afs > Filesystem Size Used Avail Use% Mounted on > AFS 8.6G 0 8.6G 0% /afs OK so it looks like it works at least, that's good.
CC: (none) => paul.blackburn
Hello David, I did not see any init scripts in the OpenAFS 1.6.2.1-1 rpms. So, I assumed they would start automagically with systemd on reboot but unfortunately they did not. I then pulled init scripts from the older 1.4 release and copied them to /etc/init.d/ and rebooted. No joy with that either. Hence the manual start to check things are working. The server init script essentially runs the "bosserver" command. The client init script needs to load the libafs kernel module then run the AFS cache manager "afsd". I do not know enough about systemd to understand how the libafs kernel module would get loaded for client initialization. I have completed building a kerberos5 and an OpenAFS server to test this bug and am now in proceeding to configure the AFS cell to make an environment for testing.
(In reply to Paul Blackburn from comment #22) > Hello David, > > I did not see any init scripts in the OpenAFS 1.6.2.1-1 rpms. Right, as I said, they shouldn't have been removed (but they were when it was updated to 1.6.1). > So, I assumed they would start automagically with systemd on reboot > but unfortunately they did not. Yes, we do want them to start automatically. I can see why the -server package isn't doing it, but the -client package should be already. What does "systemctl status openafs-client.service" give you on the client? > I then pulled init scripts from the older 1.4 release and copied them to > /etc/init.d/ and rebooted. No joy with that either. Well just having the scripts won't make them run, you'd need to enable them. If you're using systemd, it won't use those scripts anyway (since there are native service files). Do the old scripts still work if you run them manually to start and stop the services? > Hence the manual start to check things are working. > > The server init script essentially runs the "bosserver" command. > The client init script needs to load the libafs kernel module > then run the AFS cache manager "afsd". > > I do not know enough about systemd to understand how the libafs kernel module > would get loaded for client initialization. > > I have completed building a kerberos5 and an OpenAFS server to test this bug > and am now in proceeding to configure the AFS cell to make an environment > for testing. Thanks. You can see these files in /lib/systemd/system yourself, but just to point out the relevant bits so you can see what they do. openafs-server.service has this in it: EnvironmentFile=-/etc/sysconfig/openafs ExecStart=/usr/sbin/bosserver $BOSSERVER_ARGS ExecStop=/usr/bin/bos shutdown localhost -wait -localauth which means it loads environment variables (including BOSSERVER_ARGS) from /etc/sysconfig/openafs, and then runs "/usr/sbin/bosserver $BOSSERVER_ARGS" when you start the service and "/usr/bin/bos shutdown localhost -wait -localauth" when you stop the service. openafs-client.service has this in it: EnvironmentFile=/etc/sysconfig/openafs ExecStartPre=/sbin/modprobe libafs ExecStart=/usr/sbin/afsd $AFSD_ARGS ExecStop=/bin/umount /afs ExecStop=/usr/sbin/afsd -shutdown ExecStop=/usr/bin/rmmod libafs which means it reads environment variables from the same file (including AFSD_ARGS) and runs "/sbin/modprobe libafs" then "/usr/sbin/afsd $AFSD_ARGS" when you start the service and "/bin/umount /afs; /usr/sbin/afsd -shutdown; /usr/bin/rmmod libafs" when you stop the service.
BTW. ntp is also missing sysv scripts.
(In reply to Oden Eriksson from comment #24) > BTW. ntp is also missing sysv scripts. [david@marin ~]$ rpm -qf /etc/rc.d/init.d/ntpd ntp-4.2.6p5-5.mga2
My bad. Confused MBS1 with MGA2..
I have no idea where fedya got the "afs.conf" source file that's used for /etc/sysconfig/openafs in the updated packages. I don't know that anything in it is really even used, other than the AFSD_ARGS and BOSSERVER_ARGS definitions. Maybe we should just use the upstream one that just has: # OpenAFS Client Configuration AFSD_ARGS="-dynroot -fakestat -afsdb" # OpenAFS Server Configuration BOSSERVER_ARGS= The only thing I'm still concerned about, Paul said when he tried to start the client service (although he had the wrong sysconfig file at the time), it complained that the cache size was too big (using defaults I guess). Those other options (stat, dcache, daemons, volumes) in the current sysconfig file we have are related to that, but I don't know if they're enough to fix that issue, or if we should even be setting those in there, or if we need to add (as upstream does) an /etc/openafs/cacheinfo file, like this: /afs:/var/cache/openafs:262144 I guess this package could use a little more work, however I don't think these issues are big enough to hold the update. So we'll see how the rest of Paul's testing goes.
If we do re-add the SysV init scripts for the Mageia 2 package, they should not be the old ones we had (which depended on the old sysconfig file), but the upstream ones. It may not be worth it, however.
Created attachment 3976 [details] log showing attempt to start OpenAFS server using systemctl fails I have been doing some more testing on the systemd startup for openafs server and client. I disabled both client and server startup, rebooted, and manually started using systemctl commands. I could not get the openafs server to start this way but the server can be started manually from commandline: # bosserver # start AFS "basic over seer" server for AFS server processes
Whiteboard: (none) => feedback
Nicolas, I'm assigning this back to you. This package needs some more work. Please see at least Comment 27, Comment 28, and Comment 29.
Assignee: qa-bugs => nicolas.lecureuil
I am working on a wiki page to provide a guide for installing OpenAFS client: https://wiki.mageia.org/en/Installing_OpenAFS_Client At the moment, this shows manually loading the AFS kernel module and starting the AFS Cache Manager (afsd). I plan to add the systemctl details for starting/stopping as soon as they are functional. (I have also prepared a guide for installing a new AFS cell using a kerberos 5 authentication server with an OpenAFS "database" and fileserver which I will add to the wiki at some point.)
Thanks Paul! This is really helpful.
OpenAFS 1.6.5 has been released, fixing two new security issues: http://openwall.com/lists/oss-security/2013/07/25/1 http://www.openafs.org/pages/security/OPENAFS-SA-2013-003.txt http://www.openafs.org/pages/security/OPENAFS-SA-2013-004.txt openafs 1.6.5 uploaded for Cauldron fixing CVE-2013-4134 and CVE-2013-4135. http://www.openafs.org/dl/openafs/1.6.4/RELNOTES-1.6.4 http://www.openafs.org/dl/openafs/1.6.5/ChangeLog (no relnotes posted yet) Holding off on updating the update candidate for Mageia 2 and building an update candidate for Mageia 3 until the packaging issues referenced in Comment 30 are addressed.
Summary: openafs missing update for security issues CVE-2011-043[01] and new security issues CVE-2013-179[45] => openafs missing update for security issues CVE-2011-043[01] and new security issues CVE-2013-179[45] and CVE-2013-413[45]QA Contact: (none) => security
LWN reference for the new security issues: http://lwn.net/Vulnerabilities/560739/
Mageia 2 is EOL, but there are still some security issues we need to fix for Mageia 3. I'm documenting here the changes I'm making to this bug now, due to Mageia 2 EOL. The bug was originally "openafs missing update for security issues CVE-2011-043[01] and new security issues CVE-2013-179[45]" and was for Mageia 2 only. All of those issues were fixed in Mageia 3 before it was released, so I'm removing those from the title now. CVE-2013-4134 and CVE-2013-4135 came to light later and still affect Mageia 3, and were added to this bug in Comment 33. This bug is now only for those issues. Also, had we issued an update for Mageia 2, it would have also fixed Bug 6008, which this bug used to block. Due to the EOL, that is no longer relevant, so I've removed it as being blocked by this bug, and it will be closed. However, an update for Mageia 3 will be needed for similar reasons, due to the kernel 3.10 update.
Version: 2 => 3Blocks: 6008 => (none)Summary: openafs missing update for security issues CVE-2011-043[01] and new security issues CVE-2013-179[45] and CVE-2013-413[45] => openafs new security issues CVE-2013-4134 and CVE-2013-4135Source RPM: openafs-1.4.14-2.mga2.src.rpm => openafs-1.6.2.1-1.mga3.src.rpmWhiteboard: feedback => (none)
Blocks: (none) => 11356
Depends on: (none) => 13188
Closing due to Mageia 3 EOL: http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/
Status: NEW => RESOLVEDResolution: (none) => OLD
(In reply to David Walser from comment #27) > I have no idea where fedya got the "afs.conf" source file that's used for > /etc/sysconfig/openafs in the updated packages. It's here: https://github.com/elrepo/packages/blob/master/openafs/el5/afs.conf >I don't know that anything > in it is really even used, other than the AFSD_ARGS and BOSSERVER_ARGS > definitions. Maybe we should just use the upstream one that just has: > # OpenAFS Client Configuration > AFSD_ARGS="-dynroot -fakestat -afsdb" > > # OpenAFS Server Configuration > BOSSERVER_ARGS= > > The only thing I'm still concerned about, Paul said when he tried to start > the client service (although he had the wrong sysconfig file at the time), > it complained that the cache size was too big (using defaults I guess). > Those other options (stat, dcache, daemons, volumes) in the current > sysconfig file we have are related to that, but I don't know if they're > enough to fix that issue, or if we should even be setting those in there, or > if we need to add (as upstream does) an /etc/openafs/cacheinfo file, like > this: > /afs:/var/cache/openafs:262144 > > I guess this package could use a little more work, however I don't think > these issues are big enough to hold the update. So we'll see how the rest > of Paul's testing goes.
CC: (none) => thomas
(In reply to Thomas Spuhler from comment #37) > (In reply to David Walser from comment #27) > > I have no idea where fedya got the "afs.conf" source file that's used for > > /etc/sysconfig/openafs in the updated packages. > It's here: > https://github.com/elrepo/packages/blob/master/openafs/el5/afs.conf Thanks, that's good to know. It still doesn't appear to be the appropriate file to use in a current openafs package.
Thomas, I noticed your commit 800135: - replaced Fedora specific afs.conf file with a generic from MIT * upstream doesn't provide on That's not correct either, upstream does provide one. See src/packaging/RedHat in the source tarball. The file is called openafs.sysconfig there. It defines the AFSD_ARGS and BOSSERVER_ARGS variables used by the service files. The one you uploaded doesn't. Also note that src/packaging/RedHat contains service files. It might be better to patch and use those than including seperate source files.
Thanks for finding them. I tried to find them in the SRPM