Date: Thu, 26 Mar 2015 14:10:23 -0400 (EDT) From: cve-assign@...re.org To: pere@...a.cat Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE requests for Drupal Core - Moderately Critical - Multiple Vulnerabilities - SA-CORE-2015-001 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Open redirect (Several vectors including the "destination" URL >> parameter - Drupal 6 and 7) We feel that, for purposes of CVE, this is best represented as two distinct problems. First, "destination" is essentially a reserved keyword, and both Drupal 6 and 7 lacked pre-processing of the original input to eliminate unintended uses of this keyword. As mentioned on the https://www.drupal.org/node/2455007 page, 'Many areas of Drupal use a "destination" query string parameter for built-in redirect functionality.' Because "destination" was intended only for this "built-in" use, we feel that it is roughly like a Technology-Specific Special Element in the http://cwe.mitre.org/data/definitions/169.html sense. Use CVE-2015-2749. > That issue affected differently to > distinct Drupal versions; for example all confirmation forms in Drupal > 7 could be redirected to an external page via the 'destination' > parameter directly, but in Drupal 6 only if the code that builds the > confirmation form uses the parameter (and there are only a few). > The destination parameter was being trusted in multiple places We do not feel that this difference between 6 and 7 requires separate CVE IDs. Second, there were these separate changes: > http://cgit.drupalcode.org/drupal/commit/includes/menu.inc?h=6.x&id=8ffc5db3c0ab926f3d4b2cf8bc51714c8c0f3c93 > http://cgit.drupalcode.org/drupal/commit/includes/common.inc?h=7.x&id=b44056d2f8e8c71d35c85ec5c2fb8f7c8a02d8a8 Here, the underlying problem is lack of checks for the special "//" initial sequence, which is associated with an external resource. This is roughly like an Input Leader in the http://cwe.mitre.org/data/definitions/148.html sense. Because of the code reorganization between 6 and 7, the code changes are not identical but apparently the goal is to prevent only the "//" attack approach, not other attack approaches. Accordingly, it can be considered the same problem, and the same CVE ID is applicable to both 6 and 7. Use CVE-2015-2750. - -- 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) iQEcBAEBAgAGBQJVFErZAAoJEKllVAevmvms6JkIAKp/wlV9W6khCUN0xeEJUX/H cWm0kNap8NtA/cfan8oWgnSBpO2cTdB0ZLKEIKGqprJkNFb2Ng0o6mw7FO738tfZ 7vuogcNG9A57Ocz9x/0e8DBR8gy277QBN3YdoTidbhh/x0wJGNkeuE3M0FmFAf66 c4kzsmqJp7zmEkFE9dV44RqzALn0NIfMcjh1EmTjKc5HiyA9SbSUBcEiWK29S/cf FKtm/4rg1A/iJE6SjGuW0oSeIal+y7Ms404Db+7qrD2kDv52Jik6Rj/KmNcPfy+X vbU6YAJw9n0ntr1I9BBF+Fk4Q4AHBhwPEGyQ1rA5oTLwky3L5e9U1boPyhdfVKs= =8Nmg -----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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ