Follow @Openwall on Twitter for new release announcements and other news
[<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

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.