Slashdot Mirror
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?
Linux distros need to start making changes to there default install to a secure install. So people if people wants to use a service they have to turn on themselves.
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.
> Always do testing on your own.
I felt like repeating that bit. 'cos not many people do, and then they blame their tools when things go wrong.
And that applies to all systems of course though, not just Debian and not just Linux.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
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.
The main thing i thought (after reading the article) was that it's mostly right, as far as i know.
The package-signing thing has been bothering me as well.
But.
The example of rpm's package-signature checking gives an example of a better idea, but i don't want to think about what happens when the vendor key is compromised. If somebody has the key the rpm's are signed with, he/she can create a very real false sense of security ('the signature's right, so the package is 100% certain correct and secure, as well'), by applying the signature to altered/compromised packages.
The lilo-security thing seems a little farfetched to me as well. I didn't see a comparison with other distributions, and as far as i know, there are no other distributions that enforce a lilo-password.
Did he check the packages of wich you mentioned there was a security hole in them (proftpd, apache) ? A lot of debian packages (and these as well, afaik), are patched to fix those holes. Apart from that, Debian offers (fast) updates to vulnerable packages, in the form of a security.debian.org apt-rule, where fixed/patched versions are available.
From the article: >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!
I wonder if he actually checked all these 'more than a few daemons'. By my knowledge there are no publicly known vulnerabilities in Debian.
Some comments on the 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.
There is no such thing as a bug-free release. Debian has done a pretty good job in keeping their releases (including the latest one) secure. There is no software shipped in the last Debian distribution with the publicly known root hacks mentioned.
>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.
Adding security.debian.org in your apt-rules list works just fine. A lot of Debian maintainers fix security bugs in their packages, often before they become publicly known. An out-of-the-box Debian system will only have the security bugs that have become publicly known after its release date, and these can be fixed with the above-mentioned security updates.
>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 frustrat
>ing 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.
Debian is a distribution that _adds_ to the work other vendors do, making their distributions more secure. If he actually would would have taken a closer look (wich he obviously hasn't done), he would've seen there's a lot more work being done on the security of Debian than there's mentioned. The article shows some knowledge of security in linux systems, but also a very badly-informed, no-research, superficial look on Debian security issues.
First and foremost every linux distribution caters, or atleast claims to cater to a specific subsection of the linux population. If you want the most recognized linux distribution, with the one of the bigest installed bases out there you run RedHat. If you want a distribution that is as tight as a drum you apply Bastille Linux. If you want productivity suties cleanly integrated into your install process you run Corel Linux (which BTW is based on Debian.) If you feel like supporting User Friendly you run Suse. If you want a distribution that you know all the parts work well together in you run Debian.
The author of this article seems to lack an understanding of the Debian release cycle. Debian was frozen before several of the release he mentions came out. Once Debian has been frozen getting a new package into it becomes substanially more difficult. Now before everyone screams about how now that potato (Debian 2.2) is stable these fixes can't make it in, keep in mind that security fixes are one of the items on the very short list of packages that can be changed once a release goes stable.
Joe Homeuser most likely isn't going to choose Debian as his distribution. Most people who choose Debian do so because the support Open Source ideals to the extreme and as such have problem been around the Open Source block a time or two and atleast have some idea what they are doing.
Are these valid secutiry holes in potato? Yes! Should someone have written an article bringing them to light? Yes! Is this a big enough deal to warrant a Slashdot Story? No! It should be a quickie at best.
"You can't fight in here! This is the war room" --Dr. Stra
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."
Ok...the umask is permissive and user home dirs have read and execute bits by default. All this means is that users need to be carful. I have no problem with that....thats not a real security flaw. Its just something that the author doesn't like.
MD5/crypt passwords. Yup ok thats kind of a silly default these days. Of course IMHO crypt is good enough. An attacker practically needs to compromise root just to get the shadow file anyway!
Lilo is setup to allow command line options. Yea so? Doesn't that make sense after a first instal? Exploiting it requires physical box access, at that point 99.9% of machines can be compromised by throwing a root disk in the floppy drive and hitting cntl-alt-del anyway. Besides....after a fresh install you may want that, lock it down after its working right!
Face it....ANY system, out of the box, needs to be secured.
As for Apache....he complains that it being 1.3.9 rather than 1.3.12. Well Debian has been in freeze for a while. That means "NO NEW CODE", unless there is a security fix. Is that apache upgrade a security fix? If not, then its right to not ship it.
PROFTPd, no clue, would have to ask the maintainer as to why it wasn't done. A look at the Debian BTS shows a root compromise bug fixed...perhaps they just patched the problem in the old version. That way fixing the security issue without introducing any more NEW CODE than is absolutly needed (it was during a freeze).
This is probably the case for several other deamons. He should check and make sure that the system is actually vulnerable before he goes around reporting that it is. Of course without a complete list of which "insecure deamons" he found, its hard to refute is claim that there are "lots".
As for xchat...no clue. I don't use it. Looking through the bug report logs now, I don't see any bugs mentioning this, perhaps noone reported this bug that he is complaining about. He could I dunno, report the bug! What a concept.
> Debian has also ignored a lot of work other
> vendors have put into making their distributions
> more secure.
Eiither that or some author has completely ignored changlog files and bugreports...and feels the need to fault the system for not having the defaults that HE likes. Not like they arn't changeable.
"I opened my eyes, and everything went dark again"
LinuxPlanet has a pretty good article about the default security in all or most Linux distributions here.
It is about the lack of default security in most distros.
Why is it that most distributions isn't made secure by default? (like OpenBSD, which I have heard is pretty secure by default)
Is it convinience? (just turn on "everything", then the user don't have to bother with starting any services)
I know that you can choose the security level when installing the Mandrake distro - does anybody know how secure it is if you choose "paranoid" (the most secure), or which level you have to choose to make it pretty secure by default?
If the home dir is set to mode 711, and their web directory (public_html, or whatever your configuration calls for) is set to 755, you'll be fine.
--
The unsig!
Presumably, you trust your OS vendor. They have been granted an X.509 certificate for the server you're talking to, identifying your OS vendor as the people you're actually talking to. You can verify this by examining the digital signatures on the cert. It should be signed by a CA that you both trust. That's just something that can happen "automagically" with SSL, so long as the apps enforce "the rules".
--
The unsig!
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.
Bullshit!
I have never used Debian, but I run Slackware, Suse, Redhat, Solaris, Free|Net|Open BSD, HPUX, la la la.
But this article is full of shit. Default Installation is not a security hole. Calling / partiton
and swap partition a weakness cuz they are default is just wrong. Most people using linux today, are
single users. Anyone smart enough to be setting up linux for multiple users is usually smart enough
to partition the drives easily. The default password is crypt? How is this a security hole? This has
been the default, and I will really be ticked off if it was default of MD5 or some other better scheme.
Unless the Unix community adopts a new standard, crypt should remain the standard, Solaris, HPUX, they all
use crypt, not MD5. Default internet services are enabled, again this is nothing new, sure they should
be disabbled, but still, can this goon tell me the security holes in them? It is very amusing that he
mentions that gnuplot needs to be installed setuid root. Has gnuplot being audited for security bugs? How
can he make such stupid comments? First of all, there is X version of gnuplot, and I believe that is what
a user who needs to use gnuplot needs it for. No suid needed! Exim (if configured during install) gives
you the OPTION to use the RBL. What is the freaking problem? It gives you the option, if RBL is not working,
you have the option, and Exim is not debian. It is a package. Home directorys are mode 755 by default and
the default umask is 022, what again is the freaking problem? The only valid point I see him making is that
dpkg does not have a signing support. He blahs about LILO, if someone has physical access to your box, you are
owned!!! unless you are using crypto filesystem. Now, if he has bothered to check the CHANGELOGs he will notice
that security patches have been applied. This is a troll article.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
This is for zsh, but bash should work similarly, I guess. Put it into your global zshrc. (No, I didn't write it, I just "borrowed" it...). It doesn't solve all problems, but some of them:
umask()
{
if [[ $# -ne 0 && $PWD != ~/public_html* ]]; then
_orig_umask=$1
fi
builtin umask $*
}
umask 077
chpwd ()
{
if [[ $PWD = ~/public_html* ]]; then
umask 022
else
umask $_orig_umask
fi
}
Sure there is - you assume that your OS vendor knows what they're doing. Debian 2.2 was frozen for several months, during which they've had ample time to fix things. Unless you have reason to believe that they're incompetent, and in the absence of any security advisories telling you to upgrade a package, it's probably safe to assume that the problems have been fixed unless you have evidence to the contrary.
Now, in the case of somebody writing an article about a product, the onus is upon them to check their facts. The changelog is the obvious place to check them. What would you prefer Debian do?
The day will come when OpenBSD's default install will just be /bin/cat. Mark my words.
This is the exact type of nasty response that the Linux community is known for outside (hell, even inside) Linux circles. No matter how many times we all plea that people keep their cool, there's always someone who just can't resist blowing it.
Please, people, keep your cool when people say negative things about Linux stuff. I don't know why I'm saying it seeing as how very few people seem to hear it, but I'm saying it anyway. Maybe if some of us say it enough, the abrasive minority will start to listen.
You do all of us a disservice when you react like Ben. Yes, the review was misinformed. Yes, this Kurt guy didn't do his homework.
That's the press. If I had a dollar for every time I read a misinformed review of a Linux product, I'd have that MR2 Spider that I've had my eye on.
One day they'll "get it", but until they do we need to guide them a little. Flamage will get us nowhere. Be calm, and people will listen. We need to come out on top here, folks.
no offense, but I disagree with your signature.
Italian men as well as many europeans men carry large "wallets" that could be called purses by americans.
many english actually call a wallet a purse.
also, did you ever see the Seinfeld episode about the male purse?
Shouldn't assume no one will need help either; that's outright irresponsible.
The fact is, more users will need help than not for most situations. This isn't going to change in the foreseeable future. It's only responsible to set up the software to help the newbies by default, with an option to take off the "training wheels" for expert users.
Most coders seem to sometimes forget that we have a responsibility to our users to make the software as easy to use and learn as we possibly can. When we don't do this, we're screwing the vast majority of our users over big time.
----------
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
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
Never did I say Linux is user friendly, or that Linux is right for everyone and their mother.
/. is a mindless drone.
The fact of the matter is, whenever I visit my mother, I sill have to baby her through *Windows*. She can't install a single piece of software, she can't set up a ppp conection, she can't configure the zip drive she bought, nothing. She knows where to click to check her mail via telnet, and when I tried to convince her to use putty instead, she said her "mail wasn't on putty, it was on telnet". And my mother has four degrees.
As another example, I was down in the telecom office of my university yesterday, and listened to a conversation between a lady having problems with her campus dial in connection and a telecom desk operator. Aparently, when she dialed in, she was prompted for a "new password", leading her to believe her "hotmail and internet explorer been deleted, it was all just deleted". The telecom desk operator's only job was to collect payment, so she couldn't offer any sort of help. This lady was stuck in some sort of wonderland where she didn't understand anything.
I'm a firm believer that unix isn't right for everyone, just, as you can see from the above, that windows isn't right for everyone.
So next time don't put words in my mouth, thanks. Not everyone on
This sig is false.
I don't think *any* of it is extremely serious, but I do hope to see netscape and lilo fixed in the distro, as they are very commonly used by people. Overall, the author overreacted, but he did have a valid point or two.
Glad to see the hard working folks at debian are on top of it, though, and there is at least a reason behind it all.
This sig is false.
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!
Bugs arent features, see?
Try telling that to Micros~1.
"PROBLEM: Windows bluescreens when you do foo, bar, and baz. STATUS: This behavior is by design."
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
Thanks
Bruce
Bruce Perens.
Here is one of his articles that ended up in a printed mag. It discusses PAM and attempts to discredit shadowed passwords in the process. The information is misleading and inaccurate. The article sounds more like it was released from a marketing dept instead of a self-proclaimed security expert.
When he discribes limiting access to ftp, he is basically saying only a good password will limit who can access the system. What about, /etc/ftpaccess or /etc/login.access. Not to mention using tcp wrappers and /etc/hosts.deny.
When he discribes using limits on users, he tries to imply only PAM can do this. Yet he fails to mention /etc/limits. If you 'man limits', you will see the available options are EXACTLY the same the ones he mentions are in PAM.
I see Kurt post to a few security mailing lists, Suse , BUGTRAQ, Linux Security Auditing Project, Bastille, etc. For the most part, his posts are worthless. Claiming PAM is the greatest thing since sliced bread, flaming others for off topic posts, repeating well known information, etc. His new project, LSKB lacks any kind of useful information and is more of a waste of time than anything else.
I have no respect for him and try to ignore him as much as possible.
Go not unto/. for advice, for you will be told both yea and nay (but have nothing to do with the question)
A couple of weeks ago, I used Debian 2.2 to set up a test firewall at work. I'll try to summarize what I did.
This firewall is nowhere accessible through the Internet. One ethernet card is connected to the company Intranet, while the other just has a crosscable attached. Because of this, I wasn't very concerned about security. I wanted to practice a little by tuning the box.
(Why this firewall, you might ask? I figured we needed a setup to demonstrate to our clients that our applications will also work through a firewall setup. And I had nothing more important to do - being between 2 projects.)
When the installation program prompted me to allocate partitions, I opted for a root partition, a small /boot, and the second hard disk for /usr. (Nobody really tells you how to partition hard disks - that's why most newbies end up with a single partition.)
At the end of the installation, I was asked whether I wanted MD5 or crypt passwords. The dialog listed some of the reasons why I would want either one.
The default network installation did activate a couple of services like telnet (don't remember which ones), which I had to uninstall. For the builtin inetd services, I didn't even bother to deactivate them. (I'm not sure why I left inetd running. Probably because I wanted one service from the list.)
I did leave exim because I needed a way for the system to report what's happening. Unfortunately, this left a process listening on port 25.
I deactivated X (the PC had a lousy video card anyway).
I had to recompile my kernel in order to support IP forwarding and Masquerading. In the collection of packages I found mason, which is supposed to make it easier to configure a firewall.
I tried this, and I got a list of all the broadcast messages on the company network (quite a lot). I threw away all that junk, and started studying the HOWTOs. I ended up with a configuration that will forward 5 TCP ports (we have a couple of web servers listening on unusual addresses), DNS (for convienience) and ICMP (to facilitate network debugging).
The machine has a couple of services running that might reduce security: DHCP (to configure the client PC), squid and SAMBA (easier access from my own PC).
The bootup settings: no BIOS password (automatic reboots), but the LILO images are restricted (i.e., you need to enter the password if you want to pass options).
Finally, I had to set a few kernel parameters as mentionned by the HOWTO.
All in all, a pretty secure machine, at least from the network. I can't think of anything that would hold of a determined person who gets access to the console.
I can always close up the remaining holes if I want to, but I don't think anyone will try to break into the machine anyway.
All in all, it took 2 days to get everything the way I wanted (not only the security aspects). I learned a lot out of this and, most importantly, it was fun!
WWTTD?
Hmm... Internet Explorer has a minor bug that allows some users to view (not change, mind you, but view) contents on a select number of users hard drives. "The travesty! Has Microsoft no remorse! Clearly they don't test their products, and anyone using them from a security standpoint should be marked as a rat bastard!"
Debian is earmarked for possible security faults. "It's a shame, but I'm sure it won't happen again. Remember people, nothing is 'automagically' secure. Linux users are the cream of the crop, and a bug... well... I just don't believe it myself.
Sigh... when is Slashdot going to be seen as reputable? When they stop throwing a bias at everything involved with Linux.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
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
A newbie won't be able to keep a system secure, Windows or Linux. His best bet is to hop on a system you can't get back to like AOL, use a text only mime incapable mail reader and use mosaic. That would be a reasonably secure environment for a newbie.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Yah. Generally you WANT the owner of the home directory to be able to rwx in it.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Does a lot of talking make your system more insecure, or does it just make you feel insecure?
It is much safer to be frightened by talk and let the fear drive you to education than to wallow in ignorance.
Anyway, please check http://security.debian.org/ if you're using Debian.
Making a network more secure requires an admin to think of what could possibly happen in any situation. For example once upon a time in a land far far away, someone pondered:
"Hmmm, packet sniffers make it possible for someone else on a network to capture transmitted data."
"Waitasec, telnet is unencrypted! Everything is sent out in the clear."
"Maybe I should stop typing in my passwords via telnet to access a machine remotely."
The original issue arose because the article's author had seen security advisories about the versions included in the 2.2 release, and simply hadn't realized that the fixes for those problems had been backported. While it may show a poor understanding of the Debian distribution, it does not reflect poor administration practices.
*cough* *cough* hummmmmm ... heh.heh.he...bwahahahahahahahahaha!
RFC2119
What should I do fix the holes in the default installation?
The first thing you should do is subscribe to the debian-security-announce mailing list. That way you will be informed whenever a security fix is made available. (Don't worry, it's not often enough to flood your mailbox!)
The second thing you should do is make sure you fetch those updates. You can always get them by hand (the instructions are in the announcements made on the mailing list). An easier way, if your machine can reach the World Wide Web, is to use apt. Put this into the /etc/apt/sources.list file:
deb http://security.debian.org/ potato/updates main(Make any other changes to your sources.list at this time.) Then run apt-get update , and apt-get upgrade . You can run those commands any time you like, to get the most recent updated packages. Now that potato is stable, there will not be updated packages very often, but it doesn't hurt to check.
The third thing you should do is review what's installed on your system and delete anything you don't want. This is tedious and time-consuming. You also won't be able to make too many informed decisions at first, since you probably don't know what everything does yet.
I haven't installed the newest version of Debian from scratch yet (my Debian boxes are a couple years old), so I don't know how much "cruft" there is in the default tasks. But if it's anything like the previous version (slink) there's probably a whole lot of cruft.
So run dpkg -l | less and actually read through the output. You will probably see some things that look vitally important (like "dpkg" or "libc6"), some things that look terribly unimportant (like "bsdgames"), and a whole lot of things where you can't decide.
Start by removing all the things that you know you don't want. If this is your desktop system and it's behind a firewall, you probably don't need to run a name server or have the Apache web server development kit installed... on the other hand, if this is your firewall, you probably don't want xbill installed. ;-)
Once you've done all of those, take a look at some of the individual packages. You can use "dpkg --status packagename" to see all the meta-information about the package, including its long description. (You can also see this in "dselect" if you use that program.) Then try removing some of them. Remember two things here:
The fourth thing to do is to look at the system from the outside point of view. Try port-scanning your box from somewhere else on your network (another Linux box running nmap is a good way). If you see a port that's open, find out why. (Hint: lsof -i :25 will show you the processes listening on port 25. Or, fuser -n tcp 25 will give you the process numbers, which you can then look up with ps.)
At first, you may not know what each of these services is, so you'll have to do some research to figure out whether you want to keep them. Find people you trust and ask them, or hit the docs.
When you find services you want to disable, find out how to do it. The methods vary with the service -- some services run as a standalone process (like sshd on tcp port 22). Some run under the control of inetd (like telnetd on tcp port 23). Some may run either way, depending on which program is implementing that service and how the program's configured. (E.g., sendmail runs as a standalone daemon and offers smtp service (tcp port 25), whereas qmail-smtpd could run from either inetd or under control of a separate program called tcpserver.)
Each service is different, so you will have to do some investigation to figure out whether you want to disable them, and if so, how to do it.
By the time you've done all that, you won't be a newbie any more. ;-)
The fifth thing you should do isn't specific to Linux or Debian. You should make regular backups of your important data. I'm constantly amazed at how many people fail to do this. The most important things to back up are your personal data (/home) and your system configuration files (/etc). (Note that Debian policy requires all configuration files to be under /etc.) If you've got more room, you should probably back up /var and, if you use it, /usr/local. If you still have more room, back up the whole file system hierarchy.
Also, make sure you have more than 1 backup. Don't just reuse the same tape every time -- have at least two tapes (or Zip disks, or whatever) and alternate between them. Better yet, have a lot of them and rotate them (use the oldest one each time). If you're doing this on an important system (not just your personal toy), you should ship some of those backups off-site in case of a major disaster.
Can you name the things that I need to change passwords on?
There isn't anything you need to change passwords on -- but you might want to set a few passwords.
Your user accounts (most especially root!) should all have good passwords. That's absolutely essential.
Beyond that, it depends on how paranoid you are, and how much the data on your system is worth to an attacker. It will also depend on external factors (e.g., is the computer locked in a room to which only you and your boss have keys?).
You can set a password in LILO (assuming you use LILO to boot), which will prevent users from passing boot parameters to the kernel. But in order to pass boot parameters to the kernel to LILO in the first place, they have to be physically present at the keyboard, and they have to be able to cause the machine to reboot (e.g., by disrupting its electrical power).
A user with physical access to the machine has other options, however, besides LILO. They could insert a floppy disk and cause the system to boot. You can prevent this by telling your computer not to boot from floppy diskettes (in its BIOS), and then setting a BIOS password which prevents the user from changing the BIOS back to its defaults. (This has nothing to do with Debian or even Linux.)
The problem with this is that it's still possible to override the BIOS password, either by changing a motherboard jumper, or by temporarily removing the battery, or by stealing the hard drives. This requires access to the inside of the machine, which is why some people here have been talking about locks on the computer's case.
Personally, I don't bother with any of that stuff. If a system has to be secure against the kinds of things discussed in the preceding few paragraphs, then it should be in a secured room.
You have hit on one of the few problems with Debian. Stable is too darn stable, and unstable sounds bad.
Personally I simply run stable with a few packages from unstable (PostgreSQL for one) that have packages that I know are solid upgrades. This sort of thing is trivial to do with Debian Linux. It involves changing one line in /etc/apt/sources.list and then run apt-get update apt-get install and then changing /etc/apt/sources.list back.
The Debian project is also adding yet another distribution that will be somewhere in between stable and unstable.
I can understand your response to Debian backporting patches. I mostly agree. It would probably be easier for all concerned (less wasted effort) if they just upgraded to the newest stable version. As for Debian developers telling someone to "piss off" when they find a bug in unstable, clearly you have never used Debian, nor their bug tracking system. Most developers actually use unstable, and they are VERY interested in making sure that it works.
It's nice that he apologized (just about unheard of kind of apology for a journalist) and that he posted a response to his website, but why not include it at the beginning of the article? It seems to be a sidebar (which looks enough like regular sidebar crap to be ignored by users) and the article has been just about untouched. Doesn't seem right to me. Nevertheless, still nice he apologized.
icqqm [ICQ:11952102]