Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security Software Apache

OpenSSL Security Vulnerability 245

Posted by michael from the what-me-worry dept.
SiliconEntity writes "On the heels of multiple OpenSSH vulnerabilities, the OpenSSL project is now reporting a number of security vulnerabilities of its own. OpenSSL is a standard cryptographic library used in a wide variety of security applications. The new vulnerabilities range from denial-of-service attacks to stack corruption, which imply the possibility of running malicious code. New versions of the software are released today which address the vulnerabilities."
This discussion has been archived. No new comments can be posted.

OpenSSL Security Vulnerability More

OpenSSL Security Vulnerability

Comments Filter:

  • already patched (Score:2, Informative)

    by Anonymous Coward
    thanks up2date :-)

    • Re:already patched (Score:2, Informative)

      by zumajim ( 681331 )
      Thanks apt! And no subscription fee either.
    • thanks up2date :-)

      amen. all my boxes were patched before this hit the front page. Went in and even did a MANUAL up2date, since I didn't want to wait an hour, considering it was a pretty important update. Gotta love up2date...

  • phew (Score:5, Funny)

    by Anonymous Coward on Tuesday September 30, 2003 @05:49PM (#7098840)

    thank goodness i use windows

    • Re:phew (Score:5, Funny)

      by Troll_Kamikaze ( 646926 ) on Tuesday September 30, 2003 @06:00PM (#7098937)

      Hell, Microsoft is even kind enough to send the "Latest Internet Patch" right to my inbox. Sometimes 36 times a day, when necessary!!

      Now that's what I call service!

      • Now that was funny! Thanks for the laugh after a rough day dealing with clients "smart" enough to install those "Internet Patches" that "Microsoft" so kindly sends out!
        • For those who describe their systems as 'boxen', do you order multiple 'boxen' of corn flakes also?

          German!...
          Germain!... ...Germain... Jackson!...
          Jackson 5!...
          Tito!

          Yes, *ox is now *oxen in the plural, thanks to Brian Regan [brianregan.com].
          • Yes, *ox is now *oxen in the plural

            Ok then, what about 'bollox'? Does that make 'bolloxen' a second order plural?

            Bolloxen sounds a bit like a anti dandruff shampoo or something.

    • Re:phew (Score:3, Insightful)

      by BlackBolt ( 595616 )
      Yeah, me too. Ignorance is bliss.

      I like to just sit back, have an espresso, and let everything around me fall into chaos. Life is good; the flashing warning lights keep me company through the long night.

  • Which means.... (Score:2, Funny)

    by Anonymous Coward
    we should patch in about a week from now when
    the second round of patches come out.

  • pheeew (Score:3, Funny)

    by Dreadlord ( 671979 ) on Tuesday September 30, 2003 @05:53PM (#7098874) Journal
    fortunately I'm running something secure like telnet, those OpenSSH bugs never scare me...
    • Y'know, the ironic thing is, telnet *is* more secure, as long as you don't connect to it.

      Seriously, between SSH and OpenSSL, I'm getting real tired of patching every week or two. I manage a few Windows, several Linux, and a couple of Sun systems, and "panic patches" on OpenSSH/OpenSSL have far outnumbered any Windows problems. Not that I like Windows better or anything, but this is getting really, really ridiculous.

      At this point, *nix security is better only in that I can strip it down more easily, but
      • I agree, But its a tough comparison. What most people consider 'Linux' is actually a huge amount of apps, so of course there will be more vulnerabilities in comparison.

        Of course, I'm equally pissed about all vulns out as of late, but I guess thats why I run debian patches are just an apt-get away.
      • Y'know, the ironic thing is, telnet *is* more secure, as long as you don't connect to it.

        Well, not sure.
        With telnet, you need someone that actually monitors your socket to grab your password. Gicing the number of sockets out there, it's quite unlikely.
        With OpenSSH/L, you just need someone wanting to do it to your machine. They don't even need your password.

        So which one is more secure?

  • Feeling kinda good about it (Score:3, Informative)

    by ThenAgain ( 627263 ) on Tuesday September 30, 2003 @05:53PM (#7098882)
    At least we find out when where vulnerable BEFORE the exploits start rolling out. I'm also yet to hear of Linux bringing the net to it's knees when some kid writes an e-mail virus.

    Also, it took me less than a minute to patch my webserver. That's good design.

    • Re:Feeling kinda good about it (Score:5, Insightful)

      by Overly Critical Guy ( 663429 ) on Tuesday September 30, 2003 @05:57PM (#7098915)
      At least we find out when where vulnerable BEFORE the exploits start rolling out.

      As opposed to what? The months before Blaster came out that the patch was available?

      Things like this just illustrate that all software has bugs. OSS is not a magic solution, and Microsoft does not hire poor programmers. That won't stop rampant anti-"M$" trolls of course, but the more rational of us can look at this and move on.
      • ...the more rational of us can look at this and move on.

        Yeah; both of you who are on slashdot.
      • As opposed to what? The months before Blaster came out that the patch was available?

        Actually, it was a couple of weeks. And that was very much the exception to the rule with regards to Microsoft's history with bug reporting/patching.

        Case in point is the IE mishandling of SSL which allowed anyone with a valid cert to issue a "valid" cert for any OTHER domain. This went on, denied and downplayed by Microsoft, for HOW long?

      • Re:Feeling kinda good about it (Score:5, Funny)

        by ebay troll ( 712015 ) on Tuesday September 30, 2003 @06:45PM (#7099306) Homepage
        excellent poster!!!!!!! responded in less than 5 minutes, pleasure to work with, quick response

        A+++++++++++!

      • oh please... (Score:2, Interesting)

        by Ender Ryan ( 79406 )
        How many IE and IIS holes went unpatched for months. And how many of the holes found in the past 12 months were found by kids, without even access to the source... *rolls eyes* Windows is absolute garbage when it comes to security. There is no comparison.

        The holes in OSS software are usually holes found by code audits done by people who know what they're doing. And said holes are often only theoretical, ie. many of them aren't exploitable.

        • Then why was it reported, even on Slashdot, that Linux is the most-breached server on the net?

          Take off your anti-"M$" goggles and breathe the free air.
          • Is it? I thought that Linux is the most *used* server on the net. So the amount of cracks are higher simply because there are more targets.

            Or do you have some evidence to back up your claim?

            I'd like to breathe the free air, but I've not got enough money for the per-seat licence...

            • No, it was a recent article called "Linux Most Attacked Server?" The study was repeated on OSNews and several other sites. In it, a study showed over 60% of successful breaches are of Linux servers. ~30% was Windows machines.

              This directly contradicts the spoon-fed mantra that "UGH UGH LINUX=GOOD MS=BAD." And if you bring into play that Apache is more used than IIS, you directly contradict all those people who say "Windows is more used yet less secure!!!!1"

              Or, you could just be rational about it. Take
          • Oh, yeah. I'm the one who can't see clearly. Ever look at your own sig? You're too stupid to realize that the security site linked to is a perfect example of what I said, 90% of those security updates are probably not even exploitable.

            I've been working with Win, Linux, and BSD in a production enviornment for 7 years, and I'm not that stupid. Windows is shit(relatively). Most Linux distros (out of the box anyway) are shit. BSD isn't too bad. However... Windows leaves you at MS's mercy, whereas with

            • You clearly have a chip on your shoulder. Look at the furious anger inherent in your reply.

              Ever look at your own sig? You're too stupid to realize that the security site linked to is a perfect example of what I said, 90% of those security updates are probably not even exploitable.

              Apparently, 90% is your new made-up stat. Meanwhile, we'll ignore all the buffer overflows (particularly in Gentoo) and remote code exploits.

              I've been working with Win, Linux, and BSD in a production enviornment for 7 year
      • Microsoft does not hire poor programmers.

        I refute that. A good programmer would not work on a project knowing perfectly well that it is riddled with fundamental security holes, poor design, marketing driven specifications and so on. For example, whilst I am sure that there are many very SKILLED programmers who have worked on Outlook, I would argue that they cannot be GOOD. There is an ethical dimension to professionalism. Yes, I realise that by this criteria 'good' programmers are extremely hard to fin

      • Re:Feeling kinda good about it (Score:5, Insightful)

        by wfberg ( 24378 ) on Tuesday September 30, 2003 @08:39PM (#7100008)
        At least we find out when where vulnerable BEFORE the exploits start rolling out.

        As opposed to what? The months before Blaster came out that the patch was available?

        To be fair; that patch didn't install on a significant portion of machines (any system running w2k sp2), and the work-around Microsoft suggested didn't either, and if it did, it didn't until a reboot, which wasn't mentioned.
        Add to that that the first patch appeared to install but did not (and would also not "re"install) on a number of machines. Today microsoft advises you to run a firewall and anti-virus programs all over their webpage. Before the blaster incident they didn't, because they hadn't dropped the ball quite as badly yet.

        I also find it (not so..) amusing that the System File Checker doesn't work without the DCOM service running (which isn't running for example, in Safe Mode, a Mode you'd expect sfc to be used in), and that DCOM for some reason listens to any one who will talk to it, rather than, by default, restrict access to 127/8.

  • Why is some software more secure than others? (Score:5, Insightful)

    by cras ( 91254 ) on Tuesday September 30, 2003 @05:59PM (#7098931) Homepage

    I got annoyed at the slashdot comments last time there was security hole in OpenSSH and wrote this page [irccrew.org] (copy pasted below). I count OpenSSL as insecure software - we need a secure replacement. GNUTLS [gnutls.org] looks somewhat better, but I don't trust it too much either.

    Why is some software more secure than others?

    How do you measure software security?

    Here's my definition on what is secure software.

    Intro

    I get really tired of seeing these kinds of comments every time some widely used software has security holes:

    • No software is secure. The difference is how quickly they fix it.
    • It's good that they were found. Now we have less security holes.
    • Popular software gets more security audits which is why they seem to have more security holes.

    While they may be partially true, I think they're also very misleading and disparages the hard work that some secure software authors have done.

    Simplicity Is Security

    The difference between secure and insecure software is really the coding techniques being used by it's authors. Authors of secure software do everything they can to prevent accidental mistakes from ever happening. Authors of insecure software just fixes the accidental mistakes. There are very few secure software authors.

    Auditing insecure software doesn't make it secure. Sendmail is a good example of this. It's been audited countless times by competent people. The simplest mistakes were catched easily long time ago, but a few very difficult to find vulnerabilities were found only recently.

    How do secure software authors then avoid the kind of security holes that are difficult to find? By keeping the code simple. The code doesn't get secure by polluting it with tons of security checks. It gets secure by keeping the security checks in as few places as possible.

    Auditing secure software is easy. You can just quickly browse through most of the sources without having to stop and look at it carefully. Everything just looks clean, simple and correct. vsftpd is a good example of this.

    Sure, it's still possible that secure software has some security holes occationally. It just happens a lot less often (if ever) and usually the problems are less critical. For example none of the security holes in Postfix have lead to arbitrary code execution or being able to read other peoples mails. Denial of Service attacks are nothing compared to them.

    (some examples in the web page not included)

    • Re:Why is some software more secure than others? (Score:3, Informative)

      by Anonymous Coward
      What the hell are you rambling on about? OpenSSL is not inherently insecure. While your points about using the KISS method are good practice for any software, in some cases complexity is inherent to the app. OpenSSL implements cryptographic protocol which is *not* simple, both because of the underlying mathematics, and because of the care which must be taken to avoid attacks which trivialize it.

      And if you think auditing "secure software" is easy, you're just setting yourself up to be owned. Auditing sh

      • Complexity is fine, but it doesn't mean that the implementation has to be full of code that is both difficult to follow and that looks insecure at the first glance. I have looked at both GNUTLS and OpenSSL sources and GNUTLS is significantly easier to follow and it does pretty much the same thing.

        Auditing depends on what you're interested in. Auditing sources for buffer overflows and other common security flaws must be easy. Auditing for crashes and more subtle bugs of course requires to be much more care

    • Re:Why is some software more secure than others? (Score:4, Insightful)

      by GSloop ( 165220 ) <networkguru@@@sloop...net> on Tuesday September 30, 2003 @06:10PM (#7099030) Homepage
      'No software is secure. The difference is how quickly they fix it."

      Perhaps no software is absolutly secure, and without bugs, but we're not anywhere close yet.

      Software needs to be designed (engineered is a better word) to be secure, modular and ONLY as functional as needed.

      I think in general, OSS and Linux do this better than Windows does, but it's a methodology change every OS level software writer needs to take to heart.

      It's critical when Office crashes, or had bugs, but not as critical as in SSL, Apache or something similar.

      In short, I think the laissez faire attitude we all have, both from accepting bugs, and about coding them ourselves is a SIGNIFICANT part of the problem. We need to raise the expectations, and hold people/companies accountable when these standards are not met.

      Cheers,
      Greg

      • Re:Why is some software more secure than others? (Score:5, Insightful)

        by pebs ( 654334 ) on Tuesday September 30, 2003 @08:34PM (#7099981) Homepage
        In short, I think the laissez faire attitude we all have, both from accepting bugs, and about coding them ourselves is a SIGNIFICANT part of the problem. We need to raise the expectations, and hold people/companies accountable when these standards are not met.

        Here lies the problem:

        1) Cheap
        2) Fast
        3) Secure

        Pick 2
        • Here lies the problem:

          1) Cheap
          2) Fast
          3) Secure

          Pick 2

          This is simply not true. If you add in some other commonly requested attributes, like "full of overly complex GUI iCandy," "every feature under the sun," or the like, then you might have to decide.

          The key is simplicity. A simple, well-designed, and carefully coded solution can be cheap, fast, and secure; the simplicity of the design reinforces all three of these.

          QMail, for instance, is free, fast, and secure.
        • Here lies the problem: 1) Cheap 2) Fast 3) Secure
          Pick 2

          Cheap should really be "developed with few man-hours" in this generalized statement. In a sense, good OSS is "highly expensive" .. we're just fortunate enough to have enough men/women doing their part to help out.. or in the case of OpenSSL/SSH, perhaps not quite enough.

          On the other hand, programming in a truly secure fashion from day one dramatically reduces the work to secure the software later on. So maybe that generalization breaks down when y
    • Sounds great. Are you going to start coding the replacement or just wait until someone else does it?

    • Re:Why is some software more secure than others? (Score:5, Informative)

      by SiliconEntity ( 448450 ) * on Tuesday September 30, 2003 @06:21PM (#7099122)
      How do secure software authors then avoid the kind of security holes that are difficult to find? By keeping the code simple.

      You're way off base in this case. SSL requires the use of X.509 certificates, and it was in the cert parsing code that these new vulnerabilities were found. X.509 means ASN.1 formats, which have at least two different encoding rules, BER and DER that both must be supported; implicit versus explicit tags; several different ways of encoding packet lengths, and a host of other complexities. There's no way to write this kind of code and just keep it simple as you describe. Any implementation of SSL which is going to interoperate with other systems on the net is going to face these complexities.

      I've written certificate handling code so I know how complicated it is. Also worth reading is Peter Gutmann's somewhat dated but still insightful X.509 Style Guide [auckland.ac.nz] which describes some of the horrors an X.509 implementation has to deal with.

      In this case the failures were mostly in the error handling, and any developer knows that this tends to be the hardest part of your program to get right. Not only are there a lot more ways things can fail than go right, but they can fail in many more places in your code and it is very difficult to make sure your program can recover gracefully from everywhere something might go wrong.

      Also, I'm not sure if it's public yet, but a lot of other implementations are affected by this besides OpenSSL. See the CERT advisory when it comes out and you will find some of the biggest names in the security business got burned by this. It's absurd to suppose that your cosmic insights are somehow being overlooked by companies that base their reputations on security.

      • I think I'll have to change the wording some more. Complex things require complex code, that's fine. If there's a security hole because the behaviour was wrong in some case, it's understandable.

        What I especially don't like is that the same old buffer overflow and other memory allocation related problems come up over and over again. The 1. problem in this case was a double-free() bug. Although this is the most difficult C-related problem to solve easily (without garbage collector), with cleaner code it lik

      • Re:Why is some software more secure than others? (Score:5, Insightful)

        by iabervon ( 1971 ) on Tuesday September 30, 2003 @07:27PM (#7099562) Homepage Journal
        X.509 may be extremely complex to handle, but that would lead to incorrect X.509 implementations. This, however, was just unsafe code. There's nothing about X.509's complexity which should lead to stack corruption.

        The errors which you should expect from a X.509 implementation involve failing to parse obscure certificates correctly or failing to give the right error message about a malformed X.509 certificate. If the code itself is simple in implementation, it should be straightforwardly obvious that, no matter what, the parser will return either an X.509 structure or an error message; the complexity of X.509 merely prevents anyone from determining if the return value is actually correct.

        OpenSSL has a lot of spagetti code, wrappers, and unnecessary function pointers, inherited from the SSLeay days. In an ideal world, it would be rewritten to be more straightforward, but that's more effort than anyone is really willing to put in (except the GNUTLS people, but that's license-related anyway).

      • In this case the failures were mostly in the error handling, and any developer knows that this tends to be the hardest part of your program to get right. Not only are there a lot more ways things can fail than go right, but they can fail in many more places in your code and it is very difficult to make sure your program can recover gracefully from everywhere something might go wrong.

        I always wanted to have better support for error handling in C. Programmers should not be forced to handle errors by nest

        • Re:Why is some software more secure than others? (Score:4, Informative)

          by cras ( 91254 ) on Tuesday September 30, 2003 @08:35PM (#7099989) Homepage
          I always wanted to have better support for error handling in C. Programmers should not be forced to handle errors by nested if's, "goto error" and wrapper functions that do nothing but check the result of another function and do cleanup.

          Exceptions would be nice, but I think in most cases the cleanup is just freeing dynamically allocated memory. Solution is to get rid of the free() calls. Garbage collector, memory pools, alloca(), data stack, etc. Data stack [irccrew.org] and memory pools have worked very well with my latest project [dovecot.fi]. Error handling is almost always just a return call and there's hardly any wrapper functions just for handling errors. Too bad I haven't yet had time to test how well they'd work in other kind of software. I'd guess pretty well except maybe for general purpose libraries since they require a bit different way of writing C code.

    • It's also a good idea to look at what the software is doing.
      Some things are much easier to secure than others.
      You could spend you life (imprisoned) in a fortress, but you'd miss out on too many things if you do.
    • If you've read Feynman's What Do You Care What Other People Think, you might agree with me that secure software might be developed the same way that space shuttle guidance system is, while insecure software, which is by far the more common type, is written in a matter like the design of the shuttle main engine. Feynman claims that the problem with the main engine is that it was designed from the top down. They figured out how much thrust was needed and what the size should be and descended from there. So

    • the ole keep it simple stupid... (Score:5, Insightful)

      by vt0asta ( 16536 ) on Tuesday September 30, 2003 @09:32PM (#7100288)
      ...troll. Work smarter not harder. Nyuck, nyuck, nyuck. Well, thank god your here to tell everyone how to code secure simple software.

      Be advised that complex data dependent protocols are not trivial to code. Not only that, they are even harder to get to interoperate with other implementations of the same protocol. All the nasty little bug-a-boos show up that the protocol designers hadn't thought or even dreamed of.
      I count OpenSSL as insecure software - we need a secure replacement.
      So what's the plan? Toss out all the OpenSSL/GNUtls code and start over...but this time let's try something new... let's make it simple and secure?

      What you don't seem to understand, is that people far smarter than you and I have already had these philosophical debates and do you know what they came up with?

      No software is completely secure.

      Prompt disclosure is important.

      More eyes, code review, what have you is a good thing.

      Plan for failure/breaches/etc.

      Your measure of secure software is juvenile. It doesn't even provide an interesting definition of software security. Pointing at less than complete implementations of smtp and ftp makes your entire argument suspect. Also the "auditing secure software is easy" comment is another dead give away.

      • It doesn't negate the fact that an embarrassing proportian of critical bugs, are due to very common mistakes which are well documented, and for which there are design practices to avoid them, and automated tools to detect them.
    • Good piece. But it's "caught," not "catched." Not being a grammar nazi, just helping you make it nice for presentation to others.

  • Redhat 6.2 updates? (Score:3, Interesting)

    by whoever57 ( 658626 ) on Tuesday September 30, 2003 @06:22PM (#7099124) Journal
    Anyone got any suggestions where I can find updated rpms for a RH6.2 machine?

    Other than compiling from source, that is. Or upgrading to a supported distro! I'm hoping to put off that day!

  • RedHat RPMS (Score:3, Informative)

    by pollock ( 453937 ) on Tuesday September 30, 2003 @06:23PM (#7099135) Homepage
    New RPMs and RedHat's security advisory for for 7.1, 7.2, 7.3 and 8.0 can be found here [redhat.com].

  • one of life's little ironies (Score:3, Funny)

    by Bernie ( 38226 ) <mb/slash@dcs.qmul.ac.uk> on Tuesday September 30, 2003 @06:34PM (#7099223)
    If you call your product "open" SSL (or openssh for that matter), and occasionally people will discover it's Exactly What It Says On The Tin.

    Well it amused me anyway :)

  • grsec? (Score:2, Insightful)

    by BenjyD ( 316700 )
    Another good reason to run a kernel with the grsecurity patches on servers?
  • Damn did somebody give a MCSD commit priv's to the CVS tree?????

  • OpenSSH not vulnerable (Score:5, Informative)

    by dmiller ( 581 ) <djm.mindrot@org> on Tuesday September 30, 2003 @08:51PM (#7100078) Homepage

    OpenSSH isn't remotely vulnerable to these attacks. Recent versions don't use the OpenSSL ASN.1 parsing code for signature validation (e.g. signatures coming from the network). The OpenSSL ASN.1 code is only used for parsing private keys.

    This was done a little while ago [theaimsgroup.com], as Markus (wisely) decided that we didn't need a whole ASN.1 parser just to verify signatures.

    Don't let that slow you down patching the issue - Apache and other SSL/TLS apps (OpenLDAP, the various imapd's, etc.) may be vulnerable.

  • Understand the scope of the vulnerability (Score:3, Informative)

    by Anonymous Coward on Tuesday September 30, 2003 @09:49PM (#7100360)
    For a server that is using OpenSSL

    Vulnerable to denial of service attack

    Potentially vulnerable to remote exploits (unknown currently)

    For a client (e.g. mail client) using OpenSSL

    • No vulnerability; the problems are on the server side, when processing client certificates

  • Its good to see.... (Score:2, Interesting)

    by 222 ( 551054 )
    that the software we take for granted every day is being given such stiff auditing. I mean, sure it sucks to patch so often, but honestly, wouldnt you rather read this and patch before some jackass releases a public exploit, and every 15 year old that cant find something better to do decides to take down a production box?

Slashdot Top Deals

To be is to program.

Close