Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Feb 2014 13:26:01 -0500 (EST)
From: cve-assign@...re.org
To: mmcallis@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE requests: MediaWiki 1.22.3, 1.21.6 and 1.19.12 release

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Some of this seems straightforward and we will send CVE assignments a
little later. Our first question is about the UploadBase.php diff in:

   https://gerrit.wikimedia.org/r/#/q/7d923a6b53f7fbcb0cbc3a19797d741bf6f440eb,n,z

Our first thought is that it might be best to have separate CVEs for
"Disallow uploading non-whitelisted namespaces" and "disallow iframe
elements" because they are distinct types of problems. The first one
seems similar to what is discussed in:

   http://en.wikipedia.org/wiki/User:Aarchiba/SVG_sanitizer

The first CVE would, roughly, have a root cause of "does not recognize
that a trust relationship with a specific external site is reasonably
required for use of a namespace." The second CVE would, roughly, have
a root cause of "does not block IFRAME elements."

Does anyone have an opposing view: for example, that adding the
hardcoded $validNamespaces list can't be interpreted as a "normal"
vulnerability fix? Across all products, adding a list of off-site URLs
maintained by various third parties is rarely the essence of a
security patch.

(As a side issue, SVG_sanitizer allows
http://www.w3.org/XML/1998/namespace but the patched UploadBase.php
does not.)


Our second question is about
https://bugzilla.wikimedia.org/show_bug.cgi?id=61346 Comment 9. Do all
valid tokens have the same length, and thus an attacker (if he looked
at the source code) would already know that the wrong-length attempts
would always fail?

If not, a separate CVE would be needed on the basis of different
affected versions.

(This question is only about MediaWiki as shipped. If a system
administrator would need to modify the source code to use a different
length, and an attacker could detect that more easily because of
'strlen( $answer ) !== strlen( $test )' tests, that doesn't qualify
for a CVE.)

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJTENPlAAoJEKllVAevmvms/CIH/0TXSB+zHiFnVSQSyv1mqVGH
wObqMrao+532CKiqjgmQBezQEZhkCb2vNEeQoofx4CzTegQjvyL4wSIuPGx9JSa6
SkUoocGqHXOVCkk2ROwxZMTM22B6tUzogXKctyd66PgVYdmj9P4hXngueDVLszAs
Q2eLpHzyTK5GOEf0Vcrj26jGl7ouf9ROmSicuwEMVp0r5UCV3+puJtJzKnTz3shF
Dd7s94l2ebqskBsv7t/DOH2jRaXzxIBnn7046Ywtvv/fNFwodhv+MGaIsfSmj+gc
maKEy/vzdYjbJDLVvKSeBeuNuAGoI4nuna0krveG0+VpFZ4z3Mdt4SrlRjXsDNo=
=U5hr
-----END PGP SIGNATURE-----

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.