Bug 5844 - drupal possible security issues CVE-2012-1588, CVE-2012-1589, CVE-2012-1590, CVE-2012-1591, CVE-2012-2153, and CVE-2012-2922 [mga1]
Summary: drupal possible security issues CVE-2012-1588, CVE-2012-1589, CVE-2012-1590, ...
Status: RESOLVED WONTFIX
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 1
Hardware: All Linux
Priority: Normal critical
Target Milestone: ---
Assignee: Funda Wang
QA Contact:
URL: http://lwn.net/Vulnerabilities/500133/
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-11 03:17 CEST by David Walser
Modified: 2012-12-02 14:31 CET (History)
8 users (show)

See Also:
Source RPM: drupal-7.0-1.mga1.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2012-05-11 03:17:10 CEST
These issues were fixed in drupal 7.14 (uploaded in Cauldron by Funda Wang).

It's not 100% certain, but likely that 7.0 is affected.
David Walser 2012-05-11 03:18:20 CEST

CC: (none) => oliver.bgr

Comment 1 David Walser 2012-05-28 00:15:12 CEST
Looks like the 7.14 wasn't really uploaded in Cauldron when I reported this.

Funda has uploaded 7.14 to updates_testing for Mageia 2.

Funda, can you look into this for Mageia 1 and build an update if needed?

CC: (none) => fundawang

Comment 2 David Walser 2012-05-28 00:24:39 CEST
Funda, if you find an update for Mageia 1 is needed, can you please say which CVEs are relevant?

Also, Funda, do you have any references for these CVEs for the advisory?

Speaking of which, uploaded so far are:
drupal-7.14-1.mga2
drupal-mysql-7.14-1.mga2
drupal-postgresql-7.14-1.mga2
drupal-sqlite-7.14-1.mga2

from drupal-7.14-1.mga2.src.rpm
Comment 3 David Walser 2012-05-28 01:07:24 CEST
Funda has build an update of drupal 7.14 for Mageia 1 as well:
drupal-7.14-1.mga1
drupal-mysql-7.14-1.mga1
drupal-mysqli-7.14-1.mga1
drupal-postgresql-7.14-1.mga1
drupal-sqlite-7.14-1.mga1

from drupal-7.14-1.mga1.src.rpm

We can assign to QA once we have an advisory.
Comment 4 David Walser 2012-06-04 21:45:04 CEST
There is an additional vulnerability that also affects version 7.14, CVE-2012-2922, so we need another update.

Fedora has issued an advisory for this on May 26:
http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081721.html

URL: (none) => http://lwn.net/Vulnerabilities/500133/
Summary: drupal possible security issues CVE-2012-1588, CVE-2012-1589, CVE-2012-1590, CVE-2012-1591, CVE-2012-2153 => drupal possible security issues CVE-2012-1588, CVE-2012-1589, CVE-2012-1590, CVE-2012-1591, CVE-2012-2153, and CVE-2012-2922

David Walser 2012-06-14 20:44:21 CEST

Version: 1 => Cauldron
Whiteboard: (none) => MGA2TOO, MGA1TOO

Oliver Burger 2012-06-15 15:16:26 CEST

Assignee: bugsquad => oliver.bgr

Comment 5 Oliver Burger 2012-06-15 15:42:57 CEST
Fixed in Cauldron
Comment 6 David Walser 2012-06-15 15:52:51 CEST
(In reply to comment #5)
> Fixed in Cauldron

Thanks.  I'll adjust the version assignments on the bug.

Version: Cauldron => 2
Whiteboard: MGA2TOO, MGA1TOO => MGA1TOO

Comment 7 Oliver Burger 2012-06-15 16:03:39 CEST
Fixed in 1 and 2:

Advisory:
=========
This updates fixes a vulnerability, that was reported at Fedora:
http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081721.html

The request_path function in includes/bootstrap.inc in Drupal 7.14 and
earlier allows remote attackers to obtain sensitive information via
the q[] parameter to index.php, which reveals the installation path in
an error message.

See http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2922
=========


Affected packages:
drupal-7.14-1.1.mga1.noarch.rpm
drupal-mysql-7.14-1.1.mga1.noarch.rpm
drupal-mysqli-7.14-1.1.mga1.noarch.rpm
drupal-postgresql-7.14-1.1.mga1.noarch.rpm
drupal-sqlite-7.14-1.1.mga1.noarch.rpm

from drupal-7.14-1.1.mga1.src.rpm


drupal-7.14-1.1.mga2.noarch.rpm
drupal-mysql-7.14-1.1.mga2.noarch.rpm
drupal-postgresql-7.14-1.1.mga2.noarch.rpm
drupal-sqlite-7.14-1.1.mga2.noarch.rpm

from drupal-7.14-1.1.mga2.src.rpm

Assignee: oliver.bgr => qa-bugs

Comment 8 David Walser 2012-06-15 16:11:41 CEST
Thanks Oliver.

CVE-2012-1588, CVE-2012-1589, CVE-2012-1590, CVE-2012-1591, CVE-2012-2153 were also fixed by Drupal 5.14, so they should be included in the advisory if they apply to the version of Drupal we are replacing.
Comment 9 David Walser 2012-06-15 21:04:57 CEST
OK, I dug up the info on the other CVEs.  They do all apply to Mageia 1 and 2.

Advisory:
========================

Updated drupal packages fix security vulnerabilities:

Drupal core's text filtering system provides several features
including removing inappropriate HTML tags and automatically linking
content that appears to be a link. A pattern in Drupal's text
matching was found to be inefficient with certain specially crafted
strings. This vulnerability is mitigated by the fact that users must
have the ability to post content sent to the filter system such as a
role with the "post comments" or "Forum topic: Create new content"
permission (CVE-2012-1588).

Drupal core's Form API allows users to set a destination, but failed
to validate that the URL was internal to the site. This weakness
could be abused to redirect the login to a remote site with a
malicious script that harvests the login credentials and redirects to
the live site. This vulnerability is mitigated only by the end user's
ability to recognize a URL with malicious query parameters to avoid
the social engineering required to exploit the problem (CVE-2012-1589).

Drupal core's forum lists fail to check user access to nodes when
displaying them in the forum overview page. If an unpublished node was
the most recently updated in a forum then users who should not have
access to unpublished forum posts were still be able to see meta-data
about the forum post such as the post title (CVE-2012-1590).

Drupal core provides the ability to have private files, including
images, and Image Styles which create derivative images from an
original image that may differ, for example, in size or saturation.
Drupal core failed to properly terminate the page request for cached
image styles allowing users to access image derivatives for images
they should not be able to view. Furthermore, Drupal didn't set the
right headers to prevent image styles from being cached in the
browser (CVE-2012-1591).

Drupal core provides the ability to list nodes on a site at
admin/content. Drupal core failed to confirm a user viewing that page
had access to each node in the list. This vulnerability only concerns
sites running a contributed node access module and is mitigated by the
fact that users must have a role with the "Access the content overview
page" permission. Unpublished nodes were not displayed to users who
only had the "Access the content overview page" permission
(CVE-2012-2153).

The request_path function in includes/bootstrap.inc in Drupal 7.14 and
earlier allows remote attackers to obtain sensitive information via
the q[] parameter to index.php, which reveals the installation path in
an error message (CVE-2012-2922).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1588
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1589
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1590
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1591
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2153
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2922
http://drupal.org/node/1557938
http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081721.html
========================

Updated packages in core/updates_testing:
========================
drupal-7.14-1.1.mga1
drupal-mysql-7.14-1.1.mga1
drupal-mysqli-7.14-1.1.mga1
drupal-postgresql-7.14-1.1.mga1
drupal-sqlite-7.14-1.1.mga1
drupal-7.14-1.1.mga2
drupal-mysql-7.14-1.1.mga2
drupal-postgresql-7.14-1.1.mga2
drupal-sqlite-7.14-1.1.mga2

from SRPMS:
drupal-7.14-1.1.mga1.src.rpm
drupal-7.14-1.1.mga2.src.rpm
Comment 10 claire robinson 2012-06-22 17:50:26 CEST
Testing x86_64 Mageia 2

A few issues..

The README.urpmi gives incorrect instructions for installation.

Step 1) The directory to find the INSTALL.*.txt files in in /usr/share/doc/drupal7/ where they are actually in /usr/share/doc/drupal/

Step 2) It says to copy a file from and to /etc/drupal7/sites/default/ which should be /etc/drupal/sites/default/

After completing these two steps, drupal is not accessible from anything other than localhost. It remains that way after the setup is completed.


In the file /etc/httpd/conf/webapps.d/drupal.conf it is set to block the outside world but there is no mention of this.

Alias /drupal /usr/share/drupal

<Directory /usr/share/drupal/>
       Options -Indexes +FollowSymlinks +Multiviews
       AllowOverride None
       Order deny,allow
       Deny from all
       Allow from 127.0.0.1
Comment 11 claire robinson 2012-06-22 17:55:18 CEST
Other than the problems in comment 10, created articles and pages and added a picture and all appears OK.
Comment 12 claire robinson 2012-06-22 18:59:38 CEST
Testing Mageia 1 x86_64

There is no README.urpmi at all in mga1

# ls /usr/share/doc/drupal/
CHANGELOG.txt      INSTALL.pgsql.txt   LICENSE.txt      robots.txt
COPYRIGHT.txt      INSTALL.sqlite.txt  MAINTAINERS.txt  UPGRADE.txt
INSTALL.mysql.txt  INSTALL.txt         README.txt

I'll install pgsql and check if the outside world exists for this one :)
Comment 13 claire robinson 2012-06-23 16:24:47 CEST
Mageia 1 x86_64 has problems.

Installed pgsql, there is no README.urpmi but followed INSTALL.pgsql.txt

It doesn't explain that you need to su postgres before using the createuser or createdb commands. The createdb command fails without -T template0 due to the UTF8 encoding.

With this completed and after renaming /var/www/drupal/sites/default/default.settings.php to settings.php, browsing either locally to localhost/drupal or remotely to host/drupal gives..

Bad Request

Your browser sent a request that this server could not understand.

Additionally, a 400 Bad Request error was encountered while trying to use an ErrorDocument to handle the request.

This is a regression.

I think these packages still need some attention so assigning back to Oliver, sorry.

Please reassign QA when you've had a chance to look.

Thanks.

CC: (none) => qa-bugs
Hardware: i586 => All
Assignee: qa-bugs => oliver.bgr

Comment 14 Oliver Burger 2012-07-03 15:01:24 CEST
README.urpmi fixed for 2.
Comment 15 Samuel Verschelde 2012-08-26 17:36:06 CEST
What's the status of this update? Is ready to handle back to QA already?

latest SRPMs:
drupal-7.14-1.1.mga1.src.rpm
drupal-7.14-1.2.mga2.src.rpm
Manuel Hiebel 2012-09-25 23:21:48 CEST

Whiteboard: MGA1TOO => MGA1TOO feedback

David Walser 2012-10-10 00:44:49 CEST

CC: (none) => oe

Comment 16 David Walser 2012-10-15 13:42:03 CEST
Funda has pushed a new build to Mageia 1 updates_testing, so it's now:
drupal-7.14-1.2.mga1.src.rpm

Is this ready to go?
Comment 17 Funda Wang 2012-10-19 14:56:55 CEST
I've updated drupal to 7.16 so that drupal SA-CORE-2012-003 is fixed. Now we have:

drupal-7.16-1.mga1
drupal-7.16-1.mga2
Comment 18 David Walser 2012-10-19 15:54:56 CEST
Assigning back to QA.  Upstream rates these new issues as "highly critical."  The previous set of issues fixed by the 7.14 packages are rated "critical."  Hopefully we can get this pushed.

Advisory:
========================

Updated drupal packages fix security vulnerabilities:

Drupal core's text filtering system provides several features
including removing inappropriate HTML tags and automatically linking
content that appears to be a link. A pattern in Drupal's text
matching was found to be inefficient with certain specially crafted
strings. This vulnerability is mitigated by the fact that users must
have the ability to post content sent to the filter system such as a
role with the "post comments" or "Forum topic: Create new content"
permission (CVE-2012-1588).

Drupal core's Form API allows users to set a destination, but failed
to validate that the URL was internal to the site. This weakness
could be abused to redirect the login to a remote site with a
malicious script that harvests the login credentials and redirects to
the live site. This vulnerability is mitigated only by the end user's
ability to recognize a URL with malicious query parameters to avoid
the social engineering required to exploit the problem (CVE-2012-1589).

Drupal core's forum lists fail to check user access to nodes when
displaying them in the forum overview page. If an unpublished node was
the most recently updated in a forum then users who should not have
access to unpublished forum posts were still be able to see meta-data
about the forum post such as the post title (CVE-2012-1590).

Drupal core provides the ability to have private files, including
images, and Image Styles which create derivative images from an
original image that may differ, for example, in size or saturation.
Drupal core failed to properly terminate the page request for cached
image styles allowing users to access image derivatives for images
they should not be able to view. Furthermore, Drupal didn't set the
right headers to prevent image styles from being cached in the
browser (CVE-2012-1591).

Drupal core provides the ability to list nodes on a site at
admin/content. Drupal core failed to confirm a user viewing that page
had access to each node in the list. This vulnerability only concerns
sites running a contributed node access module and is mitigated by the
fact that users must have a role with the "Access the content overview
page" permission. Unpublished nodes were not displayed to users who
only had the "Access the content overview page" permission
(CVE-2012-2153).

The request_path function in includes/bootstrap.inc in Drupal 7.14 and
earlier allows remote attackers to obtain sensitive information via
the q[] parameter to index.php, which reveals the installation path in
an error message (CVE-2012-2922).

A bug in the installer code was identified that allows an attacker to
re-install Drupal using an external database server under certain
transient conditions. This could allow the attacker to execute
arbitrary PHP code on the original server (Drupal SA-CORE-2012-003).

For sites using the core OpenID module, an information disclosure
vulnerability was identified that allows an attacker to read files on
the local filesystem by attempting to log in to the site using a
malicious OpenID server (Drupal SA-CORE-2012-003).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1588
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1589
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1590
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1591
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2153
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2922
http://drupal.org/node/1557938
http://drupal.org/node/1815912
http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081721.html
========================

Updated packages in core/updates_testing:
========================
drupal-7.16-1.mga1
drupal-mysql-7.16-1.mga1
drupal-mysqli-7.16-1.mga1
drupal-postgresql-7.16-1.mga1
drupal-sqlite-7.16-1.mga1
drupal-7.16-1.mga2
drupal-mysql-7.16-1.mga2
drupal-postgresql-7.16-1.mga2
drupal-sqlite-7.16-1.mga2

from SRPMS:
drupal-7.16-1.mga1.src.rpm
drupal-7.16-1.mga2.src.rpm

Assignee: oliver.bgr => qa-bugs
Whiteboard: MGA1TOO feedback => MGA1TOO
Severity: normal => critical

Comment 19 Marc Lattemann 2012-10-20 22:03:24 CEST
tested for mga2 (x86_64) for mysql, sqlite and postgresql database. Everything seems to works fine after update. 
Only INSTALL.pgsql.txt has the same issues than explained by Claire in Comment 13:
It doesn't explain that you need to su postgres before using the createuser or
createdb commands. The createdb command fails without -T template0 due to the
UTF8 encoding.
Also it is not accessible from outside of localhost as stated in comment 10.

Does this needs to be changed, or is it OK? (all other mentioned issues from these comments seem to be fixed).

CC: (none) => marc.lattemann

Comment 20 Dave Hodgins 2012-10-23 01:55:25 CEST
Has the drupal-mysqli package intentionally been dropped, or is there a build
or mirror problem?

It isn't in ftp://mageia.webconquest.com/distrib/1/i586/media/core/updates_testing/ although the other drupal packages are there.

CC: (none) => davidwhodgins

Comment 21 Funda Wang 2012-10-23 03:40:22 CEST
(In reply to comment #20)
> Has the drupal-mysqli package intentionally been dropped, or is there a build
> or mirror problem?
No, it is wanted. There is another packaging bug in drupal for mga1.

Since 7.0, drupal started to use php-pdo as its database abstraction layer. That means, drupal no long accesses the database server via php-mysql nor php-mysqli, it needs php-pdo_mysql.

So the package in drupal for mga1 is wrongly packaged in the past.
Comment 22 Dave Hodgins 2012-10-24 01:56:59 CEST
Testing complete on Mageia 2 i586 and x86-64.

Used mysql on one, postgresql on the other.

For Mageia 1, right now, installing drupal using the defaults fails, as it
is defaulting to the older mysqli package, which can't be installed with
the newer drupal.

I think the update needs to obsolete the older packages so that it will
install cleanly.

Whiteboard: MGA1TOO => MGA1TOO MGA2-32-OK MGA2-64-OK

Comment 23 claire robinson 2012-10-24 12:33:06 CEST
Funda, could you look into this please. (comment 22)

We can't push mga2 separately as a new mga1 version would have a higher version than the current mga2.

Whiteboard: MGA1TOO MGA2-32-OK MGA2-64-OK => MGA1TOO MGA2-32-OK MGA2-64-OK feedback

Comment 24 Funda Wang 2012-10-24 16:35:50 CEST
Could somebody remove drupal-7.16-1.mga1 from core/updates_testing? So that updated packages could be pushed.

Thanks.
Comment 25 David Walser 2012-10-24 17:07:40 CEST
It can only be removed by the sysadmins.  I just asked on IRC.

CC: (none) => sysadmin-bugs

Comment 26 David Walser 2012-10-27 21:40:07 CEST
Funda, Thomas Backlund tells me has just deleted drupal in Mageia 1 updates_testing, so it's free to fix and resubmit now.
Comment 27 David Walser 2012-10-28 01:05:18 CEST
drupal-7.16-1.mga1 has been fixed and reuploaded by Funda.  Thanks Funda.

Whiteboard: MGA1TOO MGA2-32-OK MGA2-64-OK feedback => MGA1TOO MGA2-32-OK MGA2-64-OK

Comment 28 Dave Hodgins 2012-10-29 01:41:38 CET
Installing the update for drupal stops php applications such as phpmyadmin
from working.  They return a 400 http status code to the web browser.

Keeping the /etc/httpd/conf/webapps.d/drupal.conf file from the release
version of drupal, allows phpmyadmin to work again.

This is on a Mageia 1 i586 installation.

Whiteboard: MGA1TOO MGA2-32-OK MGA2-64-OK => MGA1TOO MGA2-32-OK MGA2-64-OK feedback

Comment 29 Funda Wang 2012-10-29 02:14:33 CET
According to comment#28, I'm backporting the drupal package from mga2 to mga1. So, please kill again drupal in core/updates_testing for mga1. So that updated package could be uploaded.
Comment 30 Thomas Backlund 2012-10-29 02:18:18 CET
drupal in mga1 core/updates_testing dropped

CC: (none) => tmb

Comment 31 David Walser 2012-10-29 02:34:57 CET
drupal-7.16-0.1.mga1 submitted by Funda.

Updating the advisory for the changed release tag.

Advisory:
========================

Updated drupal packages fix security vulnerabilities:

Drupal core's text filtering system provides several features
including removing inappropriate HTML tags and automatically linking
content that appears to be a link. A pattern in Drupal's text
matching was found to be inefficient with certain specially crafted
strings. This vulnerability is mitigated by the fact that users must
have the ability to post content sent to the filter system such as a
role with the "post comments" or "Forum topic: Create new content"
permission (CVE-2012-1588).

Drupal core's Form API allows users to set a destination, but failed
to validate that the URL was internal to the site. This weakness
could be abused to redirect the login to a remote site with a
malicious script that harvests the login credentials and redirects to
the live site. This vulnerability is mitigated only by the end user's
ability to recognize a URL with malicious query parameters to avoid
the social engineering required to exploit the problem (CVE-2012-1589).

Drupal core's forum lists fail to check user access to nodes when
displaying them in the forum overview page. If an unpublished node was
the most recently updated in a forum then users who should not have
access to unpublished forum posts were still be able to see meta-data
about the forum post such as the post title (CVE-2012-1590).

Drupal core provides the ability to have private files, including
images, and Image Styles which create derivative images from an
original image that may differ, for example, in size or saturation.
Drupal core failed to properly terminate the page request for cached
image styles allowing users to access image derivatives for images
they should not be able to view. Furthermore, Drupal didn't set the
right headers to prevent image styles from being cached in the
browser (CVE-2012-1591).

Drupal core provides the ability to list nodes on a site at
admin/content. Drupal core failed to confirm a user viewing that page
had access to each node in the list. This vulnerability only concerns
sites running a contributed node access module and is mitigated by the
fact that users must have a role with the "Access the content overview
page" permission. Unpublished nodes were not displayed to users who
only had the "Access the content overview page" permission
(CVE-2012-2153).

The request_path function in includes/bootstrap.inc in Drupal 7.14 and
earlier allows remote attackers to obtain sensitive information via
the q[] parameter to index.php, which reveals the installation path in
an error message (CVE-2012-2922).

A bug in the installer code was identified that allows an attacker to
re-install Drupal using an external database server under certain
transient conditions. This could allow the attacker to execute
arbitrary PHP code on the original server (Drupal SA-CORE-2012-003).

For sites using the core OpenID module, an information disclosure
vulnerability was identified that allows an attacker to read files on
the local filesystem by attempting to log in to the site using a
malicious OpenID server (Drupal SA-CORE-2012-003).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1588
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1589
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1590
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1591
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2153
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2922
http://drupal.org/node/1557938
http://drupal.org/node/1815912
http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081721.html
========================

Updated packages in core/updates_testing:
========================
drupal-7.16-0.1.mga1
drupal-mysql-7.16-0.1.mga1
drupal-postgresql-7.16-0.1.mga1
drupal-sqlite-7.16-0.1.mga1
drupal-7.16-1.mga2
drupal-mysql-7.16-1.mga2
drupal-postgresql-7.16-1.mga2
drupal-sqlite-7.16-1.mga2

from SRPMS:
drupal-7.16-1.mga1.src.rpm
drupal-7.16-1.mga2.src.rpm

Whiteboard: MGA1TOO MGA2-32-OK MGA2-64-OK feedback => MGA1TOO MGA2-32-OK MGA2-64-OK

Comment 32 David Walser 2012-10-29 02:35:29 CET
Oops, missed the SRPM.

Advisory:
========================

Updated drupal packages fix security vulnerabilities:

Drupal core's text filtering system provides several features
including removing inappropriate HTML tags and automatically linking
content that appears to be a link. A pattern in Drupal's text
matching was found to be inefficient with certain specially crafted
strings. This vulnerability is mitigated by the fact that users must
have the ability to post content sent to the filter system such as a
role with the "post comments" or "Forum topic: Create new content"
permission (CVE-2012-1588).

Drupal core's Form API allows users to set a destination, but failed
to validate that the URL was internal to the site. This weakness
could be abused to redirect the login to a remote site with a
malicious script that harvests the login credentials and redirects to
the live site. This vulnerability is mitigated only by the end user's
ability to recognize a URL with malicious query parameters to avoid
the social engineering required to exploit the problem (CVE-2012-1589).

Drupal core's forum lists fail to check user access to nodes when
displaying them in the forum overview page. If an unpublished node was
the most recently updated in a forum then users who should not have
access to unpublished forum posts were still be able to see meta-data
about the forum post such as the post title (CVE-2012-1590).

Drupal core provides the ability to have private files, including
images, and Image Styles which create derivative images from an
original image that may differ, for example, in size or saturation.
Drupal core failed to properly terminate the page request for cached
image styles allowing users to access image derivatives for images
they should not be able to view. Furthermore, Drupal didn't set the
right headers to prevent image styles from being cached in the
browser (CVE-2012-1591).

Drupal core provides the ability to list nodes on a site at
admin/content. Drupal core failed to confirm a user viewing that page
had access to each node in the list. This vulnerability only concerns
sites running a contributed node access module and is mitigated by the
fact that users must have a role with the "Access the content overview
page" permission. Unpublished nodes were not displayed to users who
only had the "Access the content overview page" permission
(CVE-2012-2153).

The request_path function in includes/bootstrap.inc in Drupal 7.14 and
earlier allows remote attackers to obtain sensitive information via
the q[] parameter to index.php, which reveals the installation path in
an error message (CVE-2012-2922).

A bug in the installer code was identified that allows an attacker to
re-install Drupal using an external database server under certain
transient conditions. This could allow the attacker to execute
arbitrary PHP code on the original server (Drupal SA-CORE-2012-003).

For sites using the core OpenID module, an information disclosure
vulnerability was identified that allows an attacker to read files on
the local filesystem by attempting to log in to the site using a
malicious OpenID server (Drupal SA-CORE-2012-003).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1588
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1589
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1590
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1591
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2153
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2922
http://drupal.org/node/1557938
http://drupal.org/node/1815912
http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081721.html
========================

Updated packages in core/updates_testing:
========================
drupal-7.16-0.1.mga1
drupal-mysql-7.16-0.1.mga1
drupal-postgresql-7.16-0.1.mga1
drupal-sqlite-7.16-0.1.mga1
drupal-7.16-1.mga2
drupal-mysql-7.16-1.mga2
drupal-postgresql-7.16-1.mga2
drupal-sqlite-7.16-1.mga2

from SRPMS:
drupal-7.16-0.1.mga1.src.rpm
drupal-7.16-1.mga2.src.rpm
Comment 33 claire robinson 2012-10-29 13:33:36 CET
Testing mga1 32
Comment 34 claire robinson 2012-10-29 14:08:40 CET
Installed release version with drupal-mysqli. Manually installed php-pdo_mysql then created a db and performed the web based installation. Added an article with an image uploaded.

The update installed drupal and drupal-mysql. Doing so restricted http://host/drupal to only being accessible from localhost and also clobbered the existing installation, returning to the start of the initial web based setup. The database is still there though.

I'll install with drupal-mysql instead and see if the 'i' makes a difference.
Comment 35 claire robinson 2012-10-29 14:56:28 CET
Further testing shows that if the web based installation is followed using the same database details it completes and enables you to view the site. I notice in the readme.urpmi it does mention restricting access to localhost. There are problems though.


The article I previously created, with an image, shows some errors and the image is now missing..

    Notice: Undefined index: width in theme_image_style() (line 1256 of /usr/share/drupal/modules/image/image.module).
    Notice: Undefined index: height in theme_image_style() (line 1257 of /usr/share/drupal/modules/image/image.module).


Logging in and editing the article shows it still has a link to the image and a size in kb but when clicking on the link a small window opens at http://localhost/drupal/sites/default/files/field/image/120thCenturyFox.jpg saying that it can't now be found..

'The requested URL "/drupal/sites/default/files/field/image/120thCenturyFox.jpg" was not found on this server.'

# ll /var/www/drupal/sites/default/files/field/image/120thCenturyFox.jpg 
-rw-rw-r-- 1 apache apache 25148 Oct 29 13:16 /var/www/drupal/sites/default/files/field/image/120thCenturyFox.jpg


I guess this is due to ..

Alias /drupal /usr/share/drupal

in /etc/httpd/conf/webapps.d/drupal.conf
claire robinson 2012-10-29 15:03:37 CET

Whiteboard: MGA1TOO MGA2-32-OK MGA2-64-OK => MGA1TOO MGA2-32-OK MGA2-64-OK feedback

Comment 36 David Walser 2012-10-29 15:16:36 CET
If the application code is going to be stored under /usr/share, that's one thing (although I don't really understand why we're starting to move a bunch of webapps there in Cauldron), but if it is going to save uploaded content and additional variable data, that needs to be under /var somewhere still and not in /usr.  We need to be careful of this with web packages in general.

CC: (none) => guillomovitch

Comment 37 claire robinson 2012-10-29 15:24:14 CET
mga2 is not affected by this so could now be pushed separately if you need more time to look into this.
Comment 38 David Walser 2012-10-29 18:58:02 CET
Fedora has issued an advisory for the newer issue on October 18:
http://lists.fedoraproject.org/pipermail/package-announce/2012-October/090861.html

from http://lwn.net/Vulnerabilities/521931/
Comment 39 claire robinson 2012-11-01 14:25:24 CET
Bug 7944 created for mga2 update which is waiting to be pushed.

Please use this bug now for Mga1 only.

Version: 2 => 1
Summary: drupal possible security issues CVE-2012-1588, CVE-2012-1589, CVE-2012-1590, CVE-2012-1591, CVE-2012-2153, and CVE-2012-2922 => drupal possible security issues CVE-2012-1588, CVE-2012-1589, CVE-2012-1590, CVE-2012-1591, CVE-2012-2153, and CVE-2012-2922 [mga1]
Whiteboard: MGA1TOO MGA2-32-OK MGA2-64-OK feedback => feedback

Comment 40 claire robinson 2012-11-06 19:27:22 CET
Assigning Fundu. Please eassign to QA when you've had a chance to look at this.

Thanks!

Assignee: qa-bugs => fundawang
Whiteboard: feedback => (none)

Comment 41 Funda Wang 2012-11-07 02:45:06 CET
Does fresh install work without problems?

If yes, then there are some problems during package updating.
Comment 42 David Walser 2012-11-20 17:03:35 CET
Ping.  What's the status of this?

We're running out of time to fix things for Mageia 1.
Guillaume Rousse 2012-11-20 18:30:22 CET

CC: guillomovitch => (none)

Comment 43 Manuel Hiebel 2012-12-02 14:31:56 CET
Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no 
longer maintained, which means that it will not receive any further security or 
bug fix updates. As a result we are closing this bug. 

If you can reproduce this bug against a currently maintained version of Mageia 
please feel free to click on "Version" change it against that version of Mageia and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX


Note You need to log in before you can comment on or make changes to this bug.