Announcement

Collapse
No announcement yet.

OpenSSL Outlines Two High Severity Vulnerabilities

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

  • #11
    Originally posted by MadCatX View Post
    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.
    they didn't. Those where all stupid coding bugs. Two off by one bugs... it's really incredible how that's always causing issues.

    Comment


    • #12
      Originally posted by karolherbst View Post

      they didn't. Those where all stupid coding bugs. Two off by one bugs... it's really incredible how that's always causing issues.
      Off by ones are, I'm told, one of the most common coding mistakes that go unnoticed.

      Comment


      • #13
        Any idea why the pulled the previous 1.1.1r release if it's not affected by this bug

        Comment


        • #14
          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.
          F35 does not have version 3.0.x yet, therefore no update is required.

          Comment


          • #15
            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.
            First rule of security... prove it. Easy for you to say that this is low risk, no chance of being used for an exploit — but you're not the one staking both your own professional reputation, and the reputation of your employer on it. Holding up a Fedora release for a week or two while they review the vulnerability and potential impact? That's not something you'd even think twice about... of course you do it.

            Comment


            • #16
              Originally posted by karolherbst View Post

              they didn't. Those where all stupid coding bugs. Two off by one bugs... it's really incredible how that's always causing issues.
              Sure but unless we rewrite all of the critical infrastructure code in the likes of Rust, we will have these things happening. At least this time we don't have to patch 90 % of the internet.

              Comment


              • #17
                anyone know the progress of rustls and if that will overtake openssl in the near future?

                Comment


                • #18
                  Originally posted by dajomu View Post
                  anyone know the progress of rustls and if that will overtake openssl in the near future?
                  There was this comment in a recent article: https://www.phoronix.com/forums/foru...00#post1354600

                  Comment

                  Working...
                  X