Many UNIX and Linux systems actually have cron jobs that check for world-writable files. On Apple’s OS X there is no such safeguard and many vendors do not seem to care about file permissions much at all. Several well-known applications are either installed with world-writable files or create them when used:

World-writable files in system directories

The following applications install world-writable files in shared directories (/Applications, /Library, …):

• Adobe CS 4, CS 5: Some uninstallers + several files and directories in /Library/Application Support + various stuff in other locations
• Adobe Media Player: directory + some files in Contents/Resources
• Adobe Flash Player: directories (including AddIns und AddIns/airappinstaller)
• Amazon MP3 Downloader: some directories
• EPSON (Scan, TWAIN data source, Easy Photo Print, …): pretty much everything, including executables
• Eye-One Match 3: complete app, including executable
• eMusic Download Manager: complete app, including executable and JavaScript (the application is based on Mozilla)
• Telltale games: complete apps including executable and libraries
• Apple OS X: some plist and cache files, including at least one LaunchDaemon plist file
• Google+Growl Utility (not a Google product): whole app including executable
• HP Scan Pro (plus supporting files): everything including executables
• DivX Converter: resource files
• Apple Remote Desktop: some plist files
• Apple GarageBand: several plist and data files
• Apple ColorSync: some profiles
• Microsoft Office 2011: directory in /Library Application Support
• Elgato EyeTV: several plist files
• ABBYY FineReader Sprint 8.0: several data files
• ArcSoft (Connect Suite, MediaImpression 2): all files, including executables
• Extensis Suitcase Fusion 2: all files, including executables

World-writable files in user directories

The following applications install world-writable files in user directories (/Users/$USER):

• GoogleGrowl.plugin: whole plugin including executable
• 3rd-party extensions for Apple Safari: some extensions (e.g. AdBlock) install world-writable files
• Apple iPhoto: the whole library seems to be world-writable
• Adium add-ons: several add-ons install world-writable files
• eMusic Download Manager:some preferences files are world-writable
• Adobe (CS 4, CS5, Flash, …): several preferences files
• Apple MobileDevice: crash logs are world-writable

The lists have been compiled by inspecting my own systems and those of several friends by running

sudo sh -c \
  "find / -xdev -perm +o=w ! \( -type d -perm +o=t \) ! -type l -print0 | \
   xargs -0 ls -dl 2>&1 | \
   tee world-writable-files.txt"

and analyzing the output.

Note that running Disk Utility‘s “Repair Disk Permissions” does not have any influence on the issues described here.

Most OS X installations are probably single-user systems in reality but the situation is still somewhat ugly.

Facebook’s FAQs (1, 2) have not been updated accordingly yet.

Firefox’s built-in search capabilities still use the unencrypted search, though. To remedy this I built an OpenSearch plug-in which makes Firefox use the HTTPS-based search:

Install Google Secure Search Plug-In

(Read more about Google’s SSL Search here)

It may be a good idea for the WordPress developers to sign their releases with a well known and trusted PGP key. This would allow people to verify that downloaded files are really what they should be!
This is a well-established practice used by other projects, for example by the Linux kernel.

Read the complete SSL setup guide here: Securing WordPress 2 Admin Access With SSL

Regarding WordPress security, please note that there still is a possible exploit for 2.0.6: New WordPress exploit also affects version 2.0.6
Make sure you use safe a PHP version and set register_globals = off.

• Prepare the chroot directory. It’s recommended to use an extra partition/filesystem for it. I will use /srv/mysql (which is an LVM2 partition with an ext3 filesystem on my system) for the rest of the text.
• Stop MySQL:

  /etc/init.d/mysql stop

• Copy the databases to new location:

  mkdir -p /srv/mysql/var/lib
  cp -a /var/lib/mysql /srv/mysql/var/lib

• Copy this script to /etc/default/mysql-chroot
• Edit /etc/init.d/mysql:
  • Source the mysql-chroot script somewhere at the top:

    …
    test -x /usr/sbin/mysqld || exit 0
    
    . /etc/default/mysql-chroot
    
    SELF=$(cd $(dirname $0); pwd -P)/$(basename $0)
    …

  • Fix the disk space check:

    …
    # check for diskspace shortage
    datadir=`mysqld_get_param datadir`
    if LC_ALL=C BLOCKSIZE= df --portability $CHROOT_DIR$datadir/. | tail -n 1 | awk '{ exit ($4>4096) }'; then
      log_failure_msg "$0: ERROR: The partition with $datadir is too full!"
    …

  • Run setup_chroot right in the start section:

    …
    if mysqld_status check_alive nowarn; then
      echo "...already running."
    else
      setup_chroot
      /usr/bin/mysqld_safe > /dev/null 2>&1 &
    …

  • Somehow /var/run/mysqld/mysqld.pid disappears after each start. We have to create it each time, otherwise the stop command won’t work properly:

    …
    if mysqld_status check_alive warn; then
      log_end_msg 0
      ln -sf $CHROOT_DIR/var/run/mysqld/mysqld.pid \
                     /var/run/mysqld
      # Now start mysqlcheck or whatever the admin wants.
      output=$(/etc/mysql/debian-start)
    …

• In /etc/mysql/debian.cnf, change the two socket lines to:

  socket = /srv/mysql/var/run/mysqld/mysqld.sock

• In /etc/mysql/my.cnf:
  • Change the socket line in the [client] section to:

    socket = /srv/mysql/var/run/mysqld/mysqld.sock

    Don’t change the socket lines in the other sections!

  • Add

    chroot = /srv/mysql

    to the [mysqld] section.

• Prepend /srv/mysql to the log files listed in /etc/logrotate.d/mysql-server
• Make /usr/bin/mysql_upgrade_shell use the chrooted socket. Note: Currently these changes must be made each time mysql gets upgraded because upgrades override this file!

  …
  --password=*) password=`echo "$arg" | sed -e 's/^[^=]*=//'` ;;
  --socket=*) socket=`echo "$arg" | sed -e 's/^[^=]*=//'` ;;
  --ldata=*|--data=*|--datadir=*) DATADIR=`echo "$arg" | sed -e 's/^[^=]*=//'` ;;
  …
  fi
  $bindir/mysql_fix_privilege_tables --silent --user=$user --password=$password --socket=$socket $args
  exit 0
  …
  check_args="--check-upgrade --all-databases --auto-repair --user=$user --password=$password --socket=$socket"
  …
  $bindir/mysql_fix_privilege_tables --silent --user=$user --password=$password --socket=$socket $args
  …

• Start MySQL:

  /etc/init.d/mysql start

• Check /var/log/syslog for errors ;-)

The situation has not changed much since WordPress 1.5: WordPress 2.0 still does not support HTTPS access to the admin area when the rest of the blog is served via normal HTTP and I still do not like logging in to my server over unencrypted connections, especially not when using public WLANs. Getting around this WordPress limitation requires quite a few steps:

The Goal

All communication involving passwords or authentication cookies should be done over HTTPS connections. wp-login.php and the wp-admin directory should only be accessible over HTTPS.
Normal reading access, as well as comments, tracebacks, and pingbacks still should go over ordinary HTTP.

The Plan

• Add an HTTPS virtual host that forwards requests to the HTTP virtual host
• Modify WordPress to send secure authentication cookies, so cookies never get sent over insecure connections accidentally
• Require a valid certificate on HTTPS clients. That means to log in to WordPress you need both a valid certificate and a valid password. If someone manages to get your password, he still can not login because he does not have a valid certificate.

The Implementation

Note: This documentation assumes a Debian sarge installation with Apache 2. Some things, in particular Apache module related ones, will be different on other systems.
The server used throughout the instructions is example.org/192.0.34.166. The server’s DocumentRoot is /blog and WordPress resides in /blog/wp. The value of WordPress’ home option is ‘http://example.org&/#8217; and the value of its site_url option is ‘http://example.org/wp’.

• Prepare the SSL certificates:
  • Generate your own certificate authority (CA) if you don’t have one already (I’m using the makefile from OpenSSL Certificate Authority Setup for managing mine) and import it into your browser.
  • Generate a certificate for the SSL server and certify it with your private CA.
  • Generate a certificate for your browser and certify it with your private CA. Most browsers expect a PKCS#12 file, so generate one with

    $ openssl pkcs12 -export -clcerts \
        -in blogclient.cert \
        -inkey blogclient.key \
        -out blogclient.p12

    Then import blogclient.p12 into your browser.

• Make WordPress SSL-ready:
  Apply this patch to the WordPress code. It makes the following changes:
  • Use secure authentication cookies in wp_setcookie()
  • Make check_admin_referer() work with HTTPS URLs
  • Use HTTPS URLs for notification mails
  • Use HTTPS URLS for redirects to wp-login.php
  • Only allow XML-RPC logins from the local host (ie. the HTTPS proxy)
  • Add the Mark-as-Spam feature from trunk

  The patch is against svn version 3825 of WordPress (ie. WordPress 2.0.3), when you apply it to a newer version, you will likely get some harmless ‘Hunk succeeded’ message. If you are getting ‘Hunk FAILED’ message, just send me note and I’ll update the patch.

• Enable the necessary Apache modules:
  • Install mod_proxy_html. It will be used to replace absolute ‘http://example.org&/#8217; HTTP URLs in the WordPress output with ‘https://example.org&/#8217; HTTPS URLs:

    $ aptitude install libapache2-mod-proxy-html

    The module gets enabled automatically after installation.

  • Enable mod_proxy and mod_ssl

    $ a2enmod proxy
    $ a2enmod ssl

    Debian provides sane default configurations for both modules. You might want to take a look at the configuration files (ssl.conf and proxy.conf) nevertheless.
    I have changed SSLCipherSuite to

    TLSv1:SSLv3:!SSLv2:!aNULL:!eNULL:!NULL:!EXP:!DES:!MEDIUM:!LOW:@STRENGTH

    in ssl.conf in order to just allow TLS v1 and SSL v3 ciphers which provide strong encryption and authentication (see ciphers(1)).

  • If you are compressing WordPress output (that is if you enabled the ‘WordPress should compress articles (gzip) if browsers ask for them’ option) then also enable mod_headers:

    $ a2enmod headers

• Configure Apache to listen on the HTTPS port

  $ cat > /etc/apache2/conf.d/ssl.conf << EOF
  <IfModule mod_ssl.c>
  	Listen 443
  </IfModule>
  EOF

• Modify the blog virtual host to limit access to wp-login.php and wp-admin to the local host. Also completely deny access to files which should never be accessed directly. Here is an example: 10-wp2-example.org
• Now setup the HTTPS virtual server: 20-wp2-example.org-ssl
  If you are compressing WordPress output you have to enable the RequestHeader line.
• Enable the site and restart Apache

  $ a2ensite 20-blog-ssl
  $ /etc/init.d/apache2 restart

• Remove the old WP cookies from your browser
• Test the new setup!

February 1st, 2006: wp2-ssl.patch updated for WordPress 2.0.1

March 11st, 2006: WordPress 2.0.2 has been released, fixing some security issues. The HTTPS patch still applies fine to that version.

March 19th, 2006: Updated wp2-ssl.patch. Changes: Fix bug in list-manipulation.php, use HTTPS for ‘Login’ and ‘Register’ links, backport ‘Mark-as-Spam’ feature from trunk

May 1st, 2006: WordPress 2.0.3 has been released. Here is the updated wp2-ssl.patch.

July 29th, 2006: WordPress 2.0.4 has been released, fixing some security issues. Here is an updated version of the wp2-ssl.patch.

January 12st, 2007: wp2-ssl.patch updated for 2.0.6 and 2.0.7-RC1

January 15st, 2007: WordPress 2.0.7 has been released. The patch still applies fine to that version.

The issue isn’t Blackdown-specific. Sun released an advisory too.

Thanks to Matthias Klose, Debian packages for 1.4.2-03 are available too. Just add something like

deb ftp://ftp.tux.org/java/debian/ sarge non-free

to your /etc/apt/sources.list.

The Release files are signed with the Blackdown Java-Linux Package Signing Key. If you have recent apt version you can use this key to authenticate our Debian packages. Just import the key with apt-key:

$ wget http://www.blackdown.org/java-linux/java2-status/gpg.asc
$ apt-key add gpg.asc

The lack of security support was one of the main problems with “testing”. You had to pull security fixes from “unstable” or even build your own packages to keep it secure.

I hope they have the manpower to keep up with security issues. Debian’s main security team, which only provides updates for the “stable” distribution, had some problems over the last months.

Stefan Esser reports that there are two WordPress 1.5.2 versions. The first one, which didn’t fix the problem it was supposed to fix, was available for download for several hours before it silently was replaced by the fixed second version.

It’s hard to understand why the version number wasn’t bumped for the second release and why the WordPress developers didn’t inform users about the mistake.

The comments from the WordPress crowd are a bit weak in my opinion. If there’s FUD about WordPress’ security it’s the sole fault of the WordPress developers!

I, myself, am perfectly able to figure out what was broken and how it was fixed. That’s not the point. I was commenting on the handling of security announcements by the WordPress developers.

I expect to get information about security issues from a central, easy-findable place from any project or product that has public exposure and more than a handful of users. (Yes, I expect that from open source projects too. Look around the net to see how good others handle it.)
Expecting your users to gather information about a problem from forums, blogs, foreign sites, or the source code is simply unprofessional.

The often used argument that more specific information only helps hackers is just plain naïve: WordPress is open source, its code and even nicely formatted svn changesets are freely available on the web. Hackers are not stupid, they’ll find the issues.

Note, I’m not saying you should post sample exploits publicly. Just give enough information that administrators can determine whether their systems are vulnerable and how severe the problem is. Again, go around the net and look how other projects handle security announcements.

I hate that kind of silly security by obscurity. Vague vulnerability descriptions are almost useless for administrators, just saying “we’ve fixed some security problems” is even worse!

August 15th, 2005: See this article for a reply to some comments I’ve received.

August 18th, 2005: The WordPress developers seem to have problems with release management too: There are two different 1.5.2 versions, read more in WordPress Security Annoyances.

deb ftp://ftp.tux.org/java/debian/ sarge non-free

to your /etc/apt/sources.list.

Upgrading is recommended as 1.4.2-02 contains an important security fix.

Users of other Java implementations based on Sun’s code should check for updates too.

I didn’t want to use the Symantec tools that came bundled with the system due to previous experiences, so I had to look for another antivirus & firewall solution. After reading a few reviews I decided to try G-Data AntiVirusKit InternetSecurity 2005 first. Installation went smooth but after the next reboot the taskbar didn’t repaint anymore and Explorer was unresponsive. The system was in pretty unusable state.

After booting into Safe Mode, I’ve changed the Data Execution Prevention (DEP) settings to only cover core Windows programs. Another reboot and G-Data started working! Well that’s quite disappointing, x86 processor with No-Execute (NX) and Execute Disable (XD) bits are available for more than two years now and XP SP2 isn’t exactly new either — still G-Data hasn’t managed to fix its code!

Lesson learned: If you have a processor that supports NX or XD (same thing, just different marketing names from AMD and Intel) and you plan to actually take advantage of that feature, you better should check twice which software you’re going to use — especially when using closed-source software. (Linux users should be on the safe side, I haven’t see an application having problems with NX for a long time.)

I’ve removed G-Data AntiVirusKit InternetSecurity 2005 and installed F-Secure Internet Security 2005 which seems to work fine with DEP enabled globally.

Read more on the shorewall-devel list.

It is sad to hear that, Tom did a great job. Shorewall is one the best firewall tools available for Linux. I sincerely hope somebody will pick up the project and continue development. If I had the time I would do it myself.

As one can guess from the look of this site, I’m using WordPress as my blog engine. At this time WordPress does not support HTTPS access to the admin area when the rest of the blog is served via normal HTTP. This is a bit unfortunate. I do not like logging in to my server over unencrypted connections, especially not when using public WLANs. Getting around this WordPress limitation requires quite a few steps:

The Goal

All communication involving passwords or authentication cookies should be done over HTTPS connections. wp-login.php and the wp-admin directory should only be accessible over HTTPS.
Normal reading access, as well as comments, tracebacks, and pingbacks still should go over ordinary HTTP.

The Plan

• Add an HTTPS virtual host that forwards requests to the HTTP virtual host
• Modify WordPress to send secure authentication cookies, so cookies never get sent over insecure connections accidentally
• Require a valid certificate on HTTPS clients. That means to log in to WordPress you need both a valid certificate and a valid password. If someone manages to get your password, he still can not login because he does not have a valid certificate.

The Implementation

Note: This documentation assumes a Debian sarge installation with Apache 2. Some things, in particular Apache module related ones, will be different on other systems.
The server used throughout the instructions is example.org/192.0.34.166. The server’s DocumentRoot is /blog and WordPress resides in /blog/wp. The value of WordPress’ home option is ‘http://example.org&/#8217; and the value of its site_url option is ‘http://example.org/wp’.

• Prepare the SSL certificates:
  • Generate your own certificate authority (CA) if you don’t have one already (I’m using the makefile from OpenSSL Certificate Authority Setup for managing mine) and import it into your browser.
  • Generate a certificate for the SSL server and certify it with your private CA.
  • Generate a certificate for your browser and certify it with your private CA. Most browsers expect a PKCS#12 file, so generate one with

    $ openssl pkcs12 -export -clcerts \
        -in blogclient.cert \
        -inkey blogclient.key \
        -out blogclient.p12

    Then import blogclient.p12 into your browser.

• Make WordPress SSL-ready:
  Apply this patch to the WordPress code. It makes the following changes:
  • Use secure authentication cookies in wp_setcookie()
  • Make check_admin_referer() working with HTTPS URLs
  • Disable login over XML-RPC
• Enable the necessary Apache modules:
  • Install mod_proxy_html. It will be used to replace absolute ‘http://example.org&/#8217; HTTP URLs in the WordPress output with ‘https://example.org&/#8217; HTTPS URLs:

    $ aptitude install libapache2-mod-proxy-html

    The module gets enabled automatically after installation.

  • Enable mod_proxy and mod_ssl

    $ a2enmod proxy
    $ a2enmod ssl

    Debian provides sane default configurations for both modules. You might want to take a look at the configuration files (ssl.conf and proxy.conf) nevertheless.

  • If you are compressing WordPress output (that is if you enabled the ‘WordPress should compress articles (gzip) if browsers ask for them’ option) then also enable mod_headers:

    $ a2enmod headers

• Configure Apache to listen on the HTTPS port

  $ cat > /etc/apache2/conf.d/ssl.conf << EOF
  <IfModule mod_ssl.c>
  	Listen 443
  </IfModule>
  EOF

• Modify the blog virtual host to limit access to wp-login.php and wp-admin to the local host. Also completely deny access to files which should never be accessed directly. Here is an example: 10-example.org
• Now setup the HTTPS virtual server: 20-example.org-ssl
  If you are compressing WordPress output you have to enable the RequestHeader line.
• Enable the site and restart Apache

  $ a2ensite 20-blog-ssl
  $ /etc/init.d/apache2 restart

• Remove the old WP cookies from your browser
• Test the new setup!

A closer look at ipt_recent.c revealed that the time tests did not work like intended if one of the last hits was more than LONG_MAX jiffies ago or if the list of last hits contained empty slots and jiffies is greater than LONG_MAX.

To fix this, I replaced jiffies with seconds since ’00:00:00 1970-01-01 UTC’. I have sent the patch to linux-kernel and netfilter-devel. The patch also includes some 64-bit fixes.

May 12th, 2005: The patch has been added to Linux 2.6.12-rc4-mm1

September 8th, 2005: Please note that only the 64-bit parts of my patch have made it into 2.6.12. I’m working on an updated fix for the time comparison problems which will hopefully get accepted for 2.6.14 or later.

September 12th, 2005: These issues have CAN numbers now: CAN-2005-2872 and CAN-2005-2873 (which supersede CAN-2005-2802)

July 10th, 2006: The jiffies issue is fixed in the vanilla kernel now. Also note that 2.6.18 will contain a rewrite of ipt_recent.c.

That means libc.so.6 is linked statically now. But glibc’s getpwnam and getpwuid implementations still need the shared libraries. The needed libraries must be copied into the chroot because mysqld calls those functions after calling chroot. I’ve updated the mysql-chroot script accordingly.
(The rest of the chroot setup procedure still works as described in Chrooting MySQL on Debian.)

By the way, I’ve filed a wishlist bug at Debian’s BTS (#299265). mysqld should do all /etc/passwd lookups before calling chroot. That way chrooting would work without $CHROOT/etc/passwd and with copying any libraries into the chroot. That’s how Apache and Bind 9 do it.

March 17th, 2005: Debian has removed the -all-static flag again. I’m leaving the additional bits in the chroot script however, just in case the maintainers decide to add the flag again.

<VirtualHost 127.0.0.2:80>
        ServerName JustForOpeningSyslog
        Redirect permanent / http://127.0.0.1/
        ErrorLog syslog
</VirtualHost>

Now apache calls openlog(3) with LOG_NDELAY before being chrooted by libapache2-mod-chroot, and libapache2-mod-php4’s syslog(3) calls work just fine.
(Idea stolen from syslog(3) and chroot(2).)

But I’ve found no guide for chrooting MySQL, so here’s my short recipe:

• Prepare the chroot directory. It’s recommended to use an extra partition/filesystem for it. I will use /srv/mysql (which is an LVM2 partition with an ext3 filesystem on my system) for the rest of the text.
• Stop MySQL:

  /etc/init.d/mysql stop

• Copy the databases to new location:

  mkdir -p /srv/mysql/var/lib
  cp -a /var/lib/mysql /srv/mysql/var/lib

• Copy this script to /etc/default/mysql-chroot
• Edit /etc/init.d/mysql:
  • Source the mysql-chroot script somewhere at the top:

    …
    test -x /usr/sbin/mysqld || exit 0
    
    . /etc/default/mysql-chroot
    
    SELF=$(cd $(dirname $0); pwd -P)/$(basename $0)
    …

  • Run setup_chroot right in the start section:

    …
    if mysqld_status check_alive nowarn; then
      echo "...already running."
    else
      setup_chroot
      /usr/bin/mysqld_safe > /dev/null 2>&1 &
    …

  • Somehow /var/run/mysqld/mysqld.pid disappears after each start. We have to create it each time, otherwise the stop command won’t work properly:

    …
    if mysqld_status check_alive warn; then
      echo "."
      ln -sf $CHROOT_DIR/var/run/mysqld/mysqld.pid \
                     /var/run/mysqld
      # Now start mysqlcheck or whatever the admin wants.
      /etc/mysql/debian-start
    …

• In /etc/mysql/debian.cnf, change the socket line to:

  socket = /srv/mysql/var/run/mysqld/mysqld.sock

• In /etc/mysql/my.cnf:
  • Change the socket line in the [client] section to:

    socket = /srv/mysql/var/run/mysqld/mysqld.sock

    Don’t change the socket lines in the other sections!

  • Add

    chroot = /srv/mysql

    to the [mysqld] section.

• Prepend /srv/mysql to the log files listed in /etc/logrotate.d/mysql-server
• Start MySQL:

  /etc/init.d/mysql start

• Check /var/log/syslog for errors ;-)

March 13th, 2005: I’ve updated the script for newer Debian packages, see Updated MySQL Chroot Script for more information.

July 30th, 2006: These modifications still work fine on the current stable Debian release (3.1, “sarge”). The mysql packages in the testing (“etch”) and unstable (“sid”) distributions of Debian need a few additional changes, I’ll post an updated guide in a few days.

December 30th, 2006: I’ve made an updated guide on how to chroot more recent MySQL packages on Debian and Ubuntu

The Limit action can be used to limit accepted connections per IP and timeframe. The hardcoded limit currently is 6 connections per 60 seconds. If an IP tries to connect more often, the attempts will be DROPed.

The Whitelist action provides some simple port-knocking whitelist. If you know the WHITELIST_PORT and can lift the limits imposed by the Limit action for your IP and 60 seconds by connecting to that port.

Here’s how you can integrate those two actions:

• Create two empty files:
  • shorewall/action.Limit
  • shorewall/action.Whitelist
• Copy Limit and Whitelist to the shorewall directory
• Add Limit and Whitelist to shorewall/actions
• Set WHITELIST_PORT in shorewall/params
• Use Limit in shorewall/rules, for instance:

  Limit:ULOG:SSH    net  fw  tcp  ssh
  Limit:ULOG:IMAP   net  fw  tcp  imap,imaps
  

  Note: You must use the <action>:<log>:<tag> format for the rules. Limit uses the <tag> for the ipt_recent table name.

• Optionally add a Whitelist rule:

  Whitelist:ULOG    net  fw
  

If you’re running OpenSSH 3.9 or later, you additionally might want to set MaxAuthTries to 1 (see sshd_config(5)).

May 9th, 2005: I have found a bug in the ipt_recent module, see this article for more information and a fix.