Red Hat Bugzilla – Bug 967909
Server trusts user returned parameters such as userID that should be tied to server state
Last modified: 2013-07-11 01:52:37 EDT
Description of problem:
The server accepts the value of parameters such as userId from the client, when it should associate such information server-side (i.e. associate it with a session or similar mechanism).
Steps to Reproduce:
1. Make an update through a POST, but change the value of the userId
The userId value that is changed is reflected in the user field of the revision history.
Tampering with the userId or other identity/origin information should not be possible (i.e. userId is not passed by client), have no effect, or result in an error.
This bug is part of a trio of bugs featured in a proof-of-concept (POC) drive-by attack I've written. For the others, see: https://bugzilla.redhat.com/buglist.cgi?f1=cf_qa_whiteboard&o1=substring&query_format=advanced&v1=poc-fc5fd70a912b
To try out the POC, visit:
That page will generate a random nonce and attempt to add it to a PressGang topic. Open the PressGang link presented by the POC in another tab and scroll to the bottom of the XML source. You should see the nonce created in the POC has been successfully embedded in the form of a comment. Finally, examine the revisions tab and see that this revision has been associated with the user mcaspers and that the revision message also refers to the generated nonce.
In summary, arbitrary web-content can make changes to PressGang resources and associate those changes with any user. Since PressGang currently lacks authentication of any kind, there is no user or session protection to constrain the timing of these attacks to when users are "logged in". The VPN also offers no protection. Malicious users outside Red Hat may make changes to PressGang topics at will simply by having users browse malicious content while connected to the VPN.