Debian 2.2 "Has Major Security Issues"? UPDATED
If you would have bothered to check the changelogs for the packages you noted as having "root hacks in them", you would have noticed that every daemon you pointed out is not vulnerbale to the holes you point out. Here is a list:
apache (1.3.9-13) frozen unstable; urgency=medium
* [RC, security] Backported security fix for Cross Site Scripting issue
(CERT Advisory CA-2000-02) from apache 1.3.11 patch.
* Added default charset iso-8859-1 to initial configs.
* [RC, critical] Perl dependency reordered to "perl5 | perl", closes:
#61421, #62427, #60575.
* Postinst no longer complains on missing /etc/aliases, closes: #60575.
* Cron script detects logfile lines with whitespace, closes: #59995.
* Fixed apxs filename edited when enabling modules (missing /g in rules
sed); suppressed linking to -ldbm, closes: #53172.
* The apxs in apache-dev no longer needs apache binary, closes: #47221.
* Perms registered for suexec changed to 4755 from 4555, closes: #60147.
* Added text from beleagured Debian Webmasters to intro.html, making it
clear the project is not responsible for installations, closes:
#61414.
* LICENSE file of manual included since 1.3.9-1, closes: #42940, #60994,
#60995.
-- Johnie Ingram Sun, 16 Apr 2000 08:29:56 -0500
* Use setproctitle(%s,foo) in main.c, lamagra@DIGIBEL.ORG advisory.
-- Johnie Ingram Wed, 5 Jul 2000 18:50:07 -0500 As for netscape 4.75, it is *already* available in our potato-proposed-updates directory. Now I suggest you change the utter bullshit you have on your review to reflect the real information, and next time do some more digging before you make false accusations and spread misinformation like this.
From Kurt
Well, it looks like I made some significant mistakes in this article. I'm not a long time Debian user, so I am somewhat unfamiliar with it. It appears Debian backports fixes, and that Apache 1.3.9 and ProFTPD 1.2.10pre10 are not subject to the various vulnerabilities I mentioned. Unfortunately I did not read all the changelogs in question (in /usr/share/doc/*/). If I had, I would have noticed this.
Folks, I assumed (assuming is bad, I know) that Debian does updates like most distro's. I expected that if Apache 1.3.12 comes out with bugfixes, that they would issue a 1.3.12 package, not backport the changes to 1.3.9. I've also been writing a weekly Linux security digest for several months now, and while there have been Debian advisories regarding Potato, most of them mention the changes being merged in, rather than warranting a new release. I should have noticed that.
While RBL's failure isn't Debian's fault, my point is that they go to great lengths in some areas to make the distro "more secure", but are missing other very key elements.
I officially apologize to the Debian community, and am glad to have been made aware of an important point: Debian backports fixes, and it is necessary to read all the changelog files in question.
-- Kurt
Ex: Apache:
http://cgi.debian.org/cg i-bin/get-changelog?package=apache
IOTW - the security may not be perfect still, but let's not get carried away just because we're too damn lazy to read.
Nothing in that article really qualifies as a 'security hole' in Debian. And most of the things in the article are common to *ALL* distributions. LEt's look at them.
;)
- Single partition / for whole system as a *default*.
Well.. first, you *DO* have the option of changing this when you install. It's not an 'automatic' thing insomuch as windows does this automatically. And from what I know, most home users do this anyway Servers no, Home use, yes.
Crypt passwords (instead of md5) by default. HELLO.. the screen ASKS you what you want to use, and just happens to have 'crypt' already selected. And they *are* right.
Now.. basic inetd services (time, echo, discard). Yes, those of us security minded tend to shut these off.. however... I think it's common knowledge that the *FIRST* thing you do with a new distro is go in and disble these. I have yet to use a distro that doesn't put these in. And I'm unaware of any current (or past) security holes in the basic inetd services. These services are *internal* to inetd. If you are *really* worried about inetd's security, why not STOP RUNNING IT ALTOGETHER?
As for 'login' and such... see above. Commenting out inetd is standard pratcice. EVERYBODY knows that.
'gnuplot' is mentioned for some reason.. even though they install it correctly (as the article says).
And EXIM using RBL? What has that to do with security (whether or not RBL is currently working?).
Okay. Calling DPKG a security problem because it doesn't allow package signing? I'll grant that's kind of valid.. but how many signed packages are their in any other linux distribution? I don't believe I've ever seen even a single one! (in other words.. who cares if RPM can do this if nobody uses it). Oh wait.. you could always just INSTALL RPM!
The users home directory thing.. that's something to always check on every distro, because it's always different wherever you go. As the admin, if you don't like it, change it. Also.. the permissions suggested on users home directories lulls them into a sense of security
lilo doesn't use sulogin? C'mon.. if you are local, you can break in *anyway*. Lots of distros don't use sulogin, and nobody has a problem.
I have to catch a plane, so I can't get the rest of the article (There look to actually be acouple of valid thigns that could use patching mentioned).
But that whole first section of the article is just whining about settings not being exactly the way the author would have liked them,.
In order to be able to use "init=/bin/sh", one needs physical access to a machine (discounting the rather obscure case of having a serial console that's accessible via a network). With physical access, there is no such thing as security. Having a LILO password makes things slightly more difficult, but IMO that'll just give a false sense of security: think of booting from a different device, temporarily placing the hard drive in a different machine etc.
The author of the article should read the changelog for the proftpd daemon, for apache, and so forth. Debian has a tendency to backport security fixes instead of shipping the newest versions. I find that much better than always shipping the latest and greatest bugware. :)
--
"Rune Kristian Viken" - http://www.nwo.no - arca
Honestly, most of the author's nitpicks are small. Debian ships with the same kind of default settings as most Linux distros do these days, openings in inetd, one large / partition, some older apps with holes, and silly home directory permissions. Really not much a seasoned user can't handle; if you are the kind of user who just installs the default and leaves it, you probably shouldn't be using any sort of unix (or unix-like) system (maybe with the exception of openbsd, which happens not to work with my network cards).
The default crypt passwds, I admit, was kind of dumb, but it takes one command usually to change. Not a big deal. I don't get his beaf with dpkg not handling signing automagically; nothing stops you from signing it with gpg anyway and checking the sig by hand, or even writing the script to do it. Make dpkg do one little thing, and do it well; it might not need the kitchen sink welded on too.
I agree with him on two points, however: the improper lilo configuration, and the version of netscape that ships with 2.2. The default lilo lets you boot into single user root mode without a password, and the shipping netscape still suffers from the huge java hole. These are two very important pieces of software to most users, and might very well cause a lot of boxen to be compromised, so make sure you fix it.
Personaly, I think this attention will only make debian better for everyone. All in all, make sure you know what you are getting into when you install any distro. And subscribe to bugtraq.
This sig is false.
Man, that reporting was almost bad enough to be Jon Katz-level "quality."
;-). Note that several other security-minded distributions also enable them. Look at, for example, the OpenBSD default inetd.conf and be amazed at everything that they enable.
Let's see, defaulting to crypt is necessary for compatibility with NIS+. Note that Kurt's vaunted Red Hat gives you the choice of crypt as well....
r* services simply aren't enabled in Debian by default. I don't know what Kurt was smoking, but they're not. Time, discard, etc., are, but if you can't trust them, you can't trust inetd period (which isn't to say I don't comment 'em out anyway
RBL not working is a security hole? C'mon Kurt, if you don't like Debian, just say so. FUD gets you nowhere (though it does promote sales of your Red Hat-oriented books, I realize).
dpkg not doing GPG sigs is a problem. The new version does support it, and that'll be in the next release. In the mean time, there is MD5 sum checking....
Just because a distribution uses a different default permission set for home files than Red Hat doesn't make it insecure. It just makes it different than Red Hat.
I actually like the "prompt for password for LILO" suggestion. It's something no Linux distribution (including Kurt's vaunted Red Hat) does currently, but it's actually not a bad idea. Give the man one point.
Daemons: this point *could* have actually been valid, but if Kurt had bothered to do any research at all like a real journalist should, he would have discovered that Debian does not ship Apache 1.3.9. They ship 1.3.9 + backported security patches. Ditto for ProFTPD. The security hole he's claiming exists is a figment of his overactive imagination.
Similarly, contrary to his claims, Debian has released updates which upgrade to Netscape 4.75. Y'know, that's what apt-get upgrade is for.
Are all of Kurt's articles completely FUD like this one? I've never read him before, or even heard of him, but from what I've seen here, he seems rather clueless.... And I say that as someone who admins Red Hat for a living, not Debian.