Hey Fellas, I noticed this posted on slashdot, this bloke seems to make some valid points, In my mind Debian is still the best distro however I consider this constructive criticism.
Regards, Peter Firmstone N.B. Please don't flame the guy, he's got balls to post this but if its true he's doing us a favour in the long term. If we as users can get in and assist the developers in any way we can it should help make their job's easier, remembering they volunteer their time, and do a damn fine job too! (taken from http://securityportal.com/closet/ ) August 30, 2000 - I wanted to write a really positive article about Debian 2.2, which was just released a few weeks ago. Unfortunately, I can't. While Debian itself is a reasonably well-done Linux distribution, it has some major security issues. Before you flame me, please read the entire article. I realize there are a lot of nice things about Debian, but I've also found a lot of problems. The odd thing is that Debian seems to have gotten the niggly little details right, but there are major issues they haven't addressed. Default Installation I did several installations, and I can safely say I don't terribly like the defaults Debian uses. The first thing I noticed was that while formatting the disk, Debian defaults to an enormous / partition and a swap partition. Unless you use quotas, a user can easily fill up the disk (/home/username, /tmp, /var/spool/mail/username, etc.). While a certain percentage is reserved for root, that doesn't help other users much. Admittedly, most distributions (or operating systems in general, for that fact) don't do a great job of this. But there are a few, like Red Hat, that do. The next default that really ticks me off is the password encryption scheme - the default is to use crypt. You can also use MD5, but there is a warning about compatibility. crypt passwords are trivial to brute-force when compared to MD5ed ones. Debian now uses PAM. Causing problems is relatively rare, unless you have some truly ancient software with no PAM support. Moving on. Once the basic install is done, you will discover that several services are enabled in inetd that shouldn't be. Discard, daytime, time, shell, login, and exec (r services) are all enabled by default, few of which (none, in my opinion) are needed on modern systems. You definitely want to disable these by commenting them out in inetd and restarting inetd or rebooting the system. If you need to test connectivity, use ping; to synchronize clocks, xntp; to use r services, install OpenSSH or SSH and use the secure replacements. Some minor points of light: gnuplot needs to be installed setuid root for users to use console SVGA - the default is no. This is good, since any users that need SVGA are local and can probably be trusted (they have physical access, after all). Remote users do not need it. Exim (if configured during install) gives you the option to use the RBL (Real-time Blackhole List). Unfortunately, it looks like RBL has not been working properly since August 10th. The config also prompts you to set the user account that root's email will be sent to, generally a good idea. General Problems dpkg - My main beef with dpkg is the lack of package signing support. Unlike RPM, dpkg does not support the signing of packages with GnuPG or PGP. This is important, since verifying the software you are installing prevents people from getting you to install Trojan horses. As an example, the ftp site ftp.win.tue.nl was cracked into some time ago, and several packages were replaced with Trojaned versions. TCP_WRAPPERS was compromised, among other things. Over 50 people downloaded these packages before someone noticed they were not properly signed with PGP, and raised the alarm. MD5 signatures can be used, but the attacker will modify those if possible, so you must somehow get the MD5 sums from a trusted host (https:// for example). This is extremely impractical and generally a pain for most users. OTOH GnuPG-signed RPMs are simply verified with "rpm --checksig," and the public key for the vendor only needs to be downloaded once. It is far from difficult for an attacker to hit your DNS server and poison it, i.e. pointing ftp.crc.ca to the IP of a server they control. Then, the next time you upgrade or install packages, you get modified software which lets the attacker take over your machine remotely. They can also simply break into an ftp server and replace the packages. Chances are they would not be discovered for some time, and even when they are, contacting all the people that downloaded software is a difficult task. Hopefully, dpkg will be changed in the near future to support signing of software, especially with GPL-licensed software such as GnUPG now available. Home directories for users in Debian are by default world readable and executable (to change into a directory, you need executable permission). This is a very bad idea. It is made even worse by the fact that the default umask is 022. This is the default in most other distros as well, but because the home directories are world readable, any file a user creates (say "emacs personal-notes.txt") will be world readable by default. Any user on the system can read any other user's files. If something like a Web-based cgi is setup improperly, the attacker would be able to view any user's files. The default in Red Hat, for example is to set the user directory so only the user can read, write or execute it. The group owner and other (i.e. anyone else) has 0 permissions and cannot get in at all. The best solution for this is to secure the user directories with: chmod go-rwx /home/username The user can also do this on their own, since they own the directory. Note that this will break the default http://www.example.org/~username/ behavior of Apache; the default directory is /home/username/public_html/. It needs to be world readable and executable, since Apache runs as the user nobody. Hopefully, Debian will issue an upgrade to adduser soon that addresses this. LILO is also configured very poorly. Despite the fact that Debian 2.2 specifies "sulogin" for single user mode, prompting a user for the root password is easily bypassed, by entering the following argument at the LILO command line: Linux init=/bin/sh You are conveniently dumped to a command prompt as root (just as the command "single" would if sulogin were not used). This is very sloppy. While Debian has gone to significant trouble to fix one problem (by installing sulogin), it is easily defeated. The addition of two lines to /etc/lilo.conf would solve the problem: restricted password=somepassword This is, of course, also useless if all Debian 2.2 machines have the same default password. During install the user should be prompted to enter a password for LILO, and the LILO configuration file should be protected from users (as it is in Debian 2.2). If you do choose to uncomment the existing password line, make sure you change the password from the default of "tatercounter2000". Daemons Apache - Why in the name of all that is holy did Debian ship Apache 1.3.9? 1.3.12 is out (has been for several months) and includes numerous fixes, some for pretty serious problems (like the cross-site scripting vulnerability). It's not like 1.3.12 is unstable or flaky. I find this odd, since Debian goes to the trouble of creating a "www-data" user and group to run the Apache server as. ProFTPD - They ship 1.2.0pre10, which has this annoying little root hack. Again, a newer version of ProFTPD has been available: 1.2.10rc1 (Release Candidate, i.e. the one you should use). It was made available on July 11th, just over one month before Debian 2.2 was released. This portion could be rather long, so I'll cut the list short. Debian has shipped more than a few daemons that have severe security problems, many of which were fixed well before Debian 2.2 was released. I find this unacceptable, especially in the light that Debian has not released any updates for these packages! Other Software There are also a number of other packages with security flaws and no updates available yet. Xchat, for example, has a well-known hole. Red Hat and Mandrake have issued updates; nothing from Debian yet. Netscape is currently up to version 4.73 on Debian, a minor problem when there is a serious bug in JPEG handling and a hole in the Java that you can march the Chinese army through. Unless you disable Java in Netscape, your Web browser can be turned into a web server by malicious Java code on a Web site. Most other vendors have issued updated versions. You'd think that now that 2.2 is out the door, Debian could focus a lot of activity on fixing it. Summary Debian's goal of a bug free-release hasn't been met. But to be fair, it's not like any software vendor will ever release bug-free software. Debian has done a particularly bad job in my opinion, shipping out-of-date software and especially publicly available network daemons that have root hacks in them. If you do go with Debian, you'll have a lot of manual updating ahead of you to bring it up-to-date and secure it. Unfortunately, the argument "apt-get, apt-upgrade" won't work, since many of these updates are not available as dpkg's yet. Debian has also ignored a lot of work other vendors have put into making their distributions more secure. If you don't learn from the mistakes and improvements of others, there is little hope. This is especially frustrating in light of Debian's effort to secure various parts of the distribution, using Exim by default instead of Sendmail. Having seen things like that during the install, I had a lot of hope for Debian, but my hopes were dashed to pieces upon closer inspection. Kurt Seifried ([EMAIL PROTECTED]) is a security analyst and the author of the Linux Administrators Security Guide, a source of natural fiber and Linux security, part of a complete breakfast. He will probably not respond to flame mail, so don't bother.
