Org Unit Setting View Permissions Can Be Bypassed

Bug #1424755 reported by Jason Stephenson on 2015-02-23
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Some org unit settings contain non-public data.

These settings can be flagged with a view_perm in config.org_unit_setting_type.

The intention is to prevent reading the value of org unit settings of that type without proper permissions.

The view_perm appears to be properly taken into account by the implementation of

The implementation of is a wrapper around OpenILS::Application::AppUtils::ou_ancestor_setting, which does NOT enforce view_perm if no auth token is provided.

This means that unauthenticated users can use to read org unit settings which should require a valid auth token associated with a user with the permission specified in the view_perm for that org unit setting type.

CVE References

Jason Stephenson (jstephenson) wrote :

This is a serious security bug in Evergreen that allows unauthenticated users to retrieve sensitive information remotely. This information could include email addresses and/or account information for 3rd party products that integrate with Evergreen.

Evergreen is patched as of releases 2.5.9, 2.6.7, 2.7.4, and 2.8.0-beta. All prior releases are vulnerable to this remote exploit.

It is extremely important that if you cannot upgrade at this time that you patch your Evergreen to protect against this exploit. To that end, a patch is being supplied that you can apply to a running system. In order to secure your system, you must download this patch, copy it to each of your Evergreen servers, at least any that run services. You will need to perform the following steps on each server to completely patch your system.

First, you must find where the module is located. This is usually under /usr/local somewhere. The following command will find it for you:

find /usr/local -name

On an Ubuntu 12.04 system, the above prints out "/usr/local/share/perl/5.14.2/OpenILS/Application/" so we will use that as our example, just be sure that when you do this for real, you use the actual path printed by the above command. If it prints nothing, you will need to check other locations.

Once you have the path, you can run the patch command. Assuming that you are in the directory where you put the patch file, the following command should apply the patch:

sudo patch /usr/local/share/perl/5.14.2/OpenILS/Application/ lp1424755.patch

Unless you have made local edits to the affected file, the patch should apply cleanly.

After you have applied the patch, you will need to restart the services. You do this by running osrf_control with the appropriate options:

osrf_control [--localhost] --restart --service

The --localhost is in brackets because you may or may not need it. Your system administrator should know if you do or not. If you do need it, remove the brackets. If you don't need it, then omit the option entirely.

Jason Stephenson (jstephenson) wrote :

The patch described in comment #1.

Ben Shum (bshum) wrote :

Marking targets for security releases.

Changed in evergreen:
milestone: none → 2.8-beta
Galen Charlton (gmc) on 2015-03-03
information type: Private Security → Public Security
Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers