Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue,  3 Mar 2015 20:08:28 -0500 (EST)
Subject: Re: CVE request - Evergreen

Hash: SHA1


We have these initial questions, in part to determine whether there should
be a total of two CVE IDs or three CVE IDs. says:

> Both bugs had permitted remote unauthenticated access of confidential
> application configuration settings.

but says:

> Any user who can authenticate to Evergreen and make the proper
> open-ils.pcrud calls can view the history of any setting ... once
> anonymous pcrud goes in, no login would be required either.

Was there a released version of Evergreen in which an unauthenticated
attacker could view a setting's history by exploiting this bug? also says:

> An immediate fix for this would be to add a permission, just about any
> permission that a patron would not have ... The
> collab/dyrcona/lp1206589-quick-fix branch in the security repo adds a
> retrieve permission of STAFF_LOGIN ... That leaves us pretty much
> where the initial bug reports assumes we were with settings exposed
> only to unauthorized staff ... Since I have suggested removing the
> open-ils.pcrud controller, leaving cstore as the only mode of access
> to these settings, new API calls would need to be added to search and
> retrieve the settings history.


> Temporary Fix for Org. Unit Settings History Bug
>  1. It adds a retrieve permission of STAFF_LOGIN.  This at least
> requires someone with staff permission to be able to view settings
> history.

Does this mean that:

 - in version 2.7.3, there is a major vulnerability in which a
   setting's history can be viewed by any authenticated user,
   including users with the "patron" role

 - in version 2.7.4, there is a minor vulnerability in which a
   setting's history can be viewed by all persons with the staff role,
   which would include unauthorized staff in many realistic
   deployments. This might be fixed in a future release by forcing all
   access to use cstore, or by some other undetermined change.



This seems to be a much simpler case that was completely fixed by;a=commit;h=3a0f1cc7b2efa517ee4cd4c6a682237554fed307
and had allowed unauthenticated access. It will have only one CVE ID.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ