article will surely annoy many
Here is an article I found today, I suspect this will get everyone going
one way or another.
It does certainly raise questions.
SecurityPortal Aug 30, 2000
About Us Feedback
options SUBSCRIBE to our
. Ask Buffy
. PGP ADK Bug
. Personal Firewalls
. Prevent Loss Top News
. All Security
. Linux Security
. Microsoft Security
. Virus Security
. Security Press Releases Features
. Cover Story
. Kurt's Closet
. Weekly Digests
. Top Twenty Virus
. Feature Archives
Get SecurityPortal To Go
Secure your site with VeriSign today!
Kurt Seifried (firstname.lastname@example.org) for SecurityPortal
Subscribe to our weekly newsletter
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
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.
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
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
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
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
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:
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:
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".
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
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!
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.
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@example.com) 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.
Top 20 Virus Report
SSL Server Security Survey
NAI: W32/NewsTick Virus
ComputerWorld: Federal agencies face grading on security readiness
Print this article
SecurityPortal © Copyright 1999,2000 Security Portal, Inc. All rights