Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 29 Oct 2015 16:25:52 -0400 (EDT)
Subject: Re: CVE Request: MediaWiki 1.25.3, 1.24.4 and 1.23.11

Hash: SHA256

> * Wikipedia user RobinHood70 reported that the API failed to correctly stop
> adding new chunks to the upload when the reported size was exceeded,
> allowing a malicious users to upload add an infinite number of chunks for a
> single file upload.
> <>

> As long as the so-called final chunk exceeds the filesize rather than
> equalling it, the upload can continue. You can set filesize to 1000,
> upload 2000 bytes in a chunk, then continue uploading data for as long
> as you wish, as long as you continue to claim that the filesize is
> 1000 bytes.

Use CVE-2015-8001.

> * Wikipedia user RobinHood70 also reported that a malicious user could
> upload chunks of 1 byte for very large files, potentially creating a very
> large number of files on the server's filesystem.
> <>

> All but the final block should have a minimum chunk size.

Use CVE-2015-8002.

> * Internal review discovered that it is not possible to throttle file
> uploads.
> <>

> We don't rate limit uploading files. We should.

Use CVE-2015-8003. An important note here is that the MITRE CVE team
accepted this CVE request only because it came from the organization
that wrote the code. In the general case, adding completely new
functionality such as an upload rate limit is a security enhancement
and not eligible for a CVE ID.

> * Internal review discovered a missing authorization check when removing
> suppression from a revision. This allowed users with the 'viewsuppressed'
> user right but not the appropriate 'suppressrevision' user right to
> unsuppress revisions.
> <>

> Check all revisions for suppression, not just the first

Use CVE-2015-8004.

> * Richard Stanway from reported that thumbnails of PNG files
> generated with ImageMagick contained the local file path in the image
> metadata.
> <>

Use CVE-2015-8005.

This CVE ID is not about the default behavior of ImageMagick; it is
about MediaWiki's use of ImageMagick without a command-line option
that prevents pathname disclosure.

There is a separate issue that the machine might be using an old
*Magick program that lacks support for this command-line option (e.g.,
an old version of GraphicsMagick instead of ImageMagick). The MITRE
CVE team did not investigate how this interacts with the MediaWiki
installation process. If the MediaWiki installation process is aware
that only an old *Magick program is installed and would ignore the
command-line option, and none of these is in place:

  - the installation process aborts with an error
  - the "image scaler" functionality is disabled
  - the user is warned that this is an undesirable configuration
  - installation-requirements documentation exists stating that the old
    *Magick program is unsupported

then this is a separate vulnerability that should have its own CVE ID.

Finally, T108616 also mentions "this amount of metadata makes up a
large part of the file size on smaller images, which can waste of
bandwidth." There is no CVE ID for any related DoS attack, e.g.,
abnormally long pathnames or other excessive metadata.

> * Extension:PageTriage - MediaWiki user Grunny discovered a DOM-based XSS in
> the way the extension handled page titles.
> <>

Use CVE-2015-8006.

The CVE ID is only about what was fixed in 1.23.11/1.24.4/1.25.3. It
is not about any other issues that might remain, associated with the "That part of the
PageTriage code is a nightmare, it's very hard to audit for security.
Everything is raw HTML several levels up every imaginable call stack."

> * Extension:Echo - Internal review discovered that Echo could display
> deleted
> or suppressed usernames when the username was previously used to Thank
> users.
> <>

> "GoodUser" looks at their notifications and sees "AbusiveUsername"
> everywhere instead of "username removed"

Use CVE-2015-8007.

> * Extension:OAuth - Wikipedia user Sitic discovered that the OAuth
> extension did not correctly enforce the IP restrictions of a Consumer when
> using previously negotiated credentials.
> <>

> These IP restrictions only seem to work when negotiating a new client
> token over Special:OAuth/initiate. When I locally make an API request
> with an already existing client/access token I get a valid response
> and no error.

Use CVE-2015-8008.

> * Extension:OAuth - Wikipedia user Sitic discovered that OAuth would accept
> a valid signature from any Consumer when checking the authorization
> signature. This allowed a registered Consumer who gained access to another
> Consumer's users' access tokens and secrets to use those credentials.
> <>

> I think there is a check missing in MWOAuthDataStore::lookup_token().
> For access tokens, we lookup the consumer by the access token, and
> don't confirm that the id's match.
> This requires that you have the access token for a different
> consumer's users, which should be a rare occurrence.

Use CVE-2015-8009.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1


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.