Blog

Improvements to Security in Drupal 7

greggles — Wed, 01 Jul 2015 21:49:52 +0000

Drupal 7 has several security improvements. People often ask if the book Cracking Drupal covers Drupal 6 or Drupal 7. The answer is that it mostly covers both because security issues did not change much between the versions. So the book is still just as relevant for Drupal 7 with the exception of the topics below. The only other major topic the book doesn't cover is CSRF, but you can read an article about Protecting Drupal from CSRF .

New Database API reduces opportunity for SQL Injection

SQL Injection makes up roughly 10% of the vulnerabilities that have been found in Drupal core or contributed modules. A lot of the times this comes from people not using query placeholders, using the wrong placeholders, or trying to build dynamic queries without properly filtering user inputs. The new database API solves these three problems:

It is based on object oriented system so people are taught to use the placeholder system by default
It completely re-thinks how placeholders work making it so the right placeholder will be automatically inserted wither your argument is a number, string, or an array of data.
It makes it much easier to do dynamic queries - See Jeff Eaton's post for details

It's still possible to create SQL Injections in Drupal 7, of course. The first is to use the ->where() method of conditional clauses which "allows for the addition of arbitrary SQL as a conditional fragment." If your code can insert arbitrary SQL then it can insert a SQL Injection. The other way is to simply use db_query for a static query but put concatenated user input into the query string. Luckily both of those things are easy to spot in a review and will soon become red-flags for every code reviewer.

As you can see, the redesigned database API is much less likely to be used incorrectly. I believe we'll see a decrease in SQL Injection vulnerabilities as Drupal 7 is adopted.

Improved hashing algorithms

We moved away from the increasingly crackable md5 hashing algorithm for all hashes. Passwords are now hashed with a user specific salt which makes them harder to crack. By default they are hashed 2^15 times, though you can control that number by setting

<?php $conf['password_count_log2'] = 16; ?>

or whatever other number you choose. The benefit of setting that variable in your settings.php is that it is not in the database so a malicious user attempting to crack a password would have to try hashing it a different number of times. This provides several benefits. It makes it very difficult to reverse engineer the passwords associated with accounts/emails if a database backup is exposed to the world or a SQL injection is found. It also makes it harder for developers to make mistakes when building an external authentication mechanism since they are practically forced to use the password/user API.

The password hashing mechanism is based on phpass and is compatible with other systems that use that system. This is helpful if importing users from another site or exporting users from one version of Drupal to another.

There is now a site specific salt called

<?php $drupal_hash_salt ?>

that lives in the settings.php in addition to the site specific key called drupal_private_key which is stored in the database. These private key values can be used to increase the strength of hashed/encrypted data.

If you just install Drupal it wil create a drupal_hash_salt value for you, but if you want to use a different one that is managed outside of your settings.php you can simply edit the settings.php prior to installation and set the

<?php $drupal_hash_salt = file_get_contents('/home/example/salt.txt'); ?>

. The salt.txt file should be somewhere that the webserver can read, but is not generally available to other users on your unix system. It should be read-only for the webserver. The permissions on settings.php should give a good guide for how to set the salt.txt permissions. The file should contain a string of randomly generated information. Random.org can give tips on how to create random strings.

These improvements are more about hardening Drupal to stay "current" than it is about reducing any specific vulnerability.

Drupal 7's built-in brute force detection

Drupal 7 also includes brute force login attack prevention. This was possible in Drupal 6 via solutions like the Login Security module but now it's part of core. This feature was added in the issue to Improve security: rate limit login attempts which does not provide a specific user interface to the feature. It does, however, have four important variables. The first two are for limiting the failed logins by IP: user_failed_login_ip_limit which defaults to 50 and user_failed_login_ip_window which defaults to 3600 seconds (i.e. one hour). The second set are for limiting failed logins per user: user_failed_login_user_limit which defaults to 5 attempts and user_failed_login_user_window which defaults to 21600 seconds (i.e. 6 hours).

Easier module updates: plugin manager

One of the persistent problems with security releases is getting sites upgraded. If the patch is out but nobody has installed it then it doesn't help. Drupal 7 includes the ability to install or update modules via the administrative interface making it much easier to keep a site up to date. This process uses ssh or ftp in a local loopback to access the files so that the webserver doesn't have to have the ability to write files. This, of course, can be seen to have drawbacks. The ideal way to manage this is as a separate user and keep close tabs on the proper file permissions and the web-based installer promotes some bad practices (e.g. leaving FTP running). I think this feature is good for some sites and hope people will use it to keep their sites up to date. If you are scared of the practices it allows then I suggest you disable it by going into settings.php and uncommenting this line at the bottom to disable the feature.

<?php $conf['allow_authorize_operations'] = FALSE; ?>

Drupal.org improvements in security coincide with Drupal 7 release

Drupal 7 was released in January of 2011 and the git migration wrapped up in March of 2011. The move to git helps module maintainers to create a new release of their module based on an old tag without having to do gymanistics in CVS. This will allow security releases to contain ONLY security fixes which will help site builders to deploy those changes quickly. Site builders will be able to QA the change much more rapidly and worry less about features and bugfix changes in the code that might break their site.

Knowing security is a process, we have also made improvements to our security advisory process. The security.drupal.org site is where the Security Team collaborates on issues. It now provides access to an issue for issue reporter and module maintainer to make collaboration with the team easier. This should increase the free time the Security Team has to work on other items, and for maintainers it will increase the ease of interacting with the Security Team making them more likely to get the fix released properly. We also are using a template for writing the Security Advisories. This process increases the quality of the advisories and lets module maintainers write them directly without needing nearly as much help from the security team. Again, that's a big help to both the Security Team and the module maintainers.

Why counting vulnerabilities is not a sufficient method of comparing product security

greggles — Tue, 18 Jun 2013 16:38:39 +0000

A lot of people find themselves in the position of trying to figure out which software package is the most secure, or at least more secure between a field of choices. They often try to do this by comparing the number of vulnerabilities in the two packages, going to vulnerability databases like MITRE-CVE or NIST-NVD.

However, consider this example timeline of vulnerability disclosure from a sample issue on full disclosure

2013.05.11 Vulnerability reported to the vendor
2013.05.12 Vendor asked for details
2013.05.12 Details and exploit provided to the vendor
2013.05.30 Asked vendor about the status of investigation (no response)
2013.06.11 Sent another mail to the vendor (no response)
2013.06.15 Full disclosure

That is actually a real problem that could expose passwords and private key of a site. It affects the core software. And even though the researcher followed responsible disclosure, apparently the security team didn't do anything about the issue after a month. Perhaps the worst part of all this...there's a good chance this vulnerability will never make it into a database like NVD or CVE.

Consider this example the next time someone talks about numbers of vulnerabilities. Remind them that it's more important that there is an active group of people who are:

Looking for vulnerabilities (these people don't have to be part of the product's insider community)
Fixing them

In this case the active user base of the product has led a researcher to find the problem. But then the product developers didn't follow through on fixing the issue and therein comes the problem: users are vulnerable and unaware of the problem.

Notes from Linux Security Tunables by Kees Cook

greggles — Fri, 31 May 2013 15:58:17 +0000

I recently attended Drupalcon Portland where I attended Kees Cook's session on Linux System Security Tunables. He had some great general security advice before the session began. You can watch the video on the Drupalcon site and read the slides there. Here are my notes from the session.

Authentication hygiene (e.g. ssh keys)

know where your credentials live
keep away from devices with remote access
store encrypted, tied to a specific device - if you lose control of that device, revoke those keys
don't use password or even only-passphrase authentication
keep the ssh comments (user@host) so you can more easily revoke keys in case you need to
ssh gives you a host key when you first connect - verify that it's right! ssh-keygen -f /etc/ssh/ssh_host_rsa.pub -lv

Discretionary Access Control (user-defined)

Personal accounts
- no direct access
Web services
- no access to personal information nor reconfigure itself
- cannot change execution
Service maintainers
- No access to personal acct, limited system access
- Can modify a given service (e.g. the database service)
System admin
- extremely powerful
This is great for logging because you can see transitions between levels
Clear lines between data and execution
Control access via sudo or other keys
User_Alias SOME_SERVICE = kees, gchaix, pholcomb
OR put individual keys into /home/some_service/.ssh/authorized_keys

Mandatory Access Control

AppArmor
SELinux
SMACK
Tomoyo

Multifactor Authentication (TFA or more)

Downside to recommending sudo: 1 password for 2 accounts
MFA can help

Kernel tunables

Tree of items /proc/sys
Use sysctl to edit them, or they are files so you can just edit them
randomize_va_space=2
net.ipv4.tcp_syncookies=1
kernel.yama.ptrace_scope=1
vm.mmap_min_addr=65536
kptr_restrict=1
kernel.dmesg_restrict=1
fs.protected_symlinks=1
fs.protected_hardlines=1
kernel.modules_disabled=1

Start today

Make a plan
Prioritize the changes
Make changes
Automate verification (cacti, nagios, cron, etc.)

Automated Security Reviews for Drupal - 2011 edition

greggles — Fri, 10 Jun 2011 07:00:00 +0000

These are the slides for a presentation on Automated Security Reviews I'm doing at Drupalcamp Colorado. You may also be interested in Steps to a Drupal Security Review.

Cracking Drupal Kindle Edition now available for $14.84 (Still relevant for Drupal 7)

greggles — Wed, 06 Apr 2011 15:56:39 +0000

The day has finally come - Cracking Drupal is available for the Kindle.

Cracking Drupal on the Kindle

I asked my publisher about this almost instantly after the book came out. I had recently received a Kindle as a gift and was excited about e-books. Unfortunately the technology was young and getting a book on such a specific topic into the Kindle format was a daunting task for them. It seems either the Kindle format got easier or they got better at reformatting things to Kindle format or both and now it's available.

The Kindle edition costs $14.84 compared to $25 for the Amazon version of the book compared to $40 for the Wiley hardback available in stores or the $40 Wiley PDF available from Wiley.com.

Drupal 7: Covered by Cracking Drupal so far

One other question I've had a lot of recently is whether or not the book Cracking Drupal covers Drupal 7. The answer is basically yes. While I was writing the book the biggest change coming about was the database API. Indeed it is now out and indeed it makes it much harder to create sql injections. Everything else the book talks about - thinking like a hacker, the nature of cross site scripting, cross site request forgeries, and sql injection - are all still relevant in Drupal 7 as they were in Drupal 6 and the configuration, process and coding practices to keep your site safe are still basically the same.

There is a chance that I will create an updated version of the book that more specifically covers Drupal 7 but I think more likely is to skip Drupal 7 and instead wait for a version of the book on Drupal 8. By then things will have changed enough to make it worthwhile and I can expand the coverage of areas I didn't cover as much as I would have liked to (mainly CSRF).