(From upstream advisory)
OpenAFS uses Kerberos tickets to secure network traffic. For historical
reasons, it has only supported the DES encryption algorithm to encrypt
these tickets. The weakness of DES's 56 bit key space has long been
known, however it has recently become possible to use that weakness
to cheaply (around $100) and rapidly (approximately 23 hours) compromise
a service's long term key.
An attacker must first obtain a ticket for the cell. They may then use
a brute force attack to compromise the cell's private service key.
Once an attacker has gained access to the service key, they can use this
to impersonate any user within the cell, including the super user, giving
them access to all administrative capabilities as well as all user data.
An attacker may gain complete control over the targeted cell.
No publicly available exploits are currently known.
All current releases of OpenAFS. This is all releases prior to 1.4.15, all
releases in the 1.6 series prior to 1.6.5 and all releases in the 1.7 series
prior to 1.7.26.
I believe this bug should be reclassified as a B0 security hole. The reason for this is the bos exec command found in AFS.
bos exec allows an appropriately credentialed user (usually the AFS administrators) to execute arbitrary shell commands on any server in the AFS realm that is running the Bosserver (Basic Overseer); generally this is any AFS server. The bos exec command can be used from All shell commands are run without any logging on the server and with root privileges.
Therefore, since this security hole allows anyone to impersonate any user in the AFS realm, it would allow them to impersonate the AFS administrators (which can be listed by anyone with even normal AFS access) and execute any shell command on any AFS server as root with no logging of the commands run.
Let's get this stabilized. Arches, please test and stabilize:
Target arches for both: amd64 sparc x86
*** Bug 482962 has been marked as a duplicate of this bug. ***
Some issues here:
-build log not verbose
-calls ar directly
-calls gcc directly
-cflags not respected
The rest is ok. I want to know the maintainer's opinion. Do you think we can stabilize it, or do you preffer to fix those issues first?
I will check those things above over the weekend, but my bet is that they cannot be changed easily due to specific requirements of the build system.
openafs-1.6.5 seems to suffer from the same issues in src_prepare (with autotools removed from inherit) as openafs-kernel did. This should also be fixed (am doing so immediately); I'll look into ar/gcc/cflags while I'm at it.
If the maintainer could check into the importance of overriding CFLAGS, that would be appreciated.
I guess security is more important than CFLAGS, so go ahead.
Direct ar calling and verbose build log on openafs-kernel-1.6.5-r1 fixed and commited.
(In reply to Andrej Filipcic from comment #5)
> I will check those things above over the weekend, but my bet is that they
> cannot be changed easily due to specific requirements of the build system.
Ping. How is going that thing?
We have decided to keep it as is.
amd64 x86 : stable
(Based on comment 1) GLSA vote: yes.
GLSA vote: yes
Added to existing GLSA draft
OpenAFS before 1.4.15, 1.6.x before 1.6.5, and 1.7.x before 1.7.26 uses weak
encryption (DES) for Kerberos keys, which makes it easier for remote
attackers to obtain the service key.
This issue was resolved and addressed in
GLSA 201404-05 at http://security.gentoo.org/glsa/glsa-201404-05.xml
by GLSA coordinator Mikle Kolyada (Zlogene).