Announcement

Collapse
No announcement yet.

OpenSSL Outlines Two High Severity Vulnerabilities

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • OpenSSL Outlines Two High Severity Vulnerabilities

    Phoronix: OpenSSL Outlines Two High Severity Vulnerabilities

    Two high severity security vulnerabilities affecting OpenSSL were made public today, which were the issues that led to Fedora 37 being delayed to mid-November to allow the release images have mitigated OpenSSL packages...

    https://www.phoronix.com/news/OpenSSL-1-November-2022

  • #2
    Not that scary. Too bad Fedora decided to slip the release date, but it's understandable.

    Comment


    • #3
      Too bad. I expected it to erupt like mount Vesuvius and destroy the Internet... Not even yum update for today.

      Comment


      • #4
        Too much ado about very little if anything.

        1) This only affects systems which verify remote X.509 TLS certificates.
        2) This needs a special stack layout and doesn't affect Linux systems.

        Not that many Web servers on the Internet even do it. Fedora 37 was delayed for this. I'm pretty sure some people in Fedora/RedHat knew everything yet they've still delayed the next release. An update for Fedora 35/36 has been pushed to testing, not even stable updates.

        TLDR: This is "critical" for non-Linux OSes and only systems which deal with user-supplied X.509 certificates. Move on.
        Last edited by birdie; 01 November 2022, 01:18 PM.

        Comment


        • #5
          That's it? This? These are the pandemonium inducing pair of CVEs? Kind of a nothingburger.

          "...requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer.​" Likelihood of a CA to act maliciously to leverage this is effectively zero. they'd be blacklisted globally within a short amount of time. Perhaps if there were a way to spoof a major CA and somehow self-sign without an app noticing. Maybe, not not very likely without Herculean effort. The second method, not sure. Outside my purview. Second vuln has the same requirement for exploitation.

          Comment


          • #6
            Originally posted by birdie View Post
            Too much ado about very little if anything.

            1) This only affects systems which verify remote X.509 TLS certificates.
            2) This needs a special stack layout and doesn't affect Linux systems.

            Not that many Web servers on the Internet even do it. Fedora 37 was delayed for this. I'm pretty sure some people in Fedora/RedHat knew everything yet they've still delayed the next release. An update for Fedora 35/36 has been pushed to testing, not even stable updates.

            TLDR: This is "critical" for non-Linux OSes and only systems which deal with user-supplied X.509 certificates. Move on.
            Because if they didn't ye ol' stock price and reputation would take a hit to the nads.

            Comment


            • #7
              Originally posted by kozman View Post

              Because if they didn't ye ol' stock price and reputation would take a hit to the nads.
              'Zactly. Yes Fedora rightly prides itself for it's degree of independence from RedHat. But in the IT world Fedora is still perhaps the most public-facing portal to IBM.

              Security Matters.

              Comment


              • #8
                Okay, who was the person who said that the biggest mistake in OpenSSL might have been the decision to use X.509 formatted certs? Step up and collect your prize.

                Comment


                • #9
                  Originally posted by kozman View Post
                  That's it? This? These are the pandemonium inducing pair of CVEs? Kind of a nothingburger.

                  "...requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer.​" Likelihood of a CA to act maliciously to leverage this is effectively zero. they'd be blacklisted globally within a short amount of time. Perhaps if there were a way to spoof a major CA and somehow self-sign without an app noticing. Maybe, not not very likely without Herculean effort. The second method, not sure. Outside my purview. Second vuln has the same requirement for exploitation.
                  Not zero. There are zombie reanimations of previously discredited CAs out there such as the Comodo decendants who are still issuing bogus certs despite being repeatedly named and shamed.

                  This still needed to be fixed and it has been even in client Linux distros. I saw the Mint update yesterday along with an OpenBSD/LibreSSL update (and arguably OpenBSD wasn't really vunlernable given the layers of mitigations already mentioned in the OpenSSL press release).
                  Last edited by stormcrow; 01 November 2022, 02:19 PM.

                  Comment


                  • #10
                    I was expecting some kind of another doomsday bug, this is quite underwhelming Apparently the lessons learned after goto_fail and heartbleed are paying off, which is good news.

                    Comment

                    Working...
                    X