* Advisory ID: DRUPAL-SA-CORE-2014-003

[paul]

View online: ​https://www.drupal.org/SA-CORE-2014-003

• Advisory ID: DRUPAL-SA-CORE-2014-003
• Project: Drupal core [1]
• Version: 6.x, 7.x
• Date: 2014-July-16
• Security risk: Critical [2]
• Exploitable from: Remote
• Vulnerability: Multiple vulnerabilities

---

---

Multiple vulnerabilities were fixed in the supported Drupal core versions 6
and 7.

.... Denial of service with malicious HTTP Host header (Base system - Drupal
6 and 7 - Critical)

Drupal core's multisite feature dynamically determines which configuration
file to use based on the HTTP Host header.

The HTTP Host header validation does not sufficiently check
maliciously-crafted header values, thereby exposing a denial of service
vulnerability.

.... Access bypass (File module - Drupal 7 - Critical)

The File module included in Drupal 7 core allows attaching files to pieces of
content. The module doesn't sufficiently check permission to view the
attached file when attaching a file that was previously uploaded. This could
allow attackers to gain access to private files.

This vulnerability is mitigated by the fact that the attacker must have
permission to create or edit content with a file field.

Note: The Drupal 6 FileField? [3] module is affected by a similar issue (see
SA-CONTRIB-2014-071 - FileField? - Access bypass [4]) and requires an update
to the current security release of Drupal 6 core in order for the fix
released there to work correctly. However, Drupal 6 core itself is not
directly affected.

.... Cross-site scripting (Form API option groups - Drupal 6 and 7 -
Moderately critical)

A cross-site scripting vulnerability was found due to Drupal's form API
failing to sanitize option group labels in select elements. This
vulnerability affects Drupal 6 core directly, and likely affects Drupal 7
forms provided by contributed or custom modules.

This vulnerability is mitigated by the fact that it requires the "administer
taxonomy" permission to exploit in Drupal 6 core, and there is no known
exploit within Drupal 7 core itself.

.... Cross-site scripting (Ajax system - Drupal 7 - Moderately critical)

A reflected cross-site scripting vulnerability was found in certain forms
containing a combination of an Ajax-enabled textfield (for example, an
autocomplete field) and a file field.

This vulnerability is mitigated by the fact that an attacker can only trigger
the attack in a limited set of circumstances, usually requiring custom or
contributed modules.

---

---

• /A CVE identifier [5] will be requested, and added upon issuance, in

accordance with Drupal Security Team processes./

---

---

• Drupal core 6.x versions prior to 6.32.
• Drupal core 7.x versions prior to 7.29.

---

---

Install the latest version:

• If you use Drupal 6.x, upgrade to Drupal core 6.32. [6]
• If you use Drupal 7.x, upgrade to Drupal core 7.29. [7]

Also see the Drupal core [8] project page.

---

---

• The denial of service vulnerability using malicious HTTP Host headers was

reported by Régis Leroy [9].

• The access bypass vulnerability in the File module was reported by Ivan

Ch
[10].

• The cross-site scripting vulnerability with Form API option groups was

reported by Károly Négyesi [11].

• The cross-site scripting vulnerability in the Ajax system was reported by

mani22test [12].

---

---

• The denial of service vulnerability using malicious HTTP Host headers was

fixed by Régis Leroy [13], and by Klaus Purer [14] of the Drupal
Security
Team.

• The access bypass vulnerability in the File module was fixed by Nate Haug

[15] and Ivan Ch [16], and by Drupal Security Team members David
Rothstein
[17], Heine Deelstra [18] and David Snopek [19].

• The cross-site scripting vulnerability with Form API option groups was

fixed by Greg Knaddison [20] of the Drupal Security Team.

• The cross-site scripting vulnerability in the Ajax system was fixed by

Neil Drumm [21] of the Drupal Security Team.

---

---

• The Drupal Security Team [22]

---

---

The Drupal security team can be reached at security at drupal.org or via the
contact form at ​http://drupal.org/contact [23].

Learn more about the Drupal Security team and their policies [24], writing
secure code for Drupal [25], and securing your site [26].

Follow the Drupal Security Team on Twitter at
​https://twitter.com/drupalsecurity [27]

[1] ​http://drupal.org/project/drupal
[2] ​http://drupal.org/security-team/risk-levels
[3] ​https://www.drupal.org/project/filefield
[4] ​https://www.drupal.org/node/2304561
[5] ​http://cve.mitre.org/
[6] ​https://www.drupal.org/drupal-6.32-release-notes
[7] ​https://www.drupal.org/drupal-7.29-release-notes
[8] ​http://drupal.org/project/drupal
[9] ​https://www.drupal.org/user/1367862
[10] ​https://www.drupal.org/user/556138
[11] ​https://www.drupal.org/u/chx
[12] ​https://www.drupal.org/user/2844779
[13] ​https://www.drupal.org/user/1367862
[14] ​https://www.drupal.org/user/262198
[15] ​https://www.drupal.org/user/35821
[16] ​https://www.drupal.org/user/556138
[17] ​https://www.drupal.org/user/124982
[18] ​https://www.drupal.org/user/17943
[19] ​https://www.drupal.org/user/266527
[20] ​https://www.drupal.org/u/greggles
[21] ​https://www.drupal.org/u/drumm
[22] ​http://drupal.org/security-team
[23] ​http://drupal.org/contact
[24] ​http://drupal.org/security-team
[25] ​http://drupal.org/writing-secure-code
[26] ​http://drupal.org/security/secure-configuration
[27] ​https://twitter.com/drupalsecurity

_
Security-news mailing list
Security-news@…
Unsubscribe at ​https://lists.drupal.org/mailman/listinfo/security-news

[paul]

It's taking longer than usual to build a new stage platform and clone the most recent version of the stage site (made by me on my own platform)

I think I'll try again ..

Adding total time taken on this task so far ..

[paul]

I have cloned the stage site after a retry.

The platform had these problems previously:

Unable to download ​​http://drupal.org/files/issues/location.module_34.patch.
Could not download platform using drush make. No platform present

Building ..

[paul]

I tried to build the platform again but I still encounter the same problem.

The patch file loads fine in my browser.

The raw makfile from my github site also loads fine in my browser:
​https://raw.githubusercontent.com/paulbooker/transitionnetwork.org-d6.profile/master/transitionnetwork.org-d6.make

@Chris

Would you have a look into this?

@Ed ..

I'll pick this is up again later

[paul]

@Chris

I get the same problem when I try to build the platform makefile from a terminal. Any thoughts on why building a platform is not working?

Considering the alternatives ..

puffin:/data/disk/tn/static/transition-network-s6-32-booker# sudo -u tn drush make transitionnetwork.org-d6.make .
Project information for admin_menu retrieved. [ok]
Project information for content_profile retrieved. [ok]
...
location downloaded from ​http://ftp.drupal.org/files/projects/location-6.x-3.x-dev.tar.gz. [ok]
Unable to download ​​http://drupal.org/files/issues/location.module_34.patch. [error]
logintoboggan downloaded from ​http://ftp.drupal.org/files/projects/logintoboggan-6.x-1.x-dev.tar.gz. [ok]
...

jquery.cycle downloaded from ​http://malsup.github.com/jquery.cycle.all.js. [ok]
jquery.ui downloaded from ​http://jquery-ui.googlecode.com/files/jquery.ui-1.6.zip. [ok]
colorbox downloaded from ​http://drupal.org/files/colorbox-1.3.18.zip. [ok]
puffin:/data/disk/tn/static/transition-network-s6-32-booker#

[paul]

Still experiencing problems creating a platform & removing failed platform requests.

As soon as these are fixed I'll perform the security update.

[chris]

Cc's added -- people might not have seen this ticket (I hadn't):

​/trac/ticket/758

Replying to paul:

Any thoughts on why building a platform is not working?

Testing getting the file using lynx and wget, as root, on the server:

lynx -head -dump http://drupal.org/files/issues/location.module_34.patch | grep Location

  Location: https://www.drupal.org/files/issues/location.module_34.patch

wget https://www.drupal.org/files/issues/location.module_34.patch -O /tmp/location.module_34.patch
  
  2014-07-20 20:54:35 (5.88 MB/s) - `/tmp/location.module_34.patch' saved [575/575]

And the file:

Index: location.module^M
===================================================================^M
--- location.module     (revision 1047)^M
+++ location.module     (working copy)^M
@@ -280,7 +280,7 @@^M
     // If State/Province is using the select widget, update the element's options.
     if ($field == 'province' && $fsettings[$field]['widget'] == 'select') {
       // We are building the element for the first time
-      if (!isset($element['value']['country'])) {
+      if (!isset($element['#value']['country'])) { 
         $country = $fdefaults['country'];
       }
       else {

The only two things I noticed are:

1. The URL you used was a 301 -- try ​https://www.drupal.org/files/issues/location.module_34.patch ?

2. The files has a mixture of Windows and UNIX line endings, I guess this isn't an issue.

[chris]

Oops, didn't mean to assign this to jim.

[ed]

anything to do with the boa update on friday?

[jim]

FWIW I found in the past it's best to use HTTP:// for patches - drush make sometimes gets confused/disallows HTTPS patches for some reason. Not clear why or what the cause is, but there you go...

[paul]

Thanks. Looking in to this now ..

[chris]

Replying to jim:

FWIW I found in the past it's best to use HTTP:// for patches - drush make sometimes gets confused/disallows HTTPS patches for some reason. Not clear why or what the cause is, but there you go...

My guess, in this case, is that the resouces was available via http but is now only available via https and drush isn't following the Location header in the 301 response.

[paul]

Thanks for the suggestion Chris. I made the change to the makefile but it didn't fix the problem.

I think it may be some broader permission problem as I also couldn't delete my failed platforms. Not sure.

It looks as though Drupal no longer provides patches for security updates. Can anyone confirm? I was considering applying the security patch to the stage site and check that everything works correctly we could then decide whether to repeat on the live site.

I'll pick this up agin later ...

[annesley]

some thoughts on security policy (note that i am just opening a discussion, my opinion on these questions is not necessarily either to ignore or accept):
how important is XSS? it would allow a malicious hacker to send a URL to someone in an email that placed a "Donate to TN" button on the TN.org page after it has been served.
do we care about DOS attacks? what is the likelihood? will the IPchains / firewall prevent it anyway?
where is the FileField? used? are all the uploaded files public?

[paul]

Personally, I don't get in to the details of what's changed. If the security team advise to patch core, I think it's best to just patch core.

[ben]

It sounds like generally follow the same principal as paul on this. I feel
like if as a community (of drupal users) we keep up with the latest version
then the developers need only to check that their modules work with the
latest version. I don't feel the need to look at the details and decide on
each update. If an update breaks a module we're using then we give feedback
to that module's developer and it (hopefully) then gets fixed for us by
them, and in turn the rest of the community. Staying behind feels a bit
'selfish'.

But saying that I realise that keeping up to date is an expensive thing to
do. I think perhaps, if what we want to do is save money, that we should
decide on a update period.

Say we decide 6 months... We do critical updates as and when they come out
(cos somebody's thought about it, and have decided that it's critical), and
if a critical updates comes out we might find we need to update other
modules/core at the same time. Other updates (that don't appear to be
related to a critical module) then are left, and only updated when we reach
the end of that period (unless some work related to a module is being
undertaken - say I'm working on the theme it makes sense that I'm working
on the latest version of the code)...

that's my tuppence...




On 21 July 2014 13:24, Transiton Technology Trac <
trac@tech.transitionnetwork.org> wrote:

> #758: * Advisory ID: DRUPAL-SA-CORE-2014-003
> -------------------------------------+-------------------------------------
>            Reporter:  paul           |                      Owner:  paul
>                Type:  maintenance    |                     Status:
>            Priority:  major          |  assigned
>           Component:  Drupal         |                  Milestone:
>   modules & settings                 |                 Resolution:
>            Keywords:                 |  Estimated Number of Hours:  0.0
> Add Hours to Ticket:  0.125          |                  Billable?:  1
>         Total Hours:  2.35           |
> -------------------------------------+-------------------------------------
> Changes (by paul):
>
>  * hours:  0.0 => 0.125
>  * totalhours:  2.35 => 2.475
>
>
> Comment:
>
>  Personally, I don't get in to the details of what's changed. If the
>  security team advise to patch core, I think it's best to just patch core.
>
> --
> Ticket URL: <https://tech.transitionnetwork.org/trac/ticket/758#comment:14
> >
> Transition Technology <https://tech.transitionnetwork.org/trac>
> Support and issues tracking for the Transition Network Web Project.
>



-- 


-------------
emailme@benjarlett.co.uk
benjarlett.co.uk <http://www.benjarlett.co.uk>
07734 970739

[chris]

Replying to paul:

I think it may be some broader permission problem as I also couldn't delete my failed platforms. Not sure.

Want me to look at anything specific? Are you doing this as the tn.ftp user?

[paul]

Replying to chris:

Replying to paul:

I think it may be some broader permission problem as I also couldn't delete my failed platforms. Not sure.

Want me to look at anything specific? Are you doing this as the tn.ftp user?

I have mostly been trying to create a platform through the aegir interface as I know this has been working. Maybe try to reproduce the problem of creating a platform in aegir and seeing if you can figure out what changed.

[ben]

adding a little bit of time for my comment.

[chris]

Replying to paul:

Maybe try to reproduce the problem of creating a platform in aegir and seeing if you can figure out what changed.

I've not done that before so I don't know how long it would take me... is there any other option?

[paul]

I was concerned about long it might take me to figure it out. I was thinking that you would probably be quicker with your Aegir shell foo. No worries. I'll investigate tomorrow - I'm a spent force this evening :).

[chris]

Replying to ed:

anything to do with the boa update on friday?

It could be, I have just realised that after running barracuda up-stable I omitted to run octopus up-stable all, really sorry about that. There is now another BOA update availabe, I'll install it tonight and make sure I don't forget the second step, ticket:765.

[ed]

has this made a difference? paul?

[paul]

Ed, I'll try this afternoon.

[paul]

Sorry, I'll get to this shortly ..

[paul]

Update seems to be working fine on stage.

​https://booker-stage-20140717.transitionnetwork.org / Transition Network D6-32-S002 Booker
​https://booker-stage-20140717.transitionnetwork.org/admin/reports/dblog

I fixed the problem with building the platform by placing quotation marks around the patch url!

New production platform:
Transition Network D6-32-P001 Booker

I'll migrate the production site to the new platform, when I get clearance.

Thoughts:

Process is slow. Better would be to do something along the lines of git pull [stage] , test [stage], create a tag [stage], git pull [production] < 45 minutes

[paul]

Just a friendly reminder, that I'll need to clearance to update the production site. I'll carry out the update late at night.

[chris]

Replying to paul:

Just a friendly reminder, that I'll need to clearance to update the production site. I'll carry out the update late at night.

My understanding is that as you are the lead Drupal deployment / update person that it's your call and although we have been discussing stopping updating the site (ticket:764) we haven't reached a consensus or decision on that proposal, so I'd say go for it when ever is convenient and if you do it before midnight it'll come out of the July budget, however it's Ed that has the last shout and I might be wrong on these things. I think Ed is still on leave so perhaps send him a quick txt to confirm what you intend to do? Email me off list if you don't have his mobile number.

[paul]

Thanks Chris. If there are no objections forthcoming I'll update the website later this evening.

[sam]

I'd not contact Ed whilst he's on holiday unless it was really genuinely urgent.

I say go for it Paul.

Best

Sam

[paul]

Thanks Sam.

[paul]

Core updated. No problems to report.

[ed]

Good work. SO - was the update problems to do with the Octopus update Chris did? ie do we need to worry about you having those problems?

[paul]

Ed,

I think the problem was just that I didn't pick up on a potential formatting problem:

​https://github.com/transitionnetwork/transitionnetwork.org-d6.profile/commit/030f3563ae20ee48f0ff7c17e826c537d44e687b

Not sure what problem Chris fixed. It may have helped.

It seem that the update process is working fine (just a little slow) Next time I'll try to do build platforms / site migrations from the terminal to see if I can get things done any quicker.

Best, Paul

[paul]

Replying to paul:

Ed,

I think the problem was just that I didn't pick up on a potential formatting problem:

​https://github.com/transitionnetwork/transitionnetwork.org-d6.profile/commit/030f3563ae20ee48f0ff7c17e826c537d44e687b

Not sure what problem Chris fixed. It may have helped.

It seems that the update process is working fine (just a little slow) Next time I'll try to build platforms / site migrations from the terminal to see if I can get things done any quicker.

Best, Paul

[paul]

@Ed I think this ticket can be closed.