Slashdot Mirror
Slashback: OpenSSH, Bio, Timeliness
Things that make you want to bring back thumbscrews. A few days ago, we mentioned the release of OpenSSH 3.3; compared to previous versions, the biggest change in 3.3 is increased emphasis on privilege separation. Today, Theo de Raadt sent word of an OpenSSH vulnerability being worked on by ISS and the OpenBSD team, details of which are expected to be published early next week.
In an announcement sent to bugtraq, he wrote: "However, I can say that when OpenSSH's sshd(8) is running with priv separation, the bug cannot be exploited.
OpenSSH 3.3p was released a few days ago, with various improvements but in particular, it significantly improves the Linux and Solaris support for priv sep. However, it is not yet perfect. Compression is disabled on some systems, and the many varieties of PAM are causing major headaches.
However, everyone should update to OpenSSH 3.3 immediately, and enable priv separation in their ssh daemons, by setting this in your /etc/ssh/sshd_config file:
UsePrivilegeSeparation yes
Depending on what your system is, privsep may break some ssh functionality. However, with privsep turned on, you are immune from at least one remote hole. Understand?
3.3 does not contain a fix for this upcoming bug.
If priv separation does not work on your operating system, you need to work with your vendor so that we get patches to make it work on your system. Our developers are swamped enough without trying to support the myriad of PAM and other issues which exist in various systems. You must call on your vendors to help us."
Theo emphasizes the role of vendor cooperation in making privilege separation work on the full range of systems on which OpenSSH runs. "If the vendors don't start pulling their part," he says in an email, "by the time the bug is posted their customers will be left unprotected. These vendors who do not do the right job and instead just 'sell sell sell' are starting to become annoying. On a lot of systems today, privsep does NOT work well at all. The vendors have not been helping!"
A patched version of OpenSSH could be released as soon as Friday, incorporating vendor patches received by this Thursday.
Read More on Stallman. Vamphyri writes: "Sam Williams, author of 'Free as in Freedom', biography of GNU/Linux founder Richard M. Stallman has gone live with the online free version 1.0 of FAIFzilla.org. The paper pulp version publishers O'Reilly & Associates agreed under the terms of the GNU Free Document License and have their own version up at their site. Williams' site allows for content and corrections to be submitted by readers. He hopes for contributions to be included in later editions of the O'Reilly bio. Also: CGI coders wanted for site enhancement, paragraph and line numbering, searches etc. Maybe a CVS Tree is in order? :)"
"Urpmi Norton" doesn't work for some reason. MrResistor writes "Upon logging in to my computer at work this morning, I was greeted by a virus update notice from McAfee SecurityCenter. The update for today includes W97M/Melissa@MM, and of course McAfees newly manuf^H^H^H^H^Hdiscovered threat, the W32/Perrun JPEG virus (which was also highlighted in yesterdays update). All of the updates in the last week or so have been rated Low or No Threat (except for Perrun, which is "Low On Watch". It seems that in addition to manufacturing new threats, they're also rehashing old threats to keep subscription renewals up. Perhaps it's time for Slashdot to add an Ethics topic?"
Ethics topic? I thought we had "The Almighty Buck" topic to take care of those pesky ethics...
---
I post links to stuff here
Since sshd is enabled by default in OpenBSD 3.1 (OpenSSH 3.1), and privilege separation isn't enabled by default, doesn't that mean OpenBSD 3.1 has a remote root hole?
With the recient Interview with the CEO of UnitedLinux and the following discussion of giving back to the community you can see how important this is. How many systems use SSH? Every single one of mine. This is where a UL can really shine, but helping OpenSSH in the shape of work towards a patch. This helps provide security to the distos and gives back the community for people who run smiliar setups.
This really shouldn't stop with SSH though. Distros in general should be helping out large development projects like this.
~Travis
UsePrivilegeSeparation yes
Read the rest of the config. READ, DAMMIT.
For linux users, you guys are outta luck. Contact your vendor for an rpm. Or, install the source to openssh by hand, and solve all the damn pam errors. We can cover you guys for a few days, so firewall behind a buddy with freebsd until you get this all rpm-happy.
Good luck.
I believe that the original poster was making a remark on the heralded "270,000 installations without a default-enabled root-level vulnerability" statement that OpenBSD uses. I don't use BSD, so I don't know the exact quote, but if the affected version of OpenSSH is enabled by default, this would jeapordize that tagline.
"How many others don't find the time for all these updates?"
What's so time consuming about 'apt-get update; apt-get upgrade'? Oh, wait...
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
After reading that post about OpenSSH, I
really do not understand how anyone could find
this guy difficult to work with.
This could be flamebait, but it should be said.
..
Consider this, would you rather use an Operating System, where the community just shrugs off the frequently once a week remote holes with simply, "go grab the updates"
.. or an Operating System where the community is surprised and in disbelief that a remote hole was found after 5 years which causes entire community to start bitch fights over the right to claim its the most secure Operating System still, despite the fact the remote hole was found by the Operating System developers, and fixed before it has actually been exploited.
You don't have to be Stephen Wolfram to figure this one out.
..There's a-dooin's a-transpirin'
"We won't tell you what the problem is, unless you're a big distributor."
Do you have some evidence to support this claim that they have revealed the exploit to big distributors? As far as I can tell they have told no one.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
The version I have been using claims it is the default (or its man page does). Perhaps you are right, I'm not familiar with previous versions.
Are you claiming that the man page is lying? :)
The upside is that they do tend to produce useful things, or have a salutary effect on those around them. So unless you disagree with what they do, you should simply dismiss their personal peccadilloes as the price you pay for having someone devote the majority of their brainpower to a single issue, and do useful work on your (and everyone else's) behalf.
Time to take a lesson from the PHB playbook - the natural response to an email like Theo's goes something like "Yeah, yeah, Theo, nice work. Keep it up. Oh, and have it done by the end of the week, willya?"
funny how this didn't make it into the main article:
We've been trying to warn vendors about 3.3 and the need for privsep,
but they really have not heeded our call for assistance. They have
basically ignored us. Some, like Alan Cox, even went further stating
that privsep was not being worked on because "Nobody provided any info
which proves the problem, and many people dont trust you theo" and
suggested I "might be feeding everyone a trojan" (I think I'll publish
that letter -- it is just so funny). HP's representative was
downright rude, but that is OK because Compaq is retiring him. Except
for Solar Designer, I think none of them has helped the OpenSSH
portable developers make privsep work better on their systems.
Apparently Solar Designer is the only person who understands the need
for this stuff.
"Looks like some folks are joining the ranks of Windows server users ;)"
Why? So that they can wait two months for a fix instead of four hours?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
From: Theo de Raadt [deraadt@cvs.openbsd.org]
/etc/ssh/sshd_config file:
Subject: Upcoming OpenSSH vulnerability
There is an upcoming OpenSSH vulnerability that we're working on with ISS. Details will be published early next week.
However, I can say that when OpenSSH's sshd(8) is running with priv seperation, the bug cannot be exploited.
OpenSSH 3.3p was released a few days ago, with various improvements but in particular, it significantly improves the Linux and Solaris support for priv sep. However, it is not yet perfect. Compression is disabled on some systems, and the many varieties of PAM are causing major headaches.
However, everyone should update to OpenSSH 3.3 immediately, and enable priv seperation in their ssh daemons, by setting this in your
UsePrivilegeSeparation yes
Depending on what your system is, privsep may break some ssh functionality. However, with privsep turned on, you are immune from at least one remote hole. Understand?
3.3 does not contain a fix for this upcoming bug.
If priv seperation does not work on your operating system, you need to work with your vendor so that we get patches to make it work on your system. Our developers are swamped enough without trying to support the myriad of PAM and other issues which exist in various systems. You must call on your vendors to help us.
Basically, OpenSSH sshd(8) is something like 27000 lines of code. A lot of that runs as root. But when UsePrivilegeSeparation is enabled, the daemon splits into two parts. A part containing about 2500 lines of code remains as root, and the rest of the code is shoved into a chroot-jail without any privs. This makes the daemon less vulnerable to attack.
We've been trying to warn vendors about 3.3 and the need for privsep, but they really have not heeded our call for assistance. They have basically ignored us. Some, like Alan Cox, even went further stating that privsep was not being worked on because "Nobody provided any info which proves the problem, and many people dont trust you theo" and suggested I "might be feeding everyone a trojan" (I think I'll publish that letter -- it is just so funny). HP's representative was downright rude, but that is OK because Compaq is retiring him. Except for Solar Designer, I think none of them has helped the OpenSSH portable developers make privsep work better on their systems. Apparently Solar Designer is the only person who understands the need for this stuff.
So, if vendors would JUMP and get it working better, and send us patches IMMEDIATELY, we can perhaps make a 3.3.1p release on Friday which supports these systems better. So send patches by Thursday night please. Then on Tuesday or Wednesday the complete bug report with patches (and exploits soon after I am sure) will hit BUGTRAQ.
Let me repeat: even if the bug exists in a privsep'd sshd, it is not exploitable. Clearly we cannot yet publish what the bug is, or provide anyone with the real patch, but we can try to get maximum deployement of privsep, and therefore make it hurt less when the problem is published.
So please push your vendor to get us maximally working privsep patches as soon as possible!
We've given most vendors since Friday last week until Thursday to get privsep working well for you so that when the announcement comes out next week their customers are immunized. That is nearly a full week (but they have already wasted a weekend and a Monday). Really I think this is the best we can hope to do (this thing will eventually leak, at which point the details will be published).
Customers can judge their vendors by how they respond to this issue.
OpenBSD and NetBSD users should also update to OpenSSH 3.3 right away. On OpenBSD privsep works flawlessly, and I have reports that is also true on NetBSD. All other systems appear to have minor or major weaknesses when this code is running.
(securityfocus postmaster; please post this through immediately, since i have bcc'd over 30 other places..)
IT WORKS BOTH WAYS.
i'm assuming you read the article by McAfee a few days ago describing their in house team developing JPEG viruses didn't you?
find proof of no proof before posting about lack of it.
MARIJUANA, SHROOMS, X: ONLINE?! - E
LSH (http://www.net.lut.ac.uk/psst/)
I love SSH. It's been installed on my boxen (regardless of OS) since it was stable enough to kill off telnet.
My problem with both the announcement as well as the patch is thus.
1. Theo nor any of the posters I've seen are willing to tell us what the hell is broken. Only that we must upgrade. That just don't cut it, I won't blindly patch without an idea of what is broken. The Debian security release summed it up best.
"Theo de Raadt announced that the OpenBSD team is working with ISS
on a remote exploit for OpenSSH (a free implementation of the
Secure SHell protocol). They are refusing to provide any details on
the vulnerability but instead are advising everyone to upgrade to
the latest release, version 3.3.
This version was released 3 days ago and introduced a new feature
to reduce the effect of exploits in the network handling code
called privilege separation. Unfortunately this release has a few
known problems: compression does not work on all operating systems
since the code relies on specific mmap features, and the PAM
support has not been completed. There may be other problems as
well."
2. Sudden, lack of belief in Full disclosure. Am I the only guy who remembers the days before full disclosure? The OpenBSD Security policy ( http://www.openbsd.org/security.html ) is pretty point blank (to quote)
"we believe in full disclosure of security problems. In the operating system arena, we were probably the first to embrace the concept. Many vendors, even of free software, still try to hide issues from their users"
I think posting a "fix" (ok, workaround) and not telling anyone *why* they should use it is "try[ing] to hide issues from their users"
I'll be firing up R.A.T.S and checking out LSH ( http://www.net.lut.ac.uk/psst/ ) (GNU'd SSH2ish) for my needs from here own out.
and yes, this needs a rant tag and yes I know the OSSH and OBSD teams are seperate, but they share enough philosophy and team members that I gather they have the same opinion on security.
Bugs Bunny was right.
replying to yourself is always a bad thing, but here goes...
if you cut through the bullshit (theo certainly has an interesting way of putting things), what he's saying is this:
there's a hole in sshd. we are working on a patch. if we release it now, you are all f'd, because all your systems will be compromised before you have time to patch them. we are giving you the next week to update your sshd, so that you are no longer vulnerable when we publish the bug+patch. yes, the new sshd has the bug, but is not vulnerable to it. if we fixed it now, the black hats will diff the results and be able to develop a compromise, and you still won't have a patch. oh yeah, we need your vendors' help so that you're all safe by next week.
make sense?
If and only if someone has made up the deb. And then it isn't compiled from source like /usr/ports on your machine.
Comparing it to Windows will be a moot point, since El Dorado is going to have a 40% larger code base than XP.
There is a /usr/ports movement on debian. Try it is is better. make. make install.
Comparing it to Windows will be a moot point, since El Dorado is going to have a 40% larger code base than XP.
It is the default. Since version 3.3.
So, is this another incompletely researched, uniformative exploit report? Where's the "patch that fixes nothing" for the exploit? Isn't that how ISS does business?
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
"Read it; you might need to pass the word on to your vendor, too."
If you need to pass the word on to your vendor you need a new vendor.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Yes the first Apache chunked encoding exploit released by Gobbles was targeted at OpenBSD. Grants you remote access but not root. To get root you still have to run a local kernel exploit. But Apache is not enabled by default in OpenBSD.
There has to be a more mature approach to vulnerability disclosure. We can't always just disclose a serious vulnerability without a fix available in place, especially if it involves a large number of systems.
I think Theo and the OpenSSH team are being responsible, and it shows that they've grown up. The right approach should be to disclose to the appropriate parties first, get a fix done QUICK, and then followed by a full disclosure.
Full disclosure at the premature time is naive and only leads to wide-scale insecurity, NOT security.
Well I just spent a few hours upgrading a handful of openssh installs and firewalling about a dozen others. This is weird though, is there NO other information about this hole except that it's "fixed" by 3.3?
If I have ssh blocked in /etc/hosts.allow, does that stop the bug? If I have AllowRootLogin off, does that stop the bug? Is it SSH protocol 1 or 2? Can this affect existing SSH connections? Is there any other work-around?????
I think we just saw TWO irresponsible announcements in the Open Source world, and I hope it's not a trend.
(SSH is one piece of software I do not like upgrading remotely..)
PS: I haven't gotten his message from Bugtraq yet. In fact I've only gotten 2 messages from Bugtraq today...weird...
Please, don't bug your vendor about this unless they don't provide a fix in a reasonable time. Any decent vendor is *already* working on a fix for this, and "passing the word on" a million times is just going to be annoying to their poor support folks.
"Another interpretation would be that he wants vendors to port the privilege separated version of sshd to their platforms..."
That is exactly what he wants.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
An important skill for anyone who uses UNIX, *BSD, or Linux is being able to build and install software from source. If you haven't done it before, take some time to learn how to do it properly. It's easier than you might think, just download the source and read the README and INSTALL files.
That's kind of why all the source is released -- you really don't have to wait for packages from your vendor. The packages make future uninstall simpler, true, but sometimes you don't have the luxury of time.
Here's the scary message I get in the system log
.rhosts etc. stuff off.
/usr/local/libexec/sftp-server
on my linux machine.
Jun 25 12:40:54 emu sshd[4872]: Accepted hostbased for userblah from 123.12.123.12 port 2654
Hostbased?
But I've got all the hostbased stuff turned off.
A bit of testing shows that _probably_ it is really using RSA or DSA publickey.
But it is very scary indeed to see this (probably wrong) message in the system log.
Does anyone know if this is _definitely_ an erroneous message.
I've got all of my
Here's my sshd_config file:
Protocol 2
IgnoreRhosts yes
PermitRootLogin no
RhostsAuthentication no
RhostsRSAAuthentication no
AllowUsers blah1 blah2
PasswordAuthentication no
PermitEmptyPasswords no
X11Forwarding yes
Subsystem sftp
Be absolutely certain (*especially* when installing 3.3 remotely) that you have created an sshd user, sshd group, and /var/empty directory prior to invoking OpenSSH 3.3. These requirements must be satisfied even if you do not intend to utilize the privilege separation feature. The daemon fails to start without them.
:))
(Disclaimer: This may be blatantly obvious to you, but I'm only attempting to help.
Do you like German cars?
"If and only if someone has made up the deb."
/usr/ports on your machine."
Someone (the Debian security team) has.
"And then it isn't compiled from source like
Right. Instead, it was configured and packaged by someone who is an expert on that particular software. Of course, I could use 'apt-get source' to get the expert's package built on my system.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
I hope you don't let ISS write the patch! ;-)
Prevent email address forgery. Publish SPF records for y
Really, you should always find no proof of no proof of proof of proof of poop of no proof before posting about lack of it (the lack of no proof). You can find my proof of this argument at my website here.
Leaving the OS Wars aside (I run Linux, yes, but I also run FreeBSD, and I would run OpenBSD if they would just get unanal about bootable iso's): Okay, swell. 3.3 has a hole.
How far BACK does this hole extend? Does my 3.1 have it? Does EVERY copy of OpenSSH since the dawn of time have it? Can someone make this clear to me? Is it only versions that have privledge separation? Where is the boundary of this bug?
A patched version of OpenSSH could be released as soon as Friday, incorporating vendor patches received by this Thursday.
Now, why can't MS and the like be that fast? With gazillions of coders on hand, you'd think they'd be able to at least match that. I like how open source projects allow lots of people to work on a problem independantly, all at the same time. The ultimate parallel processing!
It seems that in addition to manufacturing new threats, they're also rehashing old threats to keep subscription renewals up. Perhaps it's time for Slashdot to add an Ethics topic?
Well, MF has been known blow virus threats way out of proportion, almost to the extent of completely making them up, as is highlighted in this article. And there are probably many other examples of bad ethics. But perhaps a Business topic would be more inclusive? Maybe that's covered by The Almighty Buck, but TAB doesn't seem to fit with ethics as well. Would people stand for replacing TAB with Business, or should an Ethics topic be created, or should we just forget the whole thing?
Never underestimate the power of human stupidity.
Anyway. My guess is that this hole is something substantial, possibly very plateform dependent and any patches aren't going to be trivial. Seeing as all you people who felt the need to use fsck in their posts more than once know about as I do about this then my assumptions are as good as yours (and I don't feel the need to use the word fsck as an expletive once). Non-trivial patches mean that commercial vendors are going to take for ever to release final patches and if you are running anything open to the internet then it's likely to be ssh. Add it all up it means this could be very bad.
Now the OpenSSH team is actually two. One that develops new stuff and does code audits specifically for OpenBSD and another that takes that and ports it to other architectures.
All those bitching about full disclosure, you manage to be completely committed to a cause, idiots and miss the point of full disclosure all at once. If the bug is bad then releasing it when only the OpenBSD version of OpenSSH is patched would be an absolute security nightmare. Giving vendors advance notice is very much required in this case. When the vulnerability is announced then I'm sure it will be fully disclosed which will provide the opportunity to test a system for vulnerabilities.
As for you people who are saying Theo is being pro-OpenBSD, read the above paragraph again and answer this question. If Theo really wanted to really rip on other OS's then what could he have done with this announcement? Only OpenBSD not vulnerable and with mindless full disclosure to cover his arse. You do the maths.
The fact is Theo is a complete arsehole when it comes to security. Some see this as not a bad thing. With OpenBSD security is pretty much everything. To the vast majority of other "vendors" security is something they also do and with this Theo has a legitimate gripe. He has got a shitty reception from other vendors to something that will make a vital link in the security chain more secure. Is he making a point of this? Probably. Is he right to do that? Depends on your point of view. If it gets the "vendors" off their arses and add support for priviledge seperation in their ports then would this be considered a good thing? Most definately.
When it boils down to it, Theo would be well within his rights to patch the OpenBSD version of OpenSSH (by using priviledge seperation) and hanging the other vendors out to dry. He didn't. Deal with it.
Nerd: Derogatory term typically directed at anybody with a lower Slashdot ID than you.
Here's the advisory with instructions...
The ftp sites in France are usually updated the quickest.
"Karma can only be portioned out by the cosmos." -Homer Simpson
I think I'm going to go back to telnet and s/key! When was the last time you heard of a security hole in telnet?
-russ
Don't piss off The Angry Economist
So, but it's open source, so they have a patch out even before the vulnerability is discovered.
When you are finished fixing up your tinfoil hat, you can read the diffs to see exactly what has changed.
If you're using woody - debian testing - add this to your /etc/apt/sources.list:
deb http://security.debian.org woody/updates main contrib non-free
then the usual apt-get update; apt-get upgrade.
The privilege separation code in OpenSSH 3.3 does not work with 2.2 Linux kernels.
It relies on mmap() semantics that aren't supported before kernel 2.4 (maybe 2.3.x). OpenSSH will configure, compile, and install successfully. It will start up, but it will NOT accept connections.
Your clients will get a "broken pipe" message, your syslog will get an "mmap: invalid parameter" message.
The solutions are:
I didn't see this anywhere until I dug into my syslog and then the OpenSSH mailing list. You have been warned.
If you do have kernel 2.4, you should read README.privsep in the openssh source distro, since you need to create a special directory and user/group for this (which also bit me in the butt...even if sshd had worked on 2.2, when I restarted it remotely, it didn't come back up because it didn't have that user...yeah, yeah, rtfm.
Good luck to everyone.
--ryan.
Don't say, "don't quote me," because if no one quotes you, you probably haven't said a thing worth saying.
Slagborr
its not hard when they disable practically all the networkservices on it. its easy to defend a house with no doors and no windows. openbsd still rox though
I'm wondering how you can tell if UsePrivilegeSeparation is working?
Login via ssh, and run:
ps waux | grep sshd
You should see two sshd processes, one with the UID of 0 (root), and the one you are logged in via which should have your UID and "[priv]" in its command name.
If it's not like that, then try restarting sshd. On a RedHat machine run:
Don't know what the init scripts look like on Debian, but you could always kill sshd manually and start it again.
Also make sure you're picking up the configuration files from the right place. They moved from /etc/ to /etc/ssh/ in a recent version.
Somebody correct me if I'm wrong, but this only applies to the ssh server, not the clients. The vulnerability seems like it doesn't matter what software the client is using, in fact I doubt there is even a need for the client to be connected. Think of it like an Apache vulnerability - if you patch the server, then the oldest, buggiest web browser in the world wouldn't make it easier to break in to the server.
I really hate signatures, but go to my website.
Actually, just to clear things up, it's
/etc/rc.d/init.d/ will work, /etc/init.d/ should as well in later versions. /etc/init.d/ is the LSB location of init scripts.
/etc/init.d/sshd restart
on later versions of Red Hat machines. While
On a Debian machine, it's
/etc/init.d/ssh restart
(which kindof annoys me... it should be sshd restart, not ssh).
Quoth parent: We won't tell you what the problem is, unless you're a big distributor.
Quoth Theo: Some, like Alan Cox, even went further stating that privsep was not being worked on because "Nobody provided any info which proves the problem, and many people dont trust you theo" and suggested I "might be feeding everyone a trojan" (I think I'll publish that letter -- it is just so funny).
So, Redhat is a small distributor?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Do you have
deb http://security.debian.org/ woody/updates main
in your /etc/apt/sources.list?
GROGGS: alive and well and living in
I don't know of any reason to believe that the older versions of ssh are immune to this bug. Theo may, but he is the only publically identified name that does. And what he said indicates that the bug has been there for a LONG time. (i.e., ... everybody should update...).
It's not as explicit a comment as I would have liked, but it does indicate that the bug isn't new.
I think we've pushed this "anyone can grow up to be president" thing too far.
*Sigh* I've now tried both the official OpenSSH RPMs and rebuilt ones, and I can't get privelege separation working on any Red Hat 7.x box I have.
Presumably this is what Theo was referring to when saying that priv separation wouldn't work on some platforms.
Anyone manage to get priv sep working on a Red Hat 7.x box? If so, how?
here is what debian has to say:
http://www.debian.org/security/2002/dsa-134
it looks like they have priv sep on by default
Which is a good start. But did you check if any were actually running as user 'sshd'? I did, and none were --- it seems that privelege separation doesn't work on Red Hat boxes.
Of course, if I'm wrong, that's great --- but I hope somebody points me in the right direction.
That's unnecessary: the commented lines show all of the options and their default values. If the comment says 'UsePrivilegeSeparation yes', then it's already turned on.
(And yes, I tried uncommenting this and restarting. It didn't enable priv. separation at that point.)
The implication there is that the built-from-source port is not configured by an expert. I don't know how debian does it, but FreeBSD's ports are expertly configured (at least if an expert exists). They do however allow one to fetch the source, apply the expert's 'patches' (frequently just config changes)...and then if you want apply your own judgment before doing the build and install. Maybe you really do know more then the expert. Maybe your needs are different. Or, maybe the world has changed since the expert configured the port and package.
For example aome new and untrusted security feature might be left disabled because it is new and untrusted...but the world changes and there is a known attack that the untrusted thing is the only known defense against...
Again. If and only if. The .deb was done quickly, then fine.
/usr/ports updated within a 2 hours of a bug report, and more quickly in the case of a kernel problem -- the rare kernel problem, mind you.
By expert, I mean "me" as I am the expert on the machines I maintain. Not some dude in Raleigh or at MIT. Besides, I have seen
I have linux boxes that I maintain, but I use Rock and compile it all myself. That way I know what is afoot.
Linux isn't the only free operating system.
Comparing it to Windows will be a moot point, since El Dorado is going to have a 40% larger code base than XP.
How else do you expect to get by the web and email scanners which either filter or STOP any executables from getting through?
In order for this JPEG virus to work the host must be previously infected with a standard executable virus (which should be caught by scanners/filters) which enables JPEGs to be executed as code. The JPEG isn't actually a virus at all. It's more like a script for the actual virus to execute, disguised as a JPEG.
McAfee is trying to make people believe that this is a new different kind of virus, and that they now have to fear previously-thought-innocuous non-executable files, which is simply not true. This virus still requires an executable component. For that reason I feel Perrun falls under the catagory of hoax, and this is aggravated by their placing it in the apparently newly created risk catagory of "Low On Watch", which is the same as saying "Well, it's not doing anything now, BUT IT COULD AT ANY MOMENT!" In other words, it's FUD. Since there is a high likelyhood that this is being done in order to increase sales/subscriptions, it is therefore unethical.
Let me add to this that this morning when I logged in there was a message which looked like a virus alert, but which directed me to a site encouraging me to purchase a for $29.95 1 year subscription to VirusScan Online, a program which is already installed on my machine with a current subscription.
I don't know about you, but I put this kind of behavior right up there with Verisign sending fake renewal notices to people who use other registrars.
Under capitalism man exploits man. Under communism it's the other way around.