Linux Worm Spreading, Many Systems Vulnerable

sverrehu writes "A GNU/Linux worm exploiting a bug in OpenSSL spreads through vulnerable Apache web servers, according to Symantec. The worm, which was first reported in Europe, targets several popular Linux distributions. See also the SecurityFocus vulnerability listing for the OpenSSL bug." sionide also writes: "Netcraft recently published a report which explains that a large portion of Apache systems are still unpatched (halfway down). To protect yourself please upgrade to OpenSSL 0.9.6g."

Comments

Open Source Vulnerable Too

[P!erCer]

People need to know that Open Source is just as vulnerable to viruses and worms as proprietory software is... The hackers target the most widespread software, which is more often than not Windowware. Apache is one of the most widespread Linux programs, and its infection is a sign of things to come as more people leave Windows.

Re:Open Source Vulnerable Too

[Anonymous Coward]

> That's what makes open source software overall more secure -- the turnaround time with patches is a lot faster.

...then why are so many Apache servers still vulnerable? Oh, yeah - those patches still have to be applied.

Open source can't defend against admins who won't patch their software.

Re:Open Source Vulnerable Too

[delta407]

Nothing can defend against admins who won't patch their software. They dig their own grave and sign the epitath of all the systems they run.

Re:Open Source Vulnerable Too

[chris_mahan]

Nobody ever said computer programming was easy. It's a difficult job, full of arcane knowledge and fraught with pitfalls. This is why not everybody can be one, and this is why the good ones ought to be paid well.

Airline pilots are highly trained and constantly upgrade their skills, and are highly paid.

Likewise, programmers who run enterprise-strength systems have heavy responsibilities. This is not something one ought to go into for the money, but rather, for the love and dedication to the craft. (not aircraft)...

As far as QA, I tell you what. If the system is designed correctly, it will need very little QA. I know this because some systems can never get it right, no matter how much QA go into them, because of fundamuntal design flaws.

And yes, designing computer software is hard. Like heart surgery. One slip of the old wrist and it's flatline.

Nice boiler-plate advisory

[Jeffrey Baker]

The advisory at Symantec advises the reader to update their virus definitions and run a full system scan. Presumably they are talking about Symantec anti-virus products, but if they make such a product for Linux/x86, I could not detect it on their website.

...so?

[delta407]

Okay, so this vulnerability was published and corrected over a month ago. Of course it's still growing; a lot of people still haven't patched their servers. How is that newsworthy? It's been out for quite a while now, anyway, and nothing is different today from yesterday. Nothing horrible has happened, it's just continuing to do what it was designed to do.

Besides which, the impact is a lot less than, say, Code Red which affected a much larger number of machines -- it hit all unpatched IIS servers versus unpatched SSL-enabled Apache servers.

Again, I ask, how is this news? What has changed that made this story worth reporting again?

Yeah, So...?

[NetJunkie]

Most MS exploits that hit Slashdot are the SAME WAY. MS releases a fix 6 weeks before, most admins don't patch, and then the big exploit hits.

Welcome to the world of mainstream. :)

Linux is losing an important edge

[JaredOfEuropa]

Of course, it was only a matter of time before hackers showed an interest in this OS. Most parts being open source, perhaps that means that holes in the OS or applications are easier to find, but that goes for both the hackers and for people on the up-and-up. I'm surprised it took so long, and it will certainly happen again. The real question is: how will the admins of the affected or vulnerable servers act, and how many are aware of the issue?

And that is where Linux is starting to lose its edge on Windows: the quality of the sysadmins. With the risk of being accused of making a crass generalisation, I'd say that many, many Windows sysadmins are of the point-and-click Mickey Mouse variety. Worse, not just the admins, but the infrastructure architects as well. After all, all you need to set up a domain is to complete one easy wizard, right? I have seen the result in all its ugly glory. Linux on the other hand required an admin who knows what he is doing, since there were no easy wizards. Much configuration was by editing files, with the how-to printouts in hand.

I say "required" in the past tense, since Linux is becoming easier and easier to set up. Some distros are close to the point where I'd be happy to give the CD to my mom and have her set up her own desktop. That is not a bad thing. Yet, I already have seen a few (very few, thankfully) "sysadmins" setting up Linux boxes for database or web services, without really knowing what they are doing. When we get to the point where managers themselves can set up Linux, they will be tempted to hire less and less qualified staff, as has already happened to a large degree with Windows NT.

My fear is that Linux servers will be run by less qualified people in the future, and that it will cause the proliferation of aggressive and effective Linux virii.

I hate to say it

[ealar dlanvuli]

But don't a decent amount of the readers here make statments like "At least us linux admins patch our boxes regularly". And "There is a patch avadiable that night, and most linux admins patch asap; whereas MCSE's never patch".

I hope I never see another post stating that again, ok? Especially not a god damned +5 one.

Competence closes this hole too...

[rainmanjag]

It seems to me that some basic precautions close this hole before you are even vulnerable... first, only root should be able to run gcc... and second, the webserver daemon should not be running as root anyways... I've never administered an apache server, only AOLServer, and it won't even *let* you run it as root... so if you can't get the server to run code as root and only root can run gcc, then you've got no problems...

-jag

How Do We Solve The Lazy Admin Problem?

[Carnage4Life]

The primary thing that has concerned me the most about most web based worms is the fact that they usually infect systems using exploits that have long since been patched. This is true for both *nix and Windows worms.

Unfortunately given human nature, we can't rely on sys admins and end users to patch their boxen. Almost every mechanism I can think of to automate this process either calls for automatically updating machines (which sucks if a patch breaks an untested scenario and also may need some legal exemptions) or some similar mechanisms to enable computers to help themselves.

Any Slashdotters have any thoughts about this?

Re:How Do We Solve The Lazy Admin Problem?

[Hanno]

Easy. Hire an admin. Pay him to do it.

And then: Don't forget to get a new admin if your old admin leaves the job.

Those machines that have an admin are usually taken care of. But most security issues I see are with clients who have a server that some guy did the setup for some two or three years ago, then left a year later and since then nobody looked after the machine.

As one ad's catchphrase put it correctly you never talk about the server until it fails.

Being the guy in my little company who's responsible for updating the clients' servers, I often experience how clients have a hard time understanding that software support, updates and log checks are necessairy -- because from their perspective this is work without "results".

They can't check if I really did something when I give them a month's bill with x hours for security updates on their machine.

I often explain to them that this server care is a bit like toothbrushing... (Which, btw, is the actual name of that task we use in my company.)

Re:How Do We Solve The Lazy Admin Problem?

[Hanno]

That's what distributions are for... But currently, distributions rely that users check for updates every once in a while. Maybe distributions need an automated security upgrade status check whenever a system goes online.

I could imagine a ip-up.d script (for dialups) or cron job (for dedicated lines) that connects to a distribution mirror site, then asks for a current status of available security upgrades (using signed communication to avoid man-in-the-middle attacks).

If the system is found to run outdated packages, it could warn the user. If it runs dangerously insecure packages, it could even stop the insecure services, maybe even disconnect the machine.

In today's case, after dial-up the upgrade status check would stop any https-related services and tell the user how to update. If no update was available, it would allow the user to reactive the service but only after a stern warning that he should better wait for the updated packages.

Just a thought...

Re:How Do We Solve The Lazy Admin Problem?

[Garin]

It isn't lazy admins. It's lazy management. There is one exception -- home servers. In that case, it's a lazy (or ignorant) user-turned-admin.

Security is about risk management. It's about process, procedure, and diligence. Security is not a technology problem, and it is not solved by geeks.

You can have a secure server farm running virtually any kind of software out there (including M$ products). How? By having a tight, auditable system. You carefully install the systems, documenting your procedure and following best practices (even if you develop them -- the important thing is to have a process). You maintain them on a schedule, leaving nothing to chance. You document the configuration thoroughly, and you enforce rigorous change control.

You might not even have OpenSSL upgraded even though it's vulnerable! You have to decide how much risk is acceptable and worthwhile, but the trick is to consciously and deliberately evaluate the risk, and decide how you're going to deal with it.

This applies to everything. You don't leave it up to your sysadmins to decide whether or not they should upgrade -- it's a part of a checklist that must be done, and can be independently verified at any time. It's part of a procedure that will allow new upgrades to be thoroughly tested and carefully rolled out to avoid downtimes due to unexpected incompatibilities between new and old versions. Imagine someone unwittingly upgrading apache from 1.3 to 2.0, without full testing on a major production system or even realizing that there may be configuration differences.... Nightmarish.

The only way to truly run a secure system is to realize that it has to be extremely carefully planned and managed. It's a hell of a lot of work, and it costs a lot of money. So it quickly becomes an exercise in traditional risk management. This is where the suits and the high-priced consultants often come in. You have to find out how much everything is worth, and what kind of risk you're willing to tolerate (or conversely, how much security you can afford given your environment). You will never be 100% mathematically inpenetrable, but you can reduce your risk to a level that you're comfortable with.

Obviously, this kind of thing scales. If you have a simple system, your plans and procedures can be fairly simple as well. As long as you have a solid verifiable plan, and you stick to it, you'll be fine. If you have a complicated system, your security management is going to be complicated as well.

Security Lists

[Q2Serpent]

This is why I subscribe to the Mandrake Security mailing list. I got an e-mail about this a little while back, did a "urpmi --auto-select", saw ssl in there, and bang. No more problem for me.

-Serp

Re:only Intel systems?

[Anonymous Coward]

Because a buffer overflow on a Intel machine will be different than on other machines. Thats what makes architectures unique, they handle stacks and heaps and return calls differently, which means completely different machine code.

...and opens another one!

[devphil]

first, only root should be able to run gcc...

Thank you, try again.

While are you are correct in saying that a limited subset of users should be permitted to run the compiler, that subset should never be the superuser. Compilers have security holes too, and gcc has been no exception. (was it 2.7 or 2.8? don't recall, too tired)

Never do your compiling as root.

Not overrated.

[Cardinal]

How many webserver administrators have the skills to look at the Apache sourcecode (or in this case, the OpenSSL sourcecode), find the bug, and fix it?

All the skill it should take is to apt-get upgrade or up2date, or whatever the distro in question uses for updates. Debian woody had the patch posted immediately. So the skills needed to update your Apache system are no different from those needed to patch code red (Which, a year after its creation, is still roaming around)

The often tauted ability to "go in and fix things" or even to simply "contribute" is highly overrated. Who found and fixed this bug? Was it some random user, or one of the original developers?

Well, judging by the advisory from the OpenSSL team (Dated July 30, btw, this is hardly a new issue) and a cursory glance over the developer list, the advisory issue was not found by anyone on the development team. So, I'm going to have to go ahead and disagree with you. I consider the ability of users to find and patch security vulnerabilities to be a benefit of free software that simply cannot be overstated.

Having said that, I'll concede the obvious. Most end users are not skilled in the ways of finding or fixing bugs. However, there are zero end users of proprietary tools who even have the option of patching security holes in the software upon which they depend.

So, while some may say "But any user can find/fix security holes when it's free software!" I'll simply say "But any user has the freedom to find/fix security holes when it's free software!" Whether or not the user has the skills is irrelevant, what's important is that the option is there.

Nobody is Answering

[Arandir]

Okay, no one is answering the obvious question: Is this an OpenSSL bug, a Linux bug, or a GNU bug?

The submission states "A GNU/Linux worm" and "a bug in OpenSSL". But OpenSSL runs on a heck of a lot of systems that aren't Linux. Does this exploit only affect Linux systems running OpenSSL, or does it affect any system running OpenSSL?

That's a bit arrogant, dontcha think?

[the_skywise]

It's not a "lazy" admin problem.

There've been too many admins who've been burned by a "security patch" that broke the system in some other way. When your computers need to be up 24-7, and you can have, at most, about 4 hours of down time, you're going to be VERY selective about what patches get added to the system. Or from another viewpoint, I just got burned by an XP "security patch" that for some reason broke my autodial functionality so that my routing table went straight into my local network. I had to reinstall Windows XP to get the functionality back... I'm not about to start putting those security patches back on. I don't like it, but my system works. (I run firewall and antivirus software as well, so its not like my butt is completely uncovered, either)

Admin's are not only responsible for the computers and OS's themselves, but the network communications layer, hard drive resources, ALL of the apps on those boxes (and their associated patches), plus help desk support, new computer setups, and old computer shut downs, and let us not forget software licensing management issues.

IT Admins also painfully understand the one part of Software Engineering that Software Engineers don't. Any change to the program WILL have functional differences.

Automating updates can work because it takes the load off of the admin. But as you point out, there are legal issues, plus there's the above issue where you don't necessarily want to install all of these patches because your system works "as is". On the flip side, Norton's LiveUpdate for their anti-virus software runs pretty well. But NAV is a very distinct application and purpose, and doesn't have ripple effects throughout the rest of the computer system.

Also there's an apple and oranges comparison to Microsoft and Linux problems here. Microsoft got its bad press not from legitimate security issues, but because Outlook allowed the very ACT of receiving an email a vector for running a virus/trojan horse through the preview pane. Because Word allowed any document to take control of the users hard drive and begin deleting files, grab the email address book and replicate itself. That's a whole different ballgame than exploiting IIS through stack overflow issues, or exploiting this loophole in OpenSSL. There's a difference between "defeating/exploiting security" and "leaving the doors wide open.". But now, thanks to Microsoft PR to spin their problems and Linux PR to make Microsoft look bad, ALL exploits are equal so that the least exploit is just as important as a truly criticial one and THAT adds to the Admin's workload, and leads back down the road of not getting these patches installed.

In the end, the power and the responsibility lie with the Sys Admin. Which is where it should be.

Re:Linux is No Match For Microsoft !

[allolex]

point one

I know this is Slashdot, but some evidence for Symantec's anti-Linux bias might be useful and relevant.

point two

And in reference to some other posts about GNU/Linux not being Apache and Microsoft Windows not being IIS, remember that IIS and Windows are ostensibly developed by the same company, whereas GNU/Linux and Apache are separate open source projects. Blame can be distributed much more broadly in the GNU/Linux world.