Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security

New OpenSSL Security Advisory Announced 95

Posted by samzenpus from the protect-ya-neck dept.
A user writes: It's time to patch OpenSSL again. The OpenSSL project has patched several moderate- and low-severity security vulnerabilities and also has added protection against the Logjam attack in new releases of the software. Personally I wish that OpenSSL released these in a predictable cadence. Patch Tuesday maybe?
This discussion has been archived. No new comments can be posted.

New OpenSSL Security Advisory Announced More

New OpenSSL Security Advisory Announced

Comments Filter:

  • Predictable cadence? (Score:5, Insightful)

    by mars-nl ( 2777323 ) on Thursday June 11, 2015 @06:11PM (#49895067)

    What's the use of a predictable cadence for security updates? Security vulnerabilities are not found on a schedule. Personally I want my updates ASAP. You can update when you want (but sooner is better for everyone).

    • Re: (Score:2)

      by JSG ( 82708 )

      "Security vulnerabilities are not found on a schedule."

      Agreed. Still, at least we get silly names for OpenSSL vulns rather than simply just CVEs and KB numbers with descriptions that usually say something like "A vulnerability in stuff can cause your cat to spontaneously combust on wednesdays when the full moon is in venus. You may have to reboot your computer after applying this update."

      Oh well, it's time to:
      $sudo apt-get update && sudo apt-get upgrade
      $sudo pacman -Syu
      #emerge -uva --deep --newuse

      • ... My laptop is starting to cook my bollocks, compiling LibreOffice.

        Sure, it's called a "laptop" in the user manual, but that doesn't constitute a How-to now, does it?

      • Re: (Score:2)

        by rdnetto ( 955205 )

        Oh well, it's time to:
        $sudo apt-get update && sudo apt-get upgrade
        $sudo pacman -Syu
        #emerge -uva --deep --newuse --keep-going @world
        $sudo yum up

        The third one above is my patch tuesday, wednesday and probably thursday 8) My laptop is starting to cook my bollocks, compiling LibreOffice.

        I run Sabayon, you insensitive clod! :P

    • Comment removed based on user account deletion

      • Or they could release a patch and companies can install it 3 days later. I don't understand why you would want to hold the patch back? It was a retarded concept when MS introduced it, but even now you can control the distribution of windows updates in a controlled manner throughout an organisation so even that has run its course.

    • Re:Predictable cadence? (Score:4, Insightful)

      by Dutch Gun ( 899105 ) on Thursday June 11, 2015 @08:33PM (#49895693)

      You're obviously patching your own machine, not thousands of other people's machines, for whom any patch carries the risk of breaking mission-critical software and potentially costing your company millions of dollars in lots productivity per day. A predictable cadence is extremely useful for non-zero-day exploits, and even zero-day exploits if the risk is deemed acceptable or can otherwise be mitigated temporarily. The whole notion of a once-a-month patch schedule is entirely for the benefit of corporate customers, to make it easier to test and deploy those patches on a regular schedule.

      • Re:Predictable cadence? (Score:5, Interesting)

        by myowntrueself ( 607117 ) on Thursday June 11, 2015 @10:29PM (#49896097)

        You're obviously patching your own machine, not thousands of other people's machines, for whom any patch carries the risk of breaking mission-critical software and potentially costing your company millions of dollars in lots productivity per day.

        Not quite *any* patch.

        Debian has a good reputation for not changing anything in a security patch other than the security vulnerability itself. Ie if the version of the software in the distribution is, say 1.0 then patching security updates will never change the version to 2.0. The patched version has exactly the same behaviors as the version its updating minus the security vulnerabilities. If you were somehow taking advantage of those vulnerabilities then, well, thats your problem. Also if you are mixing 3rd party non-Debian packaged software in, you are on your own there too. But a pure Debian server should be able to be apt-get upgraded with no problems.

        (There was one time when the package maintainer of sudo _decided_ that the defaults for handling environment variables were 'unsecure' and changed them as a security update, which broke a lot of peoples shit. But that was a long time ago).

      • What stops you from patching your machine in your own time?

        • What stops you from patching your machine in your own time?

          Budgets, schedules, coordination with other 24/7 services that depend on it, etc, etc. If it is a single isolated system, then yeah, it's trivial. When we are talking about production and test environments with dozens (or even more) systems, then it is not just a matter of working "own your own time." This gets worse when there are systems that heavily utilize SSL.

          Any such upgrade requires some type of basic regression testing of said systems outside of the typical testing schedules associated to develo

          • The point is, why should patches be held back from everyone else just so your organization has time to plan and test. Your organization can wait until it is ready to apply the patch while some other, more nimble, organization can apply it sooner. There is absolutely no reason for the patch to be held back to give you time to get your duck in a row.

            • Well, I can give you at least one reason:

              Assuming we're talking about non-zero-day exploits (stuff that white hats reported in confidence), part of the issue is that actually releasing a patch tells black hats a lot about how to create an exploit, and this applies to both open source and non-open source, but with slightly different methodologies. It's fairly easy for black hats to reverse engineer a patch to determine exactly how you can now exploit unpatched systems. So, the clock starts ticking the mome

          • So telling you that the patch will come out on a Tuesday will alleviate your budget, schedule and co-ordination problems, but simply releasing the patch and letting you install it on a Tuesday doesn't?

            Why should I wait for my patch because you have a co-ordination issue?

    • I think it's a sign that there's something seriously wrong when people are requesting a regular release cadence to fix all the security holes in the software that's supposed to be protecting them from security problems...

      ObXKCD [xkcd.com].

  • ...by LibreSSL in FreeBSD, in addition to in OpenBSD. Wonder how long is it before Linux, Windows and MacOS (both OS-X and iOS) follow?

    • Re: (Score:2)

      by yuhong ( 1378501 )

      OS X and iOS already picked SecureTransport years ago, which had it's own problems BTW (though with 10.11 it is finally getting better).

    • Re:OpenSSL has been replaced... (Score:4, Informative)

      by Pow ( 107003 ) on Thursday June 11, 2015 @06:49PM (#49895225) Homepage

      LibreSSL patches today:

      Avoid an infinite loop that can occur when verifying a message with an unknown hash function OID.
      Diff based on OpenSSL.
      Fixes CVE-2015-1792 (however, this code is not enabled/built in LibreSSL).
      ok doug@ miod@

      Avoid a potential out-of-bounds read in X509_cmp_time(), due to missing length checks.
      Diff based on changes in OpenSSL.
      Fixes CVE-2015-1789.
      ok doug@

      Avoid an infinite loop that can be triggered by parsing an ASN.1
      ECParameters structure that has a specially malformed binary polynomial field.
      Issue reported by Joseph Barr-Pixton and fix based on OpenSSL.
      Fixes CVE-2015-1788.
      ok doug@ miod@

    • Re: (Score:1)

      by Anonymous Coward

      FreeBSD has not replaced OpenSSL with LibreSSL; OpenSSL is still used in the base system, while LibreSSL (like newer versions of OpenSSL, or WolfSSL, or anything else) are available via ports:

      stable/8: http://svnweb.freebsd.org/base/stable/8/crypto/openssl/?view=log [freebsd.org]
      stable/9: http://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log [freebsd.org]
      stable/10: http://svnweb.freebsd.org/base/stable/10/crypto/openssl/?view=log [freebsd.org]
      head (FreeBSD 11.x): http://svnweb.freebsd.org/base/head/crypto/openssl/?view=log [freebsd.org]

      It sure looks l

      • It sure looks like there's a lot of work to be done (API/ABI incompatibilities with ports) before LibreSSL could replace OpenSSL in the base system

        I'm curious as to why: LibreSSL isn't a rewrite from scratch. I thought they were explicitly doing an audit and clean up, which means keepint the external interfaces the same. Or is it just a question of actually testing things to make sure nothing has broken for obscure reasons?

        • I thought that they were starting w/ the former, and continuing w/ the latter

        • Re: (Score:2)

          by jandrese ( 485 )
          IIRC they did remove some of the more obscure APIs, but honestly most of those were research projects that were never used in real life, so they shouldn't break anything. The OpenBSD guys compile their own ports tree against LibreSSL and have only had a small handful of applications break I think.

  • Logjam / Diffie Hellman attacks (Score:5, Insightful)

    by complete loony ( 663508 ) <Jeremy.Lakeman@nOSpaM.gmail.com> on Thursday June 11, 2015 @07:29PM (#49895427)

    OpenSSL has added protection for TLS clients by rejecting handshakes with DH parameters shorter than 768 bits. This limit will be increased to 1024 bits in a future release.

    Good. But it doesn't go far enough. How about some kind of deprecation warning if DH is using any well known prime number?

    • OpenSSL has added protection for TLS clients by rejecting handshakes with DH parameters shorter than 768 bits. This limit will be increased to 1024 bits in a future release.

      Good. But it doesn't go far enough. How about some kind of deprecation warning if DH is using any well known prime number?

      What prime number that is known or effectively computable for DH is not well known? Maybe I'm missing something here.

      • In the logjam paper, they speculate that the NSA has the funds to run the first part of a number field sieve on a small number of 1024bit primes. So long as we keep using software implementations with these well known primes hard coded in their source code, HTTPS SSH & VPN connections may be vulnerable.

        Not putting all of our eggs in one basket reduces this risk considerably. In response to this threat, we should periodically publish and use a new set of primes that are appropriate for DH exchanges. Tho

  • So Did OpenBSD's much vaunted refactor of OpenSSL turn up this bug before the OpenSSL team found it?

    • LibreSSL seems to have been immune to somewhere between half and two thirds of OpenSSL vulnerabilities recently. Not perfect, but a significant improvement.

      Early on this was mostly due to the amount of outdated crap they deleted (less attack surface area), but as time goes on more and more will hopefully be due to improving the code that was left behind.

      There's still a long way to go though.

      • B..b..but... it's not perfect!!!

        Yeah, fuck the whiners. It's a huge step forward, and the whiners don't have the technical chops to know what's going on or why they should shut up and care--or just shut up and accept that something useful is being done and will likely benefit them in the future.

    • Re: (Score:3)

      by TCM ( 130219 )

      From http://www.openbsd.org/errata5... [openbsd.org] (emphasis mine)

      009: SECURITY FIX: June 11, 2015 All architectures
      Fix several defects from OpenSSL:

      CVE-2015-1788 - Malformed ECParameters causes infinite loop
      CVE-2015-1789 - Exploitable out-of-bounds read in X509_cmp_time
      CVE-2015-1792 - CMS verify infinite loop with unknown hash function

      Note that CMS was already disabled in LibreSSL. Several other issues did not apply or were alread

  • I can advice every software developer to take a look at mbed TLS (former PolarSSL). It has everything a modern SSL-enabled application needs. It's API is easier that OpenSSL's, it has very good documentation (example programs included) and last but not least: it's secure!

    No, I'm not the mbed TLS developer or in any way connected or related to mbed TLS. I'm just a very happy developer who replaced OpenSSL with mbed TLS in my project many years ago and never had any reason to look back. Even the users of my p

Slashdot Top Deals

To stay youthful, stay useful.

Close