Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 21 Mar 2015 15:08:46 +0100
From: Pere Orga <>
Subject: Re: CVE requests for Drupal Core - Moderately Critical - Multiple
 Vulnerabilities - SA-CORE-2015-001

On Fri, Mar 20, 2015 at 1:45 AM,  <> wrote:
> Hash: SHA1
>> Access bypass (Password reset URLs - Drupal 6 and 7)
>> Password reset URLs can be forged under certain circumstances,
>> allowing an attacker to gain access to another user's account without
>> knowing the account's password.
> Based on the
> changes, we think that there is a single underlying issue in which the
> attack vector seems to be essentially expressed by:
>   $attack_reset_url = str_replace("user/reset/{$user1->id()}",
>                                   "user/reset/{$user2->id()}", $reset_url);
> regardless of the Drupal version -- i.e., 6.x, 7.x, or an unreleased
> 8.x version. (For purposes of determining the correct number of CVE
> IDs, it is probably not relevant that 6.x and 7.x have different ways
> in which problematic accounts may have been created.)
> Use CVE-2015-2559.


>> Open redirect (Several vectors including the "destination" URL
>> parameter - Drupal 6 and 7)
>> Under certain circumstances, malicious users can use the destination
>> URL parameter to construct a URL that will trick users into being
>> redirected to a 3rd party website, thereby exposing the users to
>> potential social engineering attacks.
> This one might be more complicated for CVE assignment. If a single
> change to a single piece of code addressed all of these open-redirect
> issues, then a single CVE ID may be possible. However, it appears that
> the situation might be a series of related problems that were found in
> different places (and possibly different versions) by different
> people. lists two external
> discoverers, as well as discoverers from the Drupal Security Team. As
> an example, suppose that there were three independent reports, and
> each report included three unique affected parameters: one of which
> existed only in 6.x, one of which existed only in 7.x, and one of
> which existed in both 6.x and 7.x. That would have 9 CVE IDs.

I see.

There is a vulnerabilty involving a unique query parameter called
'destination' (i.e.
In Drupal, this parameter may be accessed via
$_REQUEST['destination'], $_GET['destination'] or
drupal_get_destination() function. 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 and the
fix consisted in filtering it early in Drupal's bootstrap (see This helps preventing open
redirections in custom code and contributed modules too. That issue
was reported multiple times by different people.

The Drupal 6 fix also included filtering an additional parameter but
there was no evidence that some harm could be done with it (I'm not
asking a CVE for this)

Additionally, it was detected that Drupal 7 url_is_external() and
Drupal 6 menu_path_is_external() API functions could return FALSE for
some external URLs. I think these could deserve additional CVE IDs.

These issues were present in Drupal 8 too - the fix has already been
committed: - be
we currently don't request CVEs for unstable releases of Drupal.

Many thanks

Pere Orga on behalf of the Drupal Security Team

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.