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.
why is it that when there's a Microsoft security issue, the title of the story is always a statement while when someone posts an article about security problems in linux or other major open source applications, it's always a question or doubting statement?
Dunno whether the author of the article missed it, or whether the postinst was changed again, but I'm pretty convinced that this point is invalid.
--
this post was brought to you by Andreas Fuchs.
this post was brought to you by Andreas Fuchs.
echo [Address] | sed s/[-a-z]//g | tr A-Z a-z
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
The author of the article claims a lot of packages (he mentions apache and proftpd) are out of date, while he didn't realize that Debian 2.2 was frozen months ago. This means that at release, packages are dead-stable (they wont crash) but might have a few holes in them by now. And, as another poster pointed out, backfixes do exist.
Ivo
<grub> Reading
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.
Group writable home directories: Debian uses "user groups", where every user gets their own group. This makes working on shared projects (in a +s directory) slightly easier, since your umask is 002. However, since nobody is in your group by default, your home directory and files there are as secure as if they were only user writable. This is configurable in /etc/adduser.conf, and if it is set to no, Debian's default login scripts do the correct thing and set your umask to 022
This is the stupidest idea continually propagated by us geeks. I'm not flaming here!
Why should I have to continously check every new phrickin' software product I install for security problems?
This is analagous to everytime I buy a car, I've got to get under my car and inspect it's braking system, it's steering system, it's fuel system, etc. so the damned car doesn't send me and my family careening over a cliff or exploding on us.
For God's sake, this industry has GOT to start getting things right BEFORE they phrickin' ship. We need a Consumers Reports or UL type-testing system so the software user can reasonably expect they're getting a quality product.
Passing testing security off to the user is lame, lame, lame.
EMUSE.NET
"We're sorry, but the website you're trying to reach has been disconnected."
First thing I do when I install a new dist is go in and fix the default brain damage -- disable all servers (Bind, sendmail, Portmap and FTPD being absolutely evil in my book) install some secure stuff and continue. Now a newbie woudln't know to do this but a newbie won't be able to keep his system secure anyway. Which brings me to point two.
About half the stuff he gripes about assumes you have users. For most Linux installations, if you hand out accounts, you may as well be handing out your root password. Do this sometime: "find / -type f -perm +6000 -exec ls -al {} \;" and count up the setuid files. Now ask yourself how many of them NEED to be setuid. How did you do? Half? Less than half? Distributions hand out setuid bits like haloween candy. Does all that crap need to be setuid? NO! And if you're wondering why setuid bits are bad and you've handed out accounts on your system, you've probably already been taken over.
Re: Netscape: I always turn java and javascript off by default. Not only do I not trust the langauges, but the browser is much more stable without them (Especially Java. Netscape with Java enabled is satanic, really.) 'Course I've pretty much completed my transition to Mozilla, too (With Java still turned off.)
Re: Dpkg: Cryptographic signing would be nice. Probably take less time to add than it did to write this article (Or this post for that matter.)
As for physical access, if you really want to be sure, install encrypted filesystems, because if someone's broken into your house or office with the intent to rifle through your computer, he'll have brought a boot disk and a screwdriver so he can jumper your bios back to its default settings, too.
Personal quibble, chmod go-rwx /home/username? What UNIX god doesn't use the octal numbers, saving themselves 3 keystrokes (chmod 700 /home/username) in the process?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
(1) "Defaulting to one partition."
Last time I installed Debian, I had to use fdisk to set up partitions, but maybe I just selected the advanced option. I dunno.
Anyway, unless the machine is a remote syslog server, this opens you up to (at most) a "local denial of service attack". And the only way to deal with those is with a baseball bat.
(2) Crypt instead of MD5 passwords.
The only advantage MD5 has over crypt is that you can chose passwords with more than 8 characters, and a larger salt to make dictionary building harder. Lousy passwords are lousy passwords, no matter how you hash them. And good passwords (8 characters, including non-alphanumerics) are good, even when they're hashed with crypt.
(3) Services in inetd. (discard, daytime, rsh, etc.)
Yeah, these should probably default to off, but none of them are security problems in and of themselves. It'd be nice to ship with openssh, but they can't do that until Sept. 20 when the RSA patent expires.
(4) dpkg not able to check signatures.
This is your one legitimate point.
(5) Home directories world readable, umask 022.
No real security problem here. If a user wants to hide something from prying eyes, they should learn about permissions, or better, how to use cryptography. In general, you shouldn't expect anything on a multi-user system to be private.
(6) LILO.
To "exploit" this, you'd need physical access, at which point the attacker could just as well boot off a floppy. If an attacker has physical access, the game is over.
IMHO, they shouldn't have even bothered with using "sulogin" when entering single user mode.
(7) Apache and ProFTPD versions.
Okay, Apache could stand to be updated, but the cross-site scripting hack is hardly a major security problem.
And your statement about ProFTPD 1.2.0pre10 being exploitable is just plain false! It's ProFTPD 1.2.0pre8 and earlier that have known root exploits.
IMHO they should be using the OpenBSD ftpd by default, but at least it's not wu-ftpd ("Providing remote root since 1994!"), which is the default ftp daemon on RedHat.
In general, I've found that Debian releases security patches just as fast as RedHat and SuSE, slightly quicker than Mandrake, and way quicker than Turbo and Caldera, which run about a week behind.
And the convenience of apt makes getting the security fixes much easier than trying to find a RedHat mirror that's both up-to-date and not completely overloaded.
Because this is a serious site and if a title was posted such as "Microsoft security problem?", it would just be too funny to post.
ayottesoftware.com
Increasingly, the "average" user is using UNIX, or at least being exposed to it. The problem is... how do you learn something about UNIX, if you don't know anything already? As has been pointed out, documentation (installation guides, bug reports, security vulerabilities) are fragmented; quite frankly, there is no way that a new Linux user can set up a secure system, because existing distros are all installed with certain well-known insecurities.
If you think that's untrue, consider someone with a new computer and a copy of RedHat/Debian/whatever, who get's told that all this wonderful security information is available on the net. In order to gain access to it - and read about how to secure their system - they need to install an unsecure system. Of course, this isn't the reality of the situation - most new users aren't aware of security resources on the net, of course, and nobody thinks to mention them to newbies, because, after all, everybody knows about them, right?
If there was a bug in login that allowed someone to gain root access to your system if a common file (installed by default) existed in /etc, there would be no question - this is a security flaw, and it must be fixed. Saying "Everyone knows that's a problem - if you really know UNIX, you just make sure you remove that file after you do an install" wouldn't cut it.
The same holds true in this case; installing services - like sendmail - that have blatantly stupid default settings and open up a box to potential abuses, just because "everyone knows" that you need to change the default configuration to prevent it, isn't an answer. The systems should install locked down tighter than a miser's wallet, and require a user to gain knowledge in order to expose new capabilities.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
How much work is it to just update the package to the latest version anyhow? Sure, some things change, but when it comes right down to it, people want to look at a machine and say "Yes, I've got Apache 1.3.12, and I'm safe" rather than digging through the bug reports for obscure information.
It's VERY easy to update to the latest and greatest. The problem there is that then you'll be distributing reletivly untested packages with various unknown security flaws in them rather than one where you have patched against flaws in a well tested version.
In other words, updating a package (Debian or any other package) involves about 5% work to put the package together and %95 to make sure it's at least no worse than what you have, including broken dependencies, silent loss of data, and gaping holes in security.
Many people ALREADY perceive Debian stable to be out of date. They can either use another distro or load unstable (Currently Woody). Others use Debian stable in production because it is WELL TESTED. For a busy ecommerce site do you want the latest of everything, or proven reliable stuff that's a bit older?
Besides that, new versions come out DAILY! Nobody can release a new distro every day!
Thanks
Bruce
Bruce Perens.
Ok, well to start I have been running a server on the internet for 6 years and I admit that I am not always the best administrator, especially in terms of security updates. One of the risks of having an OS that can stay up for a year at a time is that you leave it alone since it is working. As time goes on and exploits are discovered it takes a special attention or a full time job to catch every security hole. As such one has to commend Kurt for making an effort to analyze security issues in ANY distro. As to his lack of understanding of DEBIAN's policy on backfixes, well perhaps it should be made clearer. I am a VERY experienced programmer and administrator in terms of Linux and I LIKE reading changelogs but I don't always get a chance to and a Novice is unlikely to know much about that. In any case Kurt made a mistake and he apologized gracefully, as opposed to the Debian response which was sort of harsh.
.99p16) there were good services available and THAT was why I began running it. Fear of being hacked was not what turned me on to Linux. it was the fact that I could take my little 386sx and make it a SERVER. SERVER implies SERVICE. Now I understand folks are trying to switch linux into a desktop machine, and for that maybe it is best to take on the macintosh model of NO SERVICES. Seems to me that could be a REALLY small distro compared to these massive cd sized ones. Even so eveyone wants a webserver, having your own nameserver is nice, a mailserver can be handy, an ftp server solves alot of problem, and hey its nice to have remote access, even if you jsut want your friend to help you on the machine, and so it goes.
That brings me to TWO points. Alot of this discussion has turned into "Everybody Knows" and people need to shut off everything in the machine to make it secure.
#1. If everybody knows, that implies a culture which doesn't accept newcomers with a proper sense of respect. We want new people to use Linux (supposedly) but then we say that it is ok to leave certain security holes because everybody knows to close them. That is nonsensical because what it implies is that the only important people to consider on these installations is experienced users, when a truly experienced suer is NOT the target of this sort of install. Infact one of the joys of Linux is that a really experienced user can make their own canned distro anytime they want, and can essentially fix the assumptions of a distro to their own desire. Yey... Newbies on the otherhand need alot of guidance, more than Linux or Microsoft give. My understanding is that Apple managed to make it so that one can turn on their G4 models with airport and run a webbrowser immediately. That is FAR closer to what newbies need. Closing off security holes as the first step is NOT.
#2. My father has been in the industry since the 60's and he basicly told me that the perfectly secure machine has NO access. Basicly on one side is the availability of services, and on the other side is security. the more services the less secure. People ehre are mandating locking floppy drives, welding shut cases, turning off services.
This is sort of ironic. Even when I started using Linux (Slackware with kernel
Before one evaluates security one needs to evaluate use, and while a distro can be helpful to give a new user an idea of the risks versus the benefits of any decision they make in terms of services and security, there is never going to be a hard enough solution to protect against local penetration, no matter what folks say. In circumstances where someone has physical access to a server even if one can't physically tamper with the machine, effective surveilance, keyboard taps, and any sort of wiretap on datalines makes true security difficult especially in circumstances where the average user STILL probably uses a variation of his/her kid's name as a root password. Or worst writes it down.
Linux has come a long way, and Debian, Redhat, Slackware, SUSE, and every other distro makes a competition of both features and philosophy that is so valuable to the community, that discussion of fragmentation has seemed to fall off in the last year. We can see that ALL Linux is growing, and we are indebted to all those who have examined security issues on EVERY package, every DISTRO, every OS, every kernel. However security is a wide scale and no system that runs power is truly secure. Lets just be thankful that we are talking about a system where users CAN learn to secure their system by themselves.
dlg