Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Due Diligence?

michael posted more than 11 years ago | from the postscript-always-a-nice-touch dept.

Security 226

ekr writes "The OpenSSL remote buffer overflows discovered at the end of July got a lot of press here on /. But how many people actually fixed their machines? I decided to study this question, and the results are kind of depressing. Two weeks after the release of the bug, over two thirds of the servers I sampled were still vulnerable. Even two weeks after the Slapper worm was announced, a third of the total servers were vulnerable. The paper can be found here in PDF or Postscript."

cancel ×

226 comments

Sorry! There are no comments related to the filter you selected.

FP ON YOUR LAME, SLOWER THAN SHIT SIZE, FUCKNUTS! (-1)

Subject Line Troll (581198) | more than 11 years ago | (#4681285)

"SIZE", "SITE", WHATEVER. FO SHIZZLE, TURDTASTERS! (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4681320)

This just in! (-1, Flamebait)

stratjakt (596332) | more than 11 years ago | (#4681290)

Hippies are lazy!

Movie at 11

First post (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4681292)

I hate waterloo, i'm going to burn this fucking school down!!!!

I hate waterloo as well, Adam Brock is the worst (0)

Anonymous Coward | more than 11 years ago | (#4681549)

prof ever. No, I'm just kidding, he's pretty interesting, his talks on the VAX really get me excited.

First Post? (-1, Offtopic)

CowboyTodd (611194) | more than 11 years ago | (#4681297)

Does CowboyTodd get first post again?

news flash (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4681298)

Most admins suck!

Sad day ... Stephen King dead at 55 (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4681303)


I just heard some sad news on talk radio - Horror/Sci Fi writer Stephen King was found dead in his Maine home this morning. There weren't any more details. I'm sure everyone in the Slashdot community will miss him - even if you didn't enjoy his work, there's no denying his contributions to popular culture. Truly an American icon.

Do some diligence (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#4681304)

on my cock!

And fuck the canucks. They got pretty pissed over my earlier first post!

Props to the subject line troll!

One word: Liability (0, Troll)

Real World Stuff (561780) | more than 11 years ago | (#4681309)

Unless there is liability accountability, people will continue to be lazy. This frequently happens when no-talent hack spend 8 hours a dat hiding from their inflated resumes.

It's not just laziness... (5, Insightful)

Anonymous Coward | more than 11 years ago | (#4681318)

Many systems administrators aren't full-time and have other responsibilities. Keeping up-to-date with every security patch is very time consuming and sometimes management doesn't understand this and doesn't allocate resources for it as long as things are "working".

Re:It's not just laziness... (5, Insightful)

dfn5 (524972) | more than 11 years ago | (#4681853)

Unfortunately keeping up with patches is a very important part of any security strategy. I am all for letting companies do things their way, but if admins don't allocate more time to security and patching then I'm afraid the government will do more than just recommend actions for Security on the Internet and will start mandating stuff. I for one don't want that to happen.

Bottom line? Improve your security while you still have the rights to do it yourself.

Well (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4681323)

Apparently smelly fat bearded Unix gurus are no better than their tie wearing, suave, athletic MCSE counterparts who are too busy getting laid by attractive women to patch their machines.

Complacent admins (-1, Troll)

cscx (541332) | more than 11 years ago | (#4681325)

I think it's the "Linux r0x0rz! It is always secure, unlike micro$hit!!!" attitude that brings it down. I mean, with attitudes like that, they would have no reason to think that they are vulnerable, nor should they have to update it.

Kind of reminds me of that Linux user vs. HR troll, "There is NO REASON to reboot a server with a 275 day uptime because of A SECURITY EXPLOIT! I mean, it's only a LOCAL ROOT EXPLOIT!"

this is why... (5, Funny)

mr_gerbik (122036) | more than 11 years ago | (#4681335)

This is why I run Windows 3.11. No worries about falling behind and not installing the latest fixes.

Re:this is why... (1, Funny)

Anonymous Coward | more than 11 years ago | (#4681465)

Similarly, I gave my mother in law BeOS 5 PE.

Re:this is why... (2, Interesting)

Anonymous Coward | more than 11 years ago | (#4681601)

I recently did some work for a colo client with an unpatched stock FreeBSD 2.6 machine. It was in perfect condition (everything worked fine, no hidden files, no core dumps, nothing funny in the logs going back months). No only that, but all the default old-skool services were running like rexec or whatever. My mouth was hanging open in disbelief but apparently it never got hacked (or it got hacked so well I couldn't find anything). The red hat linux machines on the same lan that are supposedly kept up-to-date by the clients get hacked regularly.

I'm starting to wonder if installing linux 0.99 wouldn't be such a bad idea.....

The Barcella method saved my bacon (1, Troll)

HamNRye (20218) | more than 11 years ago | (#4681910)

Wow, I just read this after reading that article about sh*tty programming, and Michael Barcella saved my bacon. I have decided not to install any patches because:

I can't understand what the he** this program is doing. It's all just "use stdio.h"... WTF?? You wackos can read this stuff??

It is not written in perl, ruby, python, JavaScript or some other high level language. MB told me that C/C++ is evil. I believe him.

While I was trying to read it, a friend came up and pointed at the screen. Rule #3, no pointers.

Finally, I did not see the official seal of the united states in the upper left corner of my text editor. I never do, but after reading MB's column, I look for it.

However, I can't post this message because I am leaving the inet services off until I can understand all of the source for my TCP-IP stack. After that, I'm gonna tackle the source for Telnet.

WooT!
~Hammy

MS Admins (-1)

k0osh.CEOofCLIT (582286) | more than 11 years ago | (#4681342)

thats because most of the admins out there are MS admins that just put up a linux box to please the boss. they dont read security news or bulletins or even know how to secure a linux/bsd box. they just wait for sometihng like windows update to say its ready to install patches.

I wiped my OpenBSD boxes, reinstalled, patched (3, Interesting)

JimmytheGeek (180805) | more than 11 years ago | (#4681343)

I noticed connection attempts from Korea just after the announcement and decided it was time to nuke the the boxes from orbit. Not much point in having an O-BSD box you are only mostly sure of.

I had some angst with RedHat boxes, though. The update mechanism didn't change the reported version number of OpenSSH. Annoying.

Re:I wiped my OpenBSD boxes, reinstalled, patched (3)

WatertonMan (550706) | more than 11 years ago | (#4681795)

I don't understand why you felt OpenBSD was less secure than Redhat in this regard. You can patch the software on OpenBSD fairly easily. Heavens, I've updated our OpenBSD box's Apache several times now.

That is because (1, Funny)

Neck_of_the_Woods (305788) | more than 11 years ago | (#4681345)


The servers you sampled are administered by MCSEs'. Come one now, you know that this has to be the case, because no Linux admin could ever be lazy enough not to patch his system, this is the sole right of a paper MCSE.

Yea that was me pointing at you, the long haired pasty white guy with the god complex. You have become your own worst enemy. You have become lazy and ignorant because no one knew linux and you could rule. We guess what, with getting into the big league comes the price of being exposed.

Better brush up and get on the stick because yes a lot of MCSEs are lazy, no good, paper test taking gimps but your more dangerous. You take the assumption that you are secure, but as more eyeballs look at your systmes as linux gains marketshare you going to have the same issues.

Depressing no? Enjoy the ride, your in the spot light now my friends just like the windows guys....get to your patches like a good boy.

time (0)

Anonymous Coward | more than 11 years ago | (#4681348)

like admins have time for such fiddle faddle chores...

Vulnerability Check (1, Interesting)

Karamchand (607798) | more than 11 years ago | (#4681363)

How does one check if a server is vulnerable without actually "breaking in", i.e. make oneself liable to prosection?
I skimmed through the PDF but could not find anything about this.
Thank you.

Re:Vulnerability Check (0)

Anonymous Coward | more than 11 years ago | (#4681542)

The easy way: Version strings. This method fails when the version isn't bumped up by the patch in the great security by obscurity tradition. If there are other indications that the vulnerability has been removed, then there's no reason not to increase the version, so if the version remains the same, chances are that there is no other way but the shady way: You break in but try to cause no data-modification or denial of service. Especially the latter has been a problem already in the seemingly simple case of testing mail servers for open relays.

Re:Vulnerability Check (5, Informative)

James_G (71902) | more than 11 years ago | (#4681569)

How does one check if a server is vulnerable without actually "breaking in", i.e. make oneself liable to prosection? I skimmed through the PDF but could not find anything about this.

Well if you'd read the PDF instead of skimming it, you would have seen this:

Thus, we can simply connect to the HTTPS server and issue a HEAD request. The server responds with an HTTP header containing the Server: field and hence the answer we desire:

Server: Apache/1.3.26 (Unix) mod_ssl/2.8.10 OpenSSL/0.9.6

They then went on to verify that SSLv2 is not disabled, but they mention later in the paper that on only 10 hosts was this done.

Theoretically you could change the response to report the more recent version which would make this check innacurate, but why would anyone bother doing that? Far easier to just upgrade OpenSSL.

Re:Vulnerability Check (4, Interesting)

DVega (211997) | more than 11 years ago | (#4681844)

To check the version number on the "Server" field of the HTTP Reply is not enough. Some patched versions did not change this header. On the PDF they explain on page 5 that they discovered a way to check the vulnerability without crashing the server.
" It s possible to determine whether OpenSSL has been patched by generating a CLIENT-MASTER-KEY which is one octet too long. It s easy to see that in a patched version, this falls afoul of the length check shown in Figure 5. The result is a handshake error. In an unpatched version of OpenSSL, the server overruns the key_arg with whatever the extra byte is. However, as we shall now show, this overrun is harmless."

Re:Vulnerability Check (1)

Karamchand (607798) | more than 11 years ago | (#4681909)

I found this part, thank you. Sorry I cannot express it better. I meant if the SSL version check, and the SSL2 = enabled check fails - how do you check then?

Re:Vulnerability Check (4, Interesting)

FattMattP (86246) | more than 11 years ago | (#4681572)

I can't believe that you got modded up for just saying "I didn't read the article." If you had bothered to read it and not skim it, you would have found the description of how they check it on page five:
The patches provided by the OpenSSL project do not change the version number. As a consequence, we cannot simply examine at the advertised version number in order to determine whether or not they have been applied. However, due to the nature of the SSLv2 problem, it's still relatively straightforward to determine whether or not a server is vulnerable and therefore by excluding servers which advertise a newer version number identify whether or not a given server has been patched.

[snip]

It's possible to determine whether OpenSSL has been patched by generating a CLIENT-MASTER-KEY which is one octet too long. It's easy to see that in a patched version, this falls afoul of the length check shown in Figure 5. The result is a handshake error.
This right under the section called "Detecting Vulnerable Servers." Maybe you should read the article next time before you post.

Re:Vulnerability Check (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#4681802)

Maybe you should just get a cup of shut the hell up!

Re:Vulnerability Check (2)

Karamchand (607798) | more than 11 years ago | (#4681952)

Thank you for your answer and sorry I cannot express myself better.
Actually I did really _read_ the parts you quoted. My question was more about laws. Doesn't probing if it is vulnerable (i.e. actually "playing the attack") count as attacking?

THIS was what I was asking. But thanks for beeing so friendly and trying to allege me I am a stupid cocksucker.
Cheers.

Re:Vulnerability Check (1)

Karamchand (607798) | more than 11 years ago | (#4682026)

Though I actually don't really care:

I can't believe that I get modded down just for you saying "his posting sucks"

Think about it.

Re:Vulnerability Check (0)

Anonymous Coward | more than 11 years ago | (#4681639)

Easy. You pay me $150/hr, and I'll come in with my Dynasecure Professional-Grade High-speed Vulnerability Sensor and check it out. Shouldn't take more than 3 hours, tops.

Re:Vulnerability Check (0)

5r (585302) | more than 11 years ago | (#4681711)

That's why I allways try to modify this lines in src/include/httpd.h under the Apache source tree wheh I compile: #define SERVER_BASEPRODUCT "Apache" #define SERVER_BASEREVISION "1.3.27" Oh, yeah!! And be sure to set ServerTokens to "Min" in your Apache config. file.

Re:Vulnerability Check (1)

Karamchand (607798) | more than 11 years ago | (#4681976)

ServerTokens Prod is the littlest setting for the normal compile. Of course if you changed the source (e.g. applied the patch available in the apache.org contrib area) this doesn't apply..

Re:Vulnerability Check (2)

AugstWest (79042) | more than 11 years ago | (#4681810)

One installs and runs nessus [nessus.org] , updates the plugins and scans one's servers weekly.

One also tends to sleep well at night afterwards.

cause linux/oss/unix admins are all talk (-1, Redundant)

Anonymous Coward | more than 11 years ago | (#4681375)

they rant constantly about MS admins not keeping up with patch, not begin security aware, etc, but in reality, they are just as bad. Now my computer is flooded with port 137 requests, and i sit back and laugh.

Re:cause linux/oss/unix admins are all talk (1)

Trelane (16124) | more than 11 years ago | (#4682103)

Umm, 137 is netbios-ns, the netbios name service, which is for SMB/CIFS names, which is Windows Networking. Looks like somebody's scanning Windows Shares. Might want to pick a better port to laugh about. :)

Test my firewall (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4681390)

11.57.224.22

the answer is simple (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4681392)

the reason for the delays is because you have to wait for the pussy to get wet before you can enter!

Check using Lynx (0)

Anonymous Coward | more than 11 years ago | (#4681423)

lynx -mime_header http://www.YOURSERVER.com

Should be 0.9.6g or better.

Securing OpenSSL (5, Interesting)

Exmet Paff Daxx (535601) | more than 11 years ago | (#4681455)

Some points to consider:
  • Fear. Most Linux users are probably reeling in shock from the recent trojan inserted by elite hacking group ADM into the libpcap distribution [theregister.co.uk] . The old standby argument that 'checking the MD5 signatures' will save you has become null & void; ADM replaced the MD5 signatures too. The only reason the trojan was detected was because of the Google cache! This kind of thing probably has most users afraid to move to anything recently released that hasn't been extensively peer reviewed.
  • Ignorance. Since the Slapper worm only contains offsets for a handful of platforms, many flavors of Linux are 'immune' to automated infection. While blackhat groups have offsets for nearly every implementation of Apache/SSL in existence (yes, even you x86 Solaris people), this threat isn't considered 'immediate' enough to justify the third point:
  • Sloth. Upgrading your OpenSSL isn't as easy as it could be. You actually have to recompile Apache with ./configure flags to link it to the new version of OpenSSL which you just recently downloaded (it's not trojaned... right?). Sounds easy, but for a production server that hasn't been touched in a year, this tends to make people really nervous

All of this points to the fact that there is a fundamental flaw in the way that the Open Source community is securing their software. Putting MD5 signatures on the same server that the software is available from isn't even close to secure - Dave Aitel of Immunity Security keeps hammering on this point in BugTraq. And we're going to see even more of this 'Upgrade Fear' as more and more distributions get trojaned - Slash is probably next on the list.

We need to look at existing, successful solutions to this problem (like Windows Update) and catch up. Now.

Re:Securing OpenSSL (4, Informative)

Psiren (6145) | more than 11 years ago | (#4681597)

Upgrading your OpenSSL isn't as easy as it could be.

Any decent distribution will do this work for you. That's what they're for after all. My Debian box was updated no more than 24 hours after I read about the problem, requiring nothing more that an apt-get update on my part.

Re:Securing OpenSSL (4, Interesting)

Flarners (458839) | more than 11 years ago | (#4681788)

My Debian box was updated no more than 24 hours after I read about the problem, requiring nothing more that an apt-get update on my part.
That's exactly the problem the parent poster was trying to highlight! Sure, you can blindly trust that the Debian servers are secure and un-trojanned and let apt-get install it without so much as checking a key signature. Even if you do configure apt to check the signature, it fetches the public key from the same server as the packages. Thus, an attacker can easily trojan your machine with man-in-the-middle or DNS attacks, sending you to an update site with a trojanned package signed with his own public key. If someone sneaks into the real debian servers, subverting apt-get is as easy as:
  • Upload new "developers" key signature.
  • Sign trojanned package with new signature.
  • Upload trojanned package.
and it's Game Over. Of course, Red Hat and Mandrake's solutions aren't much better. The key needs to be stored with a trusted entity like Verisign, which is how Windows Update and other commercial-grade updating systems ensure the integrity of their packages. You've never heard of Windows Update being trojanned, have you?

Re:Securing OpenSSL (0, Offtopic)

Flowers (220697) | more than 11 years ago | (#4682050)

<obligatory aniti-MS sentiment> Windows Update is a trojan. </obligatory aniti-MS sentiment>

Re:Securing OpenSSL (1)

doozer (7822) | more than 11 years ago | (#4682106)

Actually, with Debian Security advisories, they DSA email includes the package md5sum

So unless they managed to break into the mailserver, and also my home machine and my laptop
and change the email sent out and also the emails I received, I can use this as a known
good source for package verification.

So, yes, they might be able to access the archive server and replace the package, but it won't
have the fingerprint I was told it would have.

Re:Securing OpenSSL (2)

halftrack (454203) | more than 11 years ago | (#4682116)

Thus, an attacker can easily trojan your machine with man-in-the-middle or DNS attacks, sending you to an update site with a trojanned package signed with his own public key.
(...)
The key needs to be stored with a trusted entity like Verisign, which is how Windows Update and other commercial-grade updating systems ensure the integrity of their packages.


I find this a weak argument. A man in the middle attack would only get slightly harder if they put keys and packages on different (trusted) servers. Their just harder to fake than one server systems, but by monitoring regular patterns between all servers and a client you'd be able to assemble the right phony proxy (or whatever the cracker's using.)

Re:Securing OpenSSL (0)

5r (585302) | more than 11 years ago | (#4681611)

I see you have a very good point about upgrading "base" software (software that other programs relays on). We have over here some serious issues with production servers that nobody knows exactly how they're working. Let alone trying to update OpenSSL. It could take weeks to get it working. On the other hand, I really don't see how is more secure to update using Microsoft scheme. As far as I understand, if someone brokes on Bill's servers, they would propagate bogus packages, in fact binary bogus packages, making the detection one hundred times more difficult. IMHO ...

Re:Securing OpenSSL (1, Informative)

Anonymous Coward | more than 11 years ago | (#4681741)

The bogus update problem is really no problem at all when you use cryptographic signatures: If there is an update, the distributor signs the update with his private key and the update process checks that the signature matches the data and is from a know authorized distributor. The public key which is used to check the update is distributed with the initial install media, so it should be out of the hackers' reach. The distributor would of course have to make sure that his key doesn't get compromised, but that should not really be an issue when smartcards or other separate/disconnected machines are used to sign the updates. This method is already in use today, but many projects still rely on MD5-checksums which the hacker can produce just as easily as the project owners.

Re:Securing OpenSSL (0)

Anonymous Coward | more than 11 years ago | (#4681942)

The public key which is used to check the update is distributed with the initial install media, so it should be out of the hackers' reach.

You are so right! It's too bad the only O/S which supports this is Windows. Hopefully some day Linux will catch up.

Re:Securing OpenSSL (0)

Anonymous Coward | more than 11 years ago | (#4682041)

Some Linux distributions use this method too. It's in the RPM package format.

Re:Securing OpenSSL (0)

Anonymous Coward | more than 11 years ago | (#4682062)

Oh REALLY? Which Linux distributions have a Verisign cert on their install media which they use to sign all their upgrades with? Which one is that? Is that the --verisign flag on RPM? Do tell!

Re:Securing OpenSSL (4, Interesting)

Albanach (527650) | more than 11 years ago | (#4681618)

There's also the issue of those running servers who, sensibly, have either gcc set to non executable, or simply have no compiler installed. It's much more difficult to compile code when there isn't a compiler, and with no gcc available, slapper can't do an awful lot.

Sure something else might come along that can, but as you point out, if you're running a server that's been up a year, changing things is never comfortable, and if you know slapper isn't going to infect you, there's much less motivation.

Re:Securing OpenSSL (3, Insightful)

mwalker (66677) | more than 11 years ago | (#4681902)

Sure something else might come along that can, but as you point out, if you're running a server that's been up a year, changing things is never comfortable, and if you know slapper isn't going to infect you, there's much less motivation.

That's exactly what the Blackhats of the world wanted to hear. Of course, they can use the exploit on you, log in, download their BINARY rootkits that don't need a compiler, and use your bandwidth to rape innocent sites like Slashdot with DoS attacks. After deleting your logs, they'll install a sniffer to see what other systems they can compromise using your NIC's visibility, and finally they'll deface your web site and pipe /dev/urandom onto your hard drive's raw interface.

Have fun!

It's really a damned shame you don't have a way of getting a securely signed OpenSSL update. While Debian has signature and key checking, it's all on a single point of failure server. You really need a trusted key that comes with the install media, but so far the only O/S which supports this is Windows. People who use Free software don't get install media and are pretty much up the creek...

Re:Securing OpenSSL (5, Insightful)

schulzdogg (165637) | more than 11 years ago | (#4681897)

The old standby argument that 'checking the MD5 signatures' will save you has become null & void; ADM replaced the MD5 signatures too. The only reason the trojan was detected was because of the Google cache! This kind of thing probably has most users afraid to move to anything recently released that hasn't been extensively peer reviewed.

False. From the HLUG website [hlug.org] (the group that discovered the trojan):
Thanks to Antioffline.com for hosting us, and Gentoo's Portage system for catching the trojaned files via checksums.

Putting MD5 signatures on the same server that the software is available from isn't even close to secure



This is true though.

False (3, Redundant)

mwalker (66677) | more than 11 years ago | (#4682016)

Thanks to Antioffline.com for hosting us, and Gentoo's Portage system for catching the trojaned files via checksums.

Gentoo had the OLD checksums, which is the reason it was caught. Everyone who checked the new checksums got owned. The Gentoo suspicions were confirmed by checking the Google cache.

Gentoo basically caught this because they were so far behind the curve that they still had the old distribution. While it's a great argument not to use Gentoo, this kind of security-through-being-behind accident is not a security process, nor is it repeatable, nor should it be considered a success of the checksum system.

Servers should disable themselves... (2, Interesting)

tjansen (2845) | more than 11 years ago | (#4681466)

IMHO the right way is to write a system that disables servers automatically if a vulnerability is known and the administrator did not fix it in n days. Either the functionality is integrated into the daemons, and they check (via http, mail, whatever) every day whether they are affected by a problem. Or each system should run a daemon that controls all server software.
It should warn the admin before it turns the server off, of course, but a broken unmaintained server is always better than a hacked server.

Re:Servers should disable themselves... (3, Interesting)

aridhol (112307) | more than 11 years ago | (#4681587)

What happens when the author's website becomes obsolete? Security may be up-to-date, but you now have a bad webpage. Will the server shut itself down, or let you run with a possible compromised server? Also, consider the effect if the timing is set in the source. The first of every (month|year|week) will show an enormous load on the update server. What happens when the software can't talk to the update server? Assume everything's fine? When someone hacks the update server with a new, trojaned form, suddenly everybody will have it. Check the server's logs, you now have a list of compromised hosts.

Other than that, it's a good idea...

Re:Servers should disable themselves... (1)

tjansen (2845) | more than 11 years ago | (#4682058)

What happens when the information is not available is a policy issue that should be configured on a per-server base, as long as the defaults are reasonable. I guess that a server that can not access a HTTP source is not connected to the internet, and thus not such a large danger.

Re:Servers should disable themselves... (0)

Anonymous Coward | more than 11 years ago | (#4681589)

Perfect attack vector for massive denial of service.

Re:Servers should disable themselves... (1)

tjansen (2845) | more than 11 years ago | (#4682047)

You could prevent this if you have several providers for the information (for example the distributions) and you sign the information.

Re:Servers should disable themselves... (2)

0xA (71424) | more than 11 years ago | (#4681669)

I don't really like this idea.

I didn't update the version of OpenSSH on a few of my boxes when the last advisory came out. I wasn't using a vulerable configuration (CHAP disabled) so I didn't really see it as an immediate danger.

Stuff like auto updates also has issues for the same reason. I can't think of an easy replacement for a resposible admin.

Re:Servers should disable themselves... (2)

tjansen (2845) | more than 11 years ago | (#4682088)

I dont care if responsible admins turn the option off. But the majority of servers are more or less umaintained. The majority of people doesn't care for security advisories, and those people can be protected by reasonable defaults that cause the server to deactivate itself if it is a danger for the (obviously naive) owner.

And BTW, dont forget that not only the owner of the server is harmed when a hacker compromises a server and starts a distributed DOS attacks...

And then the updater gets hacked (2)

phorm (591458) | more than 11 years ago | (#4681732)

This could be a nightmare in itself. What happens if the update server gets hacked... then all of a sudden you have systems either auto-trojaning themselves - or shutting down everywhere.

Not really a good idea... an equivilient to *gasp* "windows update" for terminal would be nice (RH8 has one, if you pay for or try RHN), where it automatically gives you a list of updates available and allows you to pick them in a dselect-style (debian) format, or something similar.

Re:Servers should disable themselves... (1, Funny)

Anonymous Coward | more than 11 years ago | (#4681838)

It would be fair as well if trojaned softwares warned us. Some kind of disclamer like "The software you are about to install is trojaned. Would you like to continue? [Yes|No]". This way we would sleep better at night actually *knowing* that our server got rooted.

Missing Correlation (2, Insightful)

VernonNemitz (581327) | more than 11 years ago | (#4681469)

How sure are you the the administrators of the servers you sampled are also Slashdot readers? While certainly some laziness could explain your statistics, what of good old-fashioned lack of communcations? Just because a message warning about a security hole was sent out, doesn't mean it got received, or even read in a timely manner. Besides, maybe most of those administrators were taking three-week vacations just then!

I updated, but I wasn't in a hurry (-1, Redundant)

Anonymous Coward | more than 11 years ago | (#4681485)

I first checked to see if I was vulnerable (also if I was infected), but since it takes a certificate (that I deliver) to initiate the connection with the server on my machine, I wasn't. Many connection attempts on port 443 though.

But I updated anyway with the latest of everything (apache, openssl, mod_, etc.)

We Fixed Ours (2, Interesting)

Shackleford (623553) | more than 11 years ago | (#4681495)

I worked at an ISP at the time that this was happening and we were quite well aware of these vulnerabilites. We often referred to CERT [cert.org] when looking for vulnerabilities that may have affected us. It was through sites like those that we found out about the problems with OpenSSL and we made the necessary changes. I'm not sure why it was found that many others didn't do what was necessary. Perhaps there are many admins that don't understand that they need to keep themselves up to date on these matters, and of course, they are often busy with many other tasks. It's not easy being an admin. Maybe that's why there is a System Administrator Appreciation Day. [sysadminday.com]

Should have upgraded (5, Informative)

Hegemony (104638) | more than 11 years ago | (#4681520)

I didn't and paid for it. Within about 3 hours time, some bastard got in, created a superuser, DoS'd nasa.gov, spawned a few irc servers, and started scanning other IP's for the same exploit. Damn they work fast.

When to Patch (5, Interesting)

Crispin Cowan (20238) | more than 11 years ago | (#4681527)

Readers interested in this topic may be interested in this paper that we presented last week at USENIX LISA 2002 [usenix.org] :

Steve Beattie, Seth Arnold, Crispin Cowan, Perry Wagle, and Chris Wright
WireX Communications, Inc. http://wirex.com [wirex.com]
and
Adam Shostack
Informed Security http://www.informedsecurity.com [informedsecurity.com]
Security vulnerabilities are discovered, become publicly known, get exploited by attackers, and patches come out. When should one apply security patches? Patch too soon, and you may suffer from instability induced by bugs in the patches. Patch too late, and you get hacked by attackers exploiting the vulnerability. We explore the factors affecting when it is best to apply security patches, providing both mathematical models of the factors affecting when to patch, and collecting empirical data to give the model practical value. We conclude with a model that we hope will help provide a formal foundation for when the practitioner should apply security updates.
Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. [wirex.com]
Immunix: [immunix.org] Security Hardened Linux Distribution
Available for purchase [wirex.com]

Methodology... (0)

Anonymous Coward | more than 11 years ago | (#4681534)

What methodology was used for this. Typically vendors patch a problem but don't "force" and upgrade on their customers. Just looking at (external version numbers) isn't going to tell you for sure..

(Mind you I'm not doubting most systems were not patched.. its just you may be getting false positives.)

but what about this exploit (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4681539)

Press alt+F2 (if your de supports that) or open a console and type
yes|/dev/mem

MS way (2, Insightful)

SavingPrivateNawak (563767) | more than 11 years ago | (#4681583)

That's why MS wants to make apps that upgrade themselves automagically

It's not a bad idea after all, too bad you can't trust MS on anything (They use a good idea bundled with a bad one and a EULA that grants them too much)

Re:MS way (0)

Anonymous Coward | more than 11 years ago | (#4681868)

Well, "we" use a license which tells the user that he can take the source and run, but that's usually all there is. Where MS says their software may do this suspicious sounding stuff, we tell the users nothing.

Who should be worried? (0, Troll)

JanusFury (452699) | more than 11 years ago | (#4681631)

Who should be worried about this bug? What does it affect, in particular? I'm guessing just specific webserver configurations, but do I need to patch the Linux distro I just put on this box to dual-boot? If so, how difficult is it - I'm barely getting used to Linux and the idea of recompiling a bunch of system libraries and updating lots of software doesn't sound very good to me ;)

Gentoo! (0, Troll)

tercero (529131) | more than 11 years ago | (#4681632)

For Gentoo users it's as easy as:
emerge update
emerge -u world

It took my Athlon 800 system >2 minutes to be fixed. I can understand the liability about why not to upgrade and apply security holes, but as IT pros, we have to weigh out the evils of this world and pick the best path for our users.

Re:Gentoo! (3, Funny)

op00to (219949) | more than 11 years ago | (#4682052)

>2 minutes? Like an hour?

0.9.2b and 0.9.6b (-1, Offtopic)

roly (576035) | more than 11 years ago | (#4681636)

0.9.2b is weirdly popular because the extremely-popular Sun Cobalt RaQ 3 server appliance uses a security fixed 0.9.2b, but Sun Cobalt only released the fix for all thier appliances that use OpenSSL (Qube 3, RaQ 3/4/XTR/550 use OpenSSL) on October 1 2002 which left a large amount of servers vulnerable for a long time. 0.9.6b is popular because it is used in many places, including Cobalt RaQ 4 and XTR servers, Red Hat Linux 7.2/7.3/8.0 (Anyone know why RH8.0 is still 0.9.6b?) as well as a few versions of Mandrake. The significant amount of old unpatched versions is because there are many server admins with not much security knowledge (Mostly Cobalt RaQ users and people renting dedicated servers, I was once helping someone patch thier old Apache 1.3.19/mod_ssl/OpenSSL 0.9.6b/PHP 4.0.6 server once).

... and my friend (0)

roly (576035) | more than 11 years ago | (#4681659)

And my friend's server, using OpenSSL 0.9.6 as well as old OpenSSH/Apache/PHP/etc was rooted (Proberbly via OpenSSL) and someone started using it to DoS someones server. Sigh.

Damn MCSEs (5, Funny)

davinciII (469750) | more than 11 years ago | (#4681648)

See, this is exactly what happens when you hire a bunch of paper MCSEs to run your........

wait, did you say Linux?

Due diligence. (5, Informative)

Black Parrot (19622) | more than 11 years ago | (#4681664)


This is too easy, folks. Subscribe to your distro's update announcement list, read your mail daily, and apply the relevant patches promptly.

It's really not that hard. A typical update for me is:

  1. read mail
  2. ncftpget whatever.rpm
  3. rpm -Uhv whatever
  4. read rest of mail
By far the most time-consuming part is waiting for the RPM to download. Some say that it's even easier for source-based distros.

Re:Due diligence. (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4681701)

who the fuck says "the congress"(your sig)? No one that actually LIVES in America, that's for damn sure.

The window (2)

Lemmy Caution (8378) | more than 11 years ago | (#4681752)

That is correct. That is how you fix it.

However, some people take vacations, or go on project, or the such. Some people even sleep, and a window of vulnerability of only a few hours can create a serious problem. Your advice is perfect for those situations which need it the least - where the system is regularly serviced by a nearly-constantly-available administrator. This by no means covers all situations.

Re:The window (2)

karlm (158591) | more than 11 years ago | (#4681960)

On my RH server, I have it set up every 6 hours to do an up2date followed by an autoupdate. I'm out of sync with the official website on average 3 hours. Granted, it's not a high-traffic site, so I don't have to worry too much even if updates do go awry.

Re:Due diligence. (1)

VirexEye (572399) | more than 11 years ago | (#4681876)

It's a bit more complicated than that as you would also either need to update apache using RPM's (no fun) or recompile it from source. Tack on about 30 more commands to those 4 and you might get somewhere...

Run right out and get nessus. (5, Informative)

AugstWest (79042) | more than 11 years ago | (#4681678)

If you haven't yet, you should definitely check out nessus [nessus.org] .

It'll scan your machiens for known vulnerabilities and give you pointers on how to go about taking care of any that it finds. It's also got built-in updating to pull in the latest exploits.

The clients are even getting pretty spiffy these days, and the project has matured very rapidly.

Have we grown complacent? (5, Insightful)

mao che minh (611166) | more than 11 years ago | (#4681748)

Perhaps Linux users and administators have grown overly comfortable due to the long reign of tight security and lack of virii? Until rather recently, disclosed security advisories for FOSS could be neglected for substantial periods of time without worry. The world's hackers mostly took aim at easily exploitable IIS and Exchange servers, flimsy Win32 email clients, and major routers (like AT&T backbone routers to Asia and such). Largely ignored were the hordes of vulnerable web and mail Linux/BSD servers on campus networks and elsewhere (mostly left vulnerable due to neglect, not inherent OS issues). However, the desire to orchestrate large scale DDoS attacks and an exponential increase in the use of Linux systems has caused many hackers to take interest in conquering new grounds.

All of these years of rock solid security has made us complacent. We have to remember that, while Linux and OSS may be inherently secure, and Linux's modular design works as a fail safe against complete failure, we are still just as vulnerable if we don't remain vigilant.

Re:Have we grown complacent? (4, Insightful)

AugstWest (79042) | more than 11 years ago | (#4681879)

Perhaps Linux users and administators have grown overly comfortable due to the long reign of tight security and lack of virii?

I think this is a complete fallacy. Most default Linux installations, when left alone on a cable/DSL connection, have been hackable for years now. I can remember when I installed RedHat 6.2 on my gateway machine without having time to do the updates, and before midnight that night the box had been hacked.

I think that a lot of Linux users don't even realize when they've been hacked, either. Even the automated scan-and-exploit tools these days are becoming quite good at getting themselves installed on a system quietly. Unless you watch your logs on a daily basis, you often have no idea what is actually going on with your system.

Re:Have we grown complacent? (0)

Anonymous Coward | more than 11 years ago | (#4681997)

I took the appropriate steps. Now I wear a seat belt while administering Linux.

FreeBSD binary updates (2, Informative)

Cleveland Steamer (625191) | more than 11 years ago | (#4681765)

From page 4 of the PDF:
  • As should be noted from Figure 4, updating on Linux was rather easier than updating on *BSD, since all of the *BSD updates required compilation, either of the base system or from the ports/packages collection.
Huh?

# pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/A ll/openssl-0.9.6g.tgz

Binaries installed -- no compilation required!

Weird misconception (5, Insightful)

dfn5 (524972) | more than 11 years ago | (#4681773)

I find that other admins patch by necessity. i.e. If something is broke, then patch it. If not leave it alone.

However, I read a stat somewhere that said that a large majority of security breaches could have been prevented by merely keeping up with patches. Therefore my philosphy is to create a patch schedule. And because I'm on Solaris things like OpenSSL are 3rd party to the OS, therefore I upgrade immediately. I rebuilt my solaris RPMs of OpenSSL that day and had it deployed to all my machines. Other things like GnuPG, IPFilter, OpenSSH, apache, sendmail, etc... they all need to be upgraded ASAP.

So all you Slashdot readers who posted that you have nothing to do but read Slashdot in that downsizing article [slashdot.org] , get off your butts and start patching. That should keep you busy full time.

Re:Weird misconception (5, Insightful)

mao che minh (611166) | more than 11 years ago | (#4681866)

Yes. I think that services like the "Red Hat Network" will greatly benefit end users and admins alike in this respect. Having a service that organizes errata (updates) and informs you what the current security threats are, and then shows you what systems you own/administer are vulnerable is very helpful. It gives end users an almost hands-free way of keeping themselves safe (as safe as they can in terms of updates, anyways), and can point out things that admins might have missed. I really like it.

Someone will make you do it! (0)

Anonymous Coward | more than 11 years ago | (#4681804)

If you don't update on your own, someone's going to make you update! I had my homepage overwritten by some kiddies at M4F14 (mafia?) using the OpenSSL vulnerability twice in 3 weeks.

After finding the offending package, I promptly updated it and have had no problems since. It was a bit of an annoyance, but I wansn't too mad about it. Someone's got to give me a kick in the ass sometime to keep myself up to date and secure.

Re:Someone will make you do it! (0)

Anonymous Coward | more than 11 years ago | (#4682079)

A compromised server has to be rebuilt from scratch. If you don't rebuild it, you're in risk of running hidden backdoor processes. If you value data integrity, you also need to restore a known safe backup or at least do some consinstency checks. If someone "makes you update", the update is no longer enough.

Let me get this straight... (1)

compass46 (259596) | more than 11 years ago | (#4681894)

You probed random machines that were not your own and unannounced. True this gives you the best possible sample, active machines in the wild, to do your study. It was still a dumb idea. What would have happened if you angered a disagreeable sysadmin, who may or may not have patched his system.

sysadmin: You tried to break into my server!

you: No, we were, uhhhhhh, conducting research.

Say what you will, but there would be suspicion cast over your actions. You need to balance academic goals with possible consequences

Have your machines patch themselves. (5, Informative)

TheFlu (213162) | more than 11 years ago | (#4681895)

Run GRAB [runlevelzero.net] or one of the other automatic updaters for Linux and never worry about this problem again. GRAB has saved me countless hours of updating all of the Linux boxes I administer.

We're all doomed... (2)

fanatic (86657) | more than 11 years ago | (#4681968)

because this means that for any given attack, there will always be thousands or millions of vulnerable machines out there, all of which will (potentially) be made into DDOS zombies.

I'm tempted to think that what's needed is a bunch of vigilantes who go accross the net and wipe any machine that's still vulnerable to any given bug after a while - but even this is not a solution, as some exploits/rootkits, after cracking a machine, install the fix to 'close the door behind them'.

It was you! (1, Troll)

telstar (236404) | more than 11 years ago | (#4681971)

"I decided to study this question..."
  • So
  • YOU were the guy that overflowed my server and brought the whole thing down!

Two words (4, Insightful)

npcole (251514) | more than 11 years ago | (#4682027)

Package management.

For the part-time server admin, who doesn't have time to read up on the latest patches, recompile all applications and their libraries from source, work out dependencies etc., the work of the debian security team is invaluable.

apt-get update
apt-get upgrade

Now, I know that this relies on the hard work of others; all I can say is, "thanks, I really appreciate it."

Disclaimer:

This post is not meant to be debian propaganda --- no doubt other venders are doing a good job too. The point is that this is the kind of problem that a package system solves, and solves well. (As long as there is a trusted source)

It's simple really (3, Interesting)

Anonymous Coward | more than 11 years ago | (#4682032)

Hundreds of machines running ssl. A few administrators. Often upgrading ssl means recompiling ssh and other applications, so it is NOT a simple

rpm -Uvh
or ./configure
make
make install

(If I see these simplistic answers one more time I will puke)

Other things are seen as more important than security by the people that employ the sysadmins.
You can either

A) piss people off by not fixing their problems, argue with them about how some mysterious security shit is more important, waste valuable time, maybe get the patch done and avoid getting hacked. For this you're not rewarded, you're seen as inefficient - you didn't get some dipshit's email to work or something (and this dipshit may control your life in the organization).

B) Fix dipshit's email, do whatever else people think is imporant. Don't waste time making your case. Do mention that you should be working on this mysterious security patch thing no one wants to hear about though... Get hacked - holy SHIT everyone knows that's a bad thing, no more "can I please reboot your machine" no more questions at all, you get to take that piece of shit computer and wipe it clean, upgrade everything, piece of cake. Then for the next few days no one bitches that you are patching stuff all over the building - they WANT you too so they don't get screwed like the poor schlub that got hacked. End result of not be "Duly Diligent"? You are a hero, everyone knows you work way too hard, etc etc.

The age old problem for sysadmins - if you are truly good people think you don't do anything, stuff just works.

I have ten years experience at this, I manage sysadmins at my organization now. I spend a lot of time trying to cheerlead for the important work they do. Still we often have these kinds of problems. I've found it does work to sometimes just put a smile on your face and say "what, me worry?" and let some things break. Raises follow.

Fuck people, fuck them all.

Ah, a little sysadmin recovery makes me feel so much happier.

And no, none of us read your stupid email. Your lives are boring, face it!

-A Grouchy Young Man
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>