Sunday 30 December 2007 @1:02
Yesterday was a bad GNU/Linux day. I was getting angry, and I rarely get angry. Every once in a while, I type “apt-get upgrade” and everything goes to hell. Like the print server’s ability to print from PDF. Right when I’m trying to print last-minute boarding passes, confirmation pages for hotels and rental cars, directions from the airport, etc.
I of course found workarounds, then in some cases had to work around the workarounds. But in all it took about 3 hours to figure out what was going on and get 10 pages printed. Something was broken in how CUPS talks to ‘pdftops’, causing it to hang. There were recent security updates to CUPS, but when I downgraded it, the problem persisted. It’s still not fixed, but I found and subscribed to a probably-relevant entry on bugs.debian.org.
I guess I use Debian ‘stable’ so that this sort of thing happens very rarely. The frustration had me questioning my commitment to GNU/Linux and other free software. But of course it’s not that simple: what I treasure is the hackability, and so some instability is inevitable. Even on a Mac, I’m likely to access unsanctioned functionality with “sudo vi /etc/cups/cupsd.conf” or whatever, but this kind of customization rarely survives updates.
I suppose the solution is to take updates more seriously, evaluating them the way a business would: apply them only when there’s sufficient time to run a systematic set of regression tests.
Tuesday 10 July 2007 @11:38
Over the past few days, I’ve been cleaning up compromised web sites that run PHP-based content management systems. This got me thinking (not for the first time) about the sad state of CMS security.
One of the key problems is that CMS software is not always treated with the same level of care as regular system software. As with any net-facing software, flaws must be carefully tracked and patches swiftly applied. This is tricky because CMSs are not always installed using the regular package administration system; often they are uploaded into the public_html spaces of regular users.
But I want to address an underlying problem that has more to do with the design of these systems themselves (which of course impacts their suitability for packaging and maintenance in something like the Debian archive). In my experience, many content management systems jumble together the following kinds of files and code that should — following the principles of least privilege and privilege separation — be kept distinct:
- Data files or scripts that should directly correspond to URLs.
- Data files or scripts that are merely included or opened from other files, and therefore should not be reachable from any URL.
- Code that needs privilege to write to the file system or database.
- Code that merely needs read privilege.
- Directories in which the code can create and modify files.
- Writable directories whose contents are accessible as URLs.
- Writable directories accessible as URLs, in which script extensions (.php, .cgi, etc.) are honored.
The astute reader should be able to deduce the security implications of each of the above, but here are some hints. Web-accessible library code increases the surface area for exploits. Writable, web-accessible directories invite spam content. Writable, executable, web-accessible directories are havens for malware.
Keeping these categories distinct would not just increase the baseline security of the CMS, it would also improve usability with other tools like chroot jails and suPHP. The latter provides privilege separation by executing scripts with the privileges of their owner rather than the web user (www-data), but of course that requires spawning a new process for each request. One of the reasons that PHP (and later, Python) proliferated in web applications is the lower overhead of running the interpreters as modules within the web server. By isolating the bits of code that need write access, one might achieve a better compromise of efficiency and security.
I understand that a reason for flouting security conventions (apart from ignorance) is ease of installation. Content management systems are often set up by naive users over FTP connections to unprivileged accounts on shared hosts. But I believe it’s entirely possible to design the system more securely for expert users or site administrators, while still allowing naive users their (more vulnerable) one-click installs. Pay-as-you-go security. The content management systems that do get packaged for Debian are usually configured in a pretty reasonable way, but it’s telling that the worst offenders don’t get packaged at all.
link
Filed under 
