Security Flaws on Slashdot
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 (seifried@securityportal.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.
Reply to: