Monthly Archives: December 2014

Drupal

SA-CONTRIB-2014-119 – Google Analytics – Information disclosure

Description

This module enables you to integrate Drupal with Google Analytics.

The module leaks the site specific hash salt to authenticated users when user-id tracking is turned on.

This vulnerability is mitigated by the fact that user-id tracking must be turned on and the attacker needs to have an account on the site.

CVE identifier(s) issued

  • A CVE identifier will be requested, and added upon issuance, in accordance
    with Drupal Security Team processes.

Versions affected

  • Google Analytics 7.x-2.0. Neither earlier nor later versions are affected.

Drupal core is not affected. If you do not use the contributed Google Analytics module,
there is nothing you need to do.

Solution

Install the latest version:

Affected sites are urged to generate a new hash salt and store it in settings.php.

Methods to generate a new hash salt

  • With drush:
    drush php-eval 'echo(drupal_random_key()) . "n";'
  • With openssl:
    openssl rand -base64 32

How to replace the hash salt

  1. Open your settings.php file (e.g., sites/default/settings.php
  2. Locate the variable $drupal_hash_salt: 
    <?php
    /**
     * Salt for one-time login links and cancel links, form tokens, etc.
     * [...]
     */
    $drupal_hash_salt = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX';
    ?>
  3. Replace the value and safe the file
  4. Flush all caches either from within the administrative UI (Administration » Configuration » Development » Performance) or by issuing drush cache-clear all

Effects caused by replacing the hash salt

  • Password reset links generated before the new hash salt will not work anymore. Affected users need to request a new password reset link.
  • Existing image style urls will stop working. A cache flush is necessary such that all <img> tags are updated.

If immediate installation / regeneration of the hash salt is not possible, then disable user-id tracking at once.

Also see the Google Analytics project page.

Reported by

Fixed by

Coordinated by

Contact and More Information

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

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

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

Drupal version: 
Drupal 7.x
Drupal

SA-CONTRIB-2014-118 – Administer Users by Role – Access Bypass – Unsupported

Description

This module enables site builders to set up fine-grained permissions for allowing users to edit and delete other users.

The module doesn’t sufficiently validate access permissions, enabling users who supposedly have limited permissions to grant themselves more permissions.

This vulnerability is mitigated by the fact that an attacker must have a role with the permission “administer users”. While this is usually a permission only granted to trusted users the Administer Users by Role module intends to limit the permission so that users cannot elevate their own permissions, but it fails to do so in certain scenarios.

CVE identifier(s) issued

  • A CVE identifier will be requested, and added upon issuance, in accordance
    with Drupal Security Team processes.

Versions affected

  • administerusersbyrole 6.x – all versions

Drupal core is not affected. If you do not use the contributed Administer Users by Role module,
there is nothing you need to do.

Solution

  • If you use the administerusersbyrole module for Drupal 6.x, disable and uninstall the module

Also see the Administer Users by Role project page.

Reported by

Fixed by

not applicable.

Coordinated by

Contact and More Information

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

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

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

Drupal version: 
Drupal 6.x
Redhat

Analysis of the CVE-2013-6435 Flaw in RPM

The RPM Package Manager (RPM) is a powerful command-line driven package management system capable of installing, uninstalling, verifying, querying, and updating software packages. RPM was originally written in 1997 by Erik Troan and Marc Ewing. Since then RPM has been successfully used in all versions of Red Hat Linux and currently in Red Hat Enterprise Linux.

RPM offers considerable advantages over traditional open-source software install methodology of building from source via tar balls, especially when it comes to software distribution and management. This has led to other Linux distributions to accept RPM as either the default package management system or offer it as an alternative to the ones which are default in those distributions.

Like any big, widely used software, over time several features are added to it and also several security flaws are found. On several occasions Red Hat has found and fixed security issues with RPM.

Florian Weimer of Red Hat Product Security discovered an interesting flaw in RPM, which was assigned CVE-2013-6435. Firstly, let’s take a brief look at the structure of an RPM file. It consists of two main parts: the RPM header and the payload. The payload is a compressed CPIO archive of binary files that are installed by the RPM utility. The RPM header, among other things, contains a cryptographic checksum of all the installed files in the CPIO archive. The header also contains a provision for a cryptographic signature. The signature works by performing a mathematical function on the header and archive section of the file. The mathematical function can be an encryption process, such as PGP (Pretty Good Privacy), or a message digest in the MD5 format.

If the RPM is signed, one can use the corresponding public key to verify the integrity and even the authenticity of the package. However, RPM only checked the header and not the payload during the installation.

When an RPM is installed, it writes the contents of the package to its target directory and then verifies its checksum against the value in the header. If the checksum does not match, that means something is wrong with the package (possibly someone has tampered with it) and the file is removed. At this point RPM refuses to install that particular package.

Though this may seem like the correct way to handle things, it has a bad consequence. Let’s assume RPM installs a file in the /etc/cron.d directory and then verifies its checksum. This offers a small race-window, in which crond can run before the checksum is found to be incorrect and the file is removed. There are several ways to prolong this window as well. So in the end we achieve arbitrary code execution as root, even though the system administrator assumes that the RPM package was never installed.

The approach Red Hat used to solve the problem is:

  • Require the size in the header to match with the size of the file in the payload. This prevents anyone from tampering with the payload, because the header is cryptographically verified. (This fix is already present in the upstream version of RPM)
  • Set restrictive permissions while a file is being unpacked from an RPM package. This will only allow root to access those file. Also, several programs, including cron, perform a check for permission sanity before running those files.

Another approach to mitigate this issue is the use of the O_TMPFILE flag. Linux kernel 3.11 and above introduced this flag, which can be passed to open(2), to simplify the creation of secure temporary files. Files opened with the O_TMPFILE flag are created, but they are not visible in the file system. As soon as they are closed, they are deleted. There are two uses for these files: race-free temporary files and creation of initially unreachable files. These unreachable files can be written to or changed same as regular files. RPM could use this approach to create a temporary, unreachable file, run a checksum on it, and either delete it or atomically link it to set the file up, without being vulnerable to the attack described above. However, as mentioned above, this feature is only available in Linux kernel 3.11 and above, was added to glibc 2.19, and is slowly making its way into GNU/Linux distributions.

The risk mentioned above is greatly reduced if the following precautions are followed:

  • Always check signatures of RPM packages before installing them. Red Hat RPMs are signed with cryptographic keys provided at https://access.redhat.com/security/team/key. When installing RPMs from Red Hat or Fedora repositories, Yum will automatically validate RPM packages via the respective public keys, unless explicitly told not to (via the “nogpgcheck” option and configuration directive).
  • Package downloads via Red Hat software repositories are protected via TLS/SSL so it is extremely difficult to tamper with them in transit. Fedora uses a whole-file hash chain rooted in a hash downloaded over TLS/SSL from a Fedora-run central server.

The above issue (CVE-2013-6435) has been fixed along with another issue (CVE-2014-8118), which is a potentially exploitable crash in the CPIO parser.

Red Hat customers should update to the latest versions of RPM via the following security advisories:
https://rhn.redhat.com/errata/RHSA-2014-1974.html
https://rhn.redhat.com/errata/RHSA-2014-1975.html
https://rhn.redhat.com/errata/RHSA-2014-1976.html

Full Disclosure

NEW VMSA-2014-0014 – AirWatch by VMware product update addresses information disclosure vulnerabilities

Posted by VMware Security Response Center on Dec 10

————————————————————————
VMware Security Advisory

Advisory ID: VMSA-2014-0014
Synopsis: AirWatch by VMware product update addresses information
disclosure vulnerabilities
Issue date: 2014-12-10
Updated on: 2014-12-10 (Initial Advisory)
CVE number: CVE-2014-8372

————————————————————————

1. Summary

AirWatch by…

AVG

Top Threats to Business Data in 2015

Around 1,000 delegates at the NexGen Cloud Conference in San Diego last week heard Tony Anscombe give some valuable insight into the partner opportunity for the Internet of Things.  The good news for our service provider partners is the opportunity is huge. Our recent Monetization of IoT study shows that around three fifths (62 percent) of small businesses has budget specifically assigned over the next 12 months for the development of IoT solutions.

On this evidence 2015 is shaping up to be an important year for IoT investment.  Engaging with IT providers on NextGen Cloud matters is just one component of what’s to come. The other part concerns the immediate future for their small business customers and the ever changing threat landscape.

With that in mind, here are my top threats to watch for in 2015:-

More ransomware

The latter part of 2013 was notable for a spate of ransomware attacks on small businesses. This has continued in 2014 and we are likely to see more instances in 2015. Ransomware, like the infamous CryptoLocker, encrypts or locks personal files on your machine and extorts a ransom to recover them.  To avoid falling victim, businesses should use reputable antivirus software, avoid risky downloads, educate staff and keep security software/operating systems regularly patched and updated.

 

Advanced Persistent Threats (APTs)

Cybercriminals are increasingly focusing their attacks on small businesses.  APTs are a relatively new class of malware developed by cybercriminals to steal passwords, logins and customer data.  They are purposely designed to gain a foothold in the business and remain there undetected for a prolonged period of time.  To counter this businesses require an equally sophisticated approach to defense that includes protection from risks in mobile communications and Cloud services as well as traditional networks.

 

Password-related breaches

As Cloud services and the Internet of Things become part of everyday business life password management is going to become a hot issue.  We saw a good example of this in the news last month where streaming images from thousands webcams and CCTVs around the world ended up on a Russian website simply because they had default passwords or no log-in codes at all.   Many of the images were taken from business CCTV equipment.  Until companies learn to manage their passwords efficiently we can expect to see a lot more of this kind of incidents.

 

Mobile threats

Not so long ago it was probably quite natural for your Apple®-loving colleagues to congratulate themselves for using the relatively threat-free Macintosh platform. But the tide is turning.  The prevalence of iPad® and iPhone® mobile devices in the office has turned the Apple operating system into a prime target. Last month we saw reports of a new combination of malware that infects Apple’s OS®X and iOS® mobile devices called the OSX/WireLurker Trojan.  Android™ too is subject to attack. You may have seen recent news reports about a new variant of Android malware called NotCompatible that uses spam email blasts and compromised websites to infiltrate secure company networks.

 

In summary, the outlook for business security threats is one of increasing diversity.  At the same time more IoT devices and Cloud services are coming on stream. Our study strongly indicates that small businesses are ready to spend on ways to simplify how things are kept up to date, secure and monitored in 2015.

iPhone®, iPad® and Apple® are trademarks of Apple Inc., registered in the United States and other countries.
Android™ is a trademark of Google Inc.