Transition Technology: Ticket Query

#690: Paul learning the ways of the force.

paul — Thu, 20 Feb 2014 15:00:41 GMT

I'm not a jedi yet

#### Transition Network

Week ending 16 February Monday (0,45) Phone call | Emails (not issues) | Creating a test site on Aeigr Tuesday (0.45) Reading Wiki pages | Setting up local server (Generated notes for WIki) Wednesday (0.45) Reading wiki pages: setting up a platform / cloning a stage site. Friday (3.00) Reading wiki pages , listening to Jim's talks, Emails (not issues). (Generated notes for WIki for setting up a local server)

Finished reading wiki. I'll re-read these as required on my own time going forward.

Week ending 23 February Monday (0,15) Emails (not issues) (Mailing list) Thursday (0,30) Phone call / Emails (not issues)

Total 6, 00 hours

#701: Emails & Telephone calls

paul — Tue, 18 Mar 2014 09:38:24 GMT

#711: Emails & Telephone calls

paul — Tue, 01 Apr 2014 13:47:56 GMT

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

paul — Wed, 16 Jul 2014 21:55:29 GMT

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]

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

#759: [Security-news] SA-CONTRIB-2014-071 - FileField - Access bypass

paul — Wed, 16 Jul 2014 21:59:46 GMT

View online: https://www.drupal.org/node/2304561

Advisory ID: DRUPAL-SA-CONTRIB-2014-071
Project: FileField? [1] (third-party module)
Version: 6.x
Date: 2014-July-16
Security risk: Critical [2]
Exploitable from: Remote
Vulnerability: Access bypass

The FileField? module enables you to define and use fields that contain files.

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.

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

accordance with Drupal Security Team processes./

FileField? 6.x-3.x versions prior to 6.x-3.13.

Drupal core is not affected. If you do not use the contributed FileField? [4] module, there is nothing you need to do.

If you use the FileField? module for Drupal 6.x, upgrade to Filefield

6.x-3.13 [5], and also update to Drupal core 6.32 [6] (see SA-CORE-2014-003 [7]).

Ivan Ch [8]

Nate Haug [9]
Ivan Ch [10]
David Snopek [11] of the Drupal Security Team.

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

Learn more about the Drupal Security team and their policies [13], writing secure code for Drupal [14], and securing your site [15].

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

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

#789: SA-CONTRIB-2014-088 - Mollom - Cross-site scripting (XSS)

paul — Mon, 22 Sep 2014 13:09:48 GMT

View online: https://www.drupal.org/node/2340029

Advisory ID: DRUPAL-SA-CONTRIB-2014-088
Project: Mollom [1] (third-party module)
Version: 6.x, 7.x
Date: 2014-September-17
Security risk: 11/25 ( Moderately Critical)

AC:Complex/A:User/CI:Some/II:Some/E:Theoretical/TD:Uncommon [2]

Vulnerability: Cross Site Scripting

Mollom is an "intelligent" content moderation web service which determines if a post is potentially spam; not only based on the posted content, but also on the past activity and reputation of the poster across multiple sites.

Mollom offers a feature to report submitted content as inappropriate which allows end users to indicate that a piece of site content is objectionable or out of place. When reporting content, the content title is not sufficiently sanitized to prevent cross-site scripting (XSS) attacks.

This vulnerability is mitigated by the fact that an attacker must have a role with the permission to create content and the content type must be enabled for "Flag as Inappropriate" within the Mollom advanced configuration settings (which is not the default setting).

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

accordance with Drupal Security Team processes./

Mollom 6.x-2.x versions from 6.x-2.7 to 6.x-2.10
Mollom 7.x-2.x versions from 7.x-2.9 to 7.x-2.10

Drupal core is not affected. If you do not use the contributed Mollom [4] module, there is nothing you need to do.

Install the latest version:

If you use the Mollom module for Drupal 6.x, upgrade to Mollom 6.x-2.11

[5]

If you use the Mollom module for Drupal 7.x, upgrade to Mollom 7.x-2.11

[6]

Also see the Mollom [7] project page.

Matt Vance [8]

Lisa Backer [9] the module maintainer
Matt Vance [10]

Greg Knaddison [11] of the Drupal Security Team

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact [12].

Learn more about the Drupal Security team and their policies [13], writing secure code for Drupal [14], and securing your site [15].

#792: [Security-news] SA-CONTRIB-2014-094 - Webform Patched - Cross Site Scripting (XSS)

paul — Mon, 29 Sep 2014 09:28:08 GMT

View online: https://www.drupal.org/node/2344369

Advisory ID: DRUPAL-SA-CONTRIB-2014-094
Project: Webform Patched [1] (third-party module)
Version: 6.x, 7.x
Date: 2014-September-24
Security risk: 13/25 ( Moderately Critical)

AC:Basic/A:User/CI:Some/II:Some/E:Theoretical/TD:Default [2]

Vulnerability: Cross Site Scripting

The Webform Patched module is a fork of the Webform module with Token support added. The module enables you to create forms which can be used for surveys, contact forms or other data collection throughout your site.

The module doesn't sufficiently sanitize field label titles when two fields have the same form_key, which can only be managed by carefully crafting the webform structure via a specific set of circumstances.

This vulnerability is mitigated by the fact that an attacker must have a role with the permission "create webform content".

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

accordance with Drupal Security Team processes./

Webform Patched 6.x-3.x versions prior to 6.x-3.20.
Webform Patched 7.x-3.x versions prior to 7.x-3.20.

Drupal core is not affected. If you do not use the contributed Webform Patched [4] module, there is nothing you need to do.

Install the latest version:

If you use the webform module for Drupal 6.x, upgrade to webform_patched

6.x-3.20 [5]

If you use the webform module for Drupal 7.x-3.x, upgrade to

webform_patched 7.x-3.20 [6]

Also see the Webform Patched [7] project page.

Maurits Lawende [8]
Matt Vance [9]

Nate Haug [10] the module maintainer

Greg Knaddison [11], Dan Smith [12] and Lee Rowlands [13] of the Drupal

Security Team

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact [14].

Learn more about the Drupal Security team and their policies [15], writing secure code for Drupal [16], and securing your site [17].

#804: Investigating the site security following SA-CORE-2014-005 (Drupal 7.32)

paul — Mon, 03 Nov 2014 15:20:25 GMT

It was discovered that TN could have have been compromised from the recent security vulnerability (even though we are running Drupal 6) as the site is using the DBTNG module. However the site doesn't appear to have been compromised. I'll post my findings shortly.

#809: [Security-news] Drupal Core - Moderately Critical - Multiple Vulnerabilities - SA-CORE-2014-006

paul — Wed, 19 Nov 2014 21:35:25 GMT

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

Advisory ID: DRUPAL-SA-CORE-2014-006
Project: Drupal core [1]
Version: 6.x, 7.x
Date: 2014-November-19
Security risk: 14/25 ( Moderately Critical) AC:Basic/A:None/CI:Some/II:Some/E:Theoretical/TD:Uncommon [2]
Vulnerability: Multiple vulnerabilities

.... Session hijacking (Drupal 6 and 7)

A specially crafted request can give a user access to another user's session, allowing an attacker to hijack a random session.

This attack is known to be possible on certain Drupal 7 sites which serve both HTTP and HTTPS content ("mixed-mode" [3]), but it is possible there are other attack vectors for both Drupal 6 and Drupal 7.

.... Denial of service (Drupal 7 only)

Drupal 7 includes a password hashing API to ensure that user supplied passwords are not stored in plain text.

A vulnerability in this API allows an attacker to send specially crafted requests resulting in CPU and memory exhaustion. This may lead to the site becoming unavailable or unresponsive (denial of service).

This vulnerability can be exploited by anonymous users.

/A CVE identifier [4] will be requested, and added upon issuance, in accordance

with Drupal Security Team processes./

Drupal core 6.x versions prior to 6.34.
Drupal core 7.x versions prior to 7.34.

Install the latest version:

If you use Drupal 6.x, upgrade to Drupal core 6.34. [5]
If you use Drupal 7.x, upgrade to Drupal core 7.34. [6]

If you have configured a custom password.inc file for your Drupal 7 site you also need to make sure that it is not prone to the same denial of service vulnerability. See also the similar security advisory for the Drupal 6 contributed Secure Password Hashes module: SA-CONTRIB-2014-113 [7]

Also see the Drupal core [8] project page.

Session hijacking:

Aaron Averill [9]

Denial of service:

Michael Cullum [10]
Javier Nieto [11]
Andrés Rojas Guerrero [12]

Session hijacking:

Klaus Purer [13] of the Drupal Security Team
David Rothstein [14] of the Drupal Security Team
Peter Wolanin [15] of the Drupal Security Team

Denial of service:

Klaus Purer [16] of the Drupal Security Team
Peter Wolanin [17] of the Drupal Security Team
Heine Deelstra [18] of the Drupal Security Team
Tom Phethean [19]

The Drupal Security Team

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact [20].

Learn more about the Drupal Security team and their policies [21], writing secure code for Drupal [22], and securing your site [23].

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

#849: (No subject)

paul — Tue, 28 Apr 2015 12:35:03 GMT

Hi Sam / Ade
Would you advise when outstanding invoices will be paid? We used to get our
invoices paid every month.
--
Best
Paul Booker
Drupal Developer & Linux Systems Administrator
Website: http://www.paulbooker.co.uk
Drupal.org: https://www.drupal.org/u/paulbooker
Twitter: @paulbooker <https://www.twitter.com/paulbooker>
Tel: +44 01922 861636

#877: RE: outstanding invoices

paul — Thu, 15 Oct 2015 11:20:05 GMT

Hi Sam,
Hope you're well.
Any chance you could pay my 3 outstanding invoices today?
Best, Paul
--
Paul Booker
Drupal Support for Websites and Linux Servers
Website: http://www.paulbooker.co.uk
Tel: +44 01922 861636

#884: RE: http://news.transitionnetwork.org

paul — Thu, 03 Dec 2015 12:40:03 GMT

Hi Chris, All
Can you help me to reset my password for paulbooker for
news.transitionnetwork.org? I just tried to use the reset password form but
I never received an email and when I Iooked at the settings,php file for
the website (generated by Aegir) I couldn't see immediately where to find
the database.
I think I may have missed some recent updates to news.transitionnetwork.org
so urgently need to resolve this today.
Not sure how this has fallen of my radar, but, I just noticed that
news.transitionnetwork.org is no longer mentioned on the platform page on
Aegir so may have got into thinking that this site no longer exists.
http://news.transitionnetwork.org
https://tn.puffin.webarch.net/hosting/platforms
--
Paul Booker
Drupal Support for Websites and Linux Servers
Website: http://www.paulbooker.co.uk
Tel: +44 01922 861636

#899: Managing security after Feb 24th, 2016.

paul — Thu, 28 Jan 2016 15:22:28 GMT

Hello,

Just did some research to check how we will manage security after Feb 24th, 2016.

A small group of vendors (approved by the security team) will provide patches for core and some of the most commonly used contributed modules, that are used on their client websites. Security patches will be put in the Git repo for the D6LTS project on Drupal.org, and will be announced in the issue queue. We will just need to monitor this issue queue and apply any security patches.

However, these vendors will not be supporting ALL contributed modules. Each of the vendors will be maintaining lists, and providing them to the Drupal Security Team so they know which issues to include them on. With this in mind shall we send a copy of our list of contributed modules to each of the vendor companies and ask them to provide us with a list of our modules that they are currently not supporting? We can then decide how we should support the modules that are not supported by the vendors.

Best, Paul