Bug 1066761 (CVE-2014-2015)

Created freeradius tracking bugs for this issue:

Affects: fedora-all [bug 1066763]

This issue was originally reported for SSHA (salted SHA1 hash), which does not use fixed salt string and used base64 encoding.  SSHA password hash is expected to be:

 '{SSHA}' + Base64( SHA1( password + salt ) + salt )

The + symbol is used for string concatenation.

This problem is not specific to SSHA or base64.  It affects multiple other hashing methods supported by FreeRadius, including unsalted SHA, salted or unsalted MD5, NT, and LM hash.  FreeRadius tries both hex and base64 decoding for all those formats using normify() function, with hex decoding tried first:

https://github.com/FreeRADIUS/freeradius-server/blob/63b21e1/src/modules/rlm_pap/rlm_pap.c#L244

The function uses a fixed size buffer[] to which decoded password hash value is written.  Upstream fix implements two changes:

- increases buffer[] size form 64 to 256
- correctly passes buffer[] size to fr_hex2bin() function that tries hex decoding

This fix may seem insufficient for FreeRadius 2.x, which uses base64_decode() with no bounds check.  This is a difference from FreeRadius 3.x versions, which use fr_base64_decode() with output buffer size checks.  Even before the patch, fr_base64_decode() was called with buffer size as argument, therefore properly formatted SSHA hash string with long salt could not trigger overflow in FreeRadius 3.x in base64 decoding even before this patch.  Only hex decoding was affected in 3.x.

Upstream fix is sufficient also for 2.x.  buffer[] size increase is sufficient to address the problem, as encoded hash string value is taken from vp->vp_strvalue, where:

- vp is VALUE_PAIR / struct value_pair
- vp_strvalue is #define vp_strvalue   data.strvalue
- data is VALUE_PAIR_DATA data;
- strvalue in VALUE_PAIR_DATA is char strvalue[MAX_STRING_LEN];
- MAX_STRING_LEN  is #define MAX_STRING_LEN 254

https://github.com/FreeRADIUS/freeradius-server/blob/63b21e1/src/include/libradius.h#L156
https://github.com/FreeRADIUS/freeradius-server/blob/63b21e1/src/include/libradius.h#L77

Hence inputs to decoding are shorter than the buffer[] with increased size, and decoding process generates shorter output than the input (1/2 in case of hex decoding and 3/4 in case of base64).

This problem can only be triggered when following conditions are met:

- freeradius has rlm_pap module enabled (enabled in the default configuration)
- network devices communicating with radius server use pap authentication
- attacker is able to set password hash rather than password

The last condition is typically met in any system using password authentication.  When setting password, user typically provides it in plain and hashing is performed by system or application.

In case of FreeRadius, problematic configurations may be:

- authentication uses LDAP server as backend, where userPassword attribute has self-write acl defined, and users are permitted to connect directly to LDAP.  In such configuration, use may be able to set SSHA password hash with long salt that is still a valid password hash and can be used to authenticate against LDAP.

- radius server is configured to authenticate users from multiple domains (or realms in radius terminology), with not all realms equally trusted.  Server providing passwords for one realm may be able to crash FreeRadius and block authentication for users from other realms.

This issue affects freeradius packages in Red Hat Enterprise Linux 6, and freeradius2 packages in Red Hat Enterprise Linux 5.

The freeradius packages in Red Hat Enterprise Linux 5 are not affected.  They provide FreeRadius version 1.x, which does not support salted SHA1 or MD5 password hashes.  For non-salted hashes, checking is different from what is used in FreeRadius 2.x and later.  Only hashes with expected length are processed.

Re comment #8

"attacker is able to set password hash rather than password"

This is not a requirement to trigger the issue. The normify() function is also called on password value the server looks up in it's backend data store, not just on the password passed in the request. You correctly allude to this in the 2nd to last paragraph discussing LDAP. Thus receiving a password in a request with a long salt is one trigger, another trigger is storing a password with a long salt.

Re comment #9

It also affects the freeradius-3.0.1 package in RHEL-7, there we need errata for:

RHEL-5 freeradius2
RHEL-6 freeradius
RHEL-7 freeradius

(In reply to John Dennis from comment #10)
> Re comment #8
> 
> "attacker is able to set password hash rather than password"
> 
> This is not a requirement to trigger the issue. The normify() function is
> also called on password value the server looks up in it's backend data
> store, not just on the password passed in the request. You correctly allude
> to this in the 2nd to last paragraph discussing LDAP. Thus receiving a
> password in a request with a long salt is one trigger, another trigger is
> storing a password with a long salt.

Ok, I see that part of my comment 8 was probably unclear.  It was meant to say that attacker who wants to trigger this needs to be able to set long password hash in the password store backend used by FreeRadius.  That implies that password store can feed untrusted / malicious data to FreeRadius server, either by allowing attacker to set such password has in trusted password store, or the whole data store being malicious and controlled by an attacker.

However, this is rather non-standard assumption.  When considering authentication service bypass or DoS issues, password data store would typically be considered a trusted input and issues triggered by malformed password data are more likely to be classified as bugs rather than security issues as they would not cross trust boundary.  For example sshd crash caused by malformed /etc/shadow would probably not be called security, as unprivileged local user can not modify the file to corrupt it.

My examples listing LDAP with users able to directly alter userPassword, or multi-realm configuration (which, however, does not seem typical radius multi-realm setup), were meant to provide examples of use cases where this issue can be considered security.

I do not believe this issue can be triggered by malicious data in a radius request sent to FreeRadius, but only by malicious data from the password store backend.  Please correct me if I'm overlooking some way to trigger this using only malicious password attribute in a request.

> Re comment #9
> 
> It also affects the freeradius-3.0.1 package in RHEL-7

Red Hat Enterprise Linux 7 Beta was released with FreeRadius 3.0.  This issue is planned to be corrected before the final release of Red Hat Enterprise Linux 7, and hence there will be no erratum for it.

Re comment #11

Yes, you are correct, this can only be triggered by data stored in the backend data store. My comment concerning normify being applied to the password in the request was incorrect and misleading.

I will note that putting values into the backend data store that can trigger this does not require malicious intent, just ignorance.

Statement:

This issue affects the versions of freeradius2 as shipped with Red Hat Enterprise Linux 5. Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Moderate security impact and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.

This issue did not affect the versions of freeradius as shipped with Red Hat Enterprise Linux 5 and 7.

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2015:1287 https://rhn.redhat.com/errata/RHSA-2015-1287.html