Threads for komuW

  1. 5

    Go and OpenSSL releasing on the same day is indeed interesting. To my understanding that makes it less likely to be like heartbleed and more like something more similar to the protocol side for example, if in fact related

    I must say that it’s quite disappointing that the embargo of something that critical is runniwng for so long. Giving any attackers aware of this issue a week to exploit systems is a lot. I wonder how complex the fix will be.

    1. 11

      Yeah, at least rustls hasn’t also announced an embargoed fix. If rustls did too, then I’d maybe be a bit more urgent with response.

      I must say that it’s quite disappointing that the embargo of something that critical is runniwng for so long.

      Honestly I’d rather be given plenty of warning because this is probably going to suck super hard.

      1. 10

        Filippo Valsorda(FiloSottile), who is the maintainer of Go’s cryptography libraries said on Go’s slack channel that the patch is unrelated.

        1. 4

          Any chance of a link to that?

          1. 1

            Russ Cox also sent an email clarifying that the two fixes are unrelated.

            (I am not sure if the Google Groups link there is available to non-subscribers, but I hope it is.)

          2. 3

            A week is pretty normal in my experience.

            That’s what the Django project does, too, for example – one week out from scheduled disclosure/fix date we send the patches to distros so they have time to get their packages tested and ready, and do a “security release coming in seven days” message to the release announcements list. And that was set up based largely on what I found when researching how other projects did it.

            1. 1

              It night be standard but it still means there’s a while week where people involved in OpenSSL, sisters, etc. can start attacks before anyone else even has the possibility to update.

              Thar also means people with good reasons too use during cryptography are at risk. I also wouldn’t be surprised if lots of institutions including ones in authoritarian regimes have done their best to be part in that elected group. If not directly then through contacts. It’s not like having such information wouldn’t be big business.

              A week seems just long enough to make use of such kind of nformation.

              Of course I’m not saying it couldn’t be worse. At least in this case a downgrade might be something to migrate the risk in some instances. But given that it’s a major release and there’s new APIs it might not be so trivial.

              1. 5

                On the other hand, if there wasn’t a weeks advance notice, many people, including distros, would not have enough time to prepare and test fixes, leaving everyone with no possibility to update at all!

                …there’s a while week where people involved in OpenSSL, sisters, etc. can start attacks…

                Everyone has different threat models and trust circles, but if you are concerned that OpenSSL folks are going to start using their inside knowledge to attack people you should probably switch TLS libraries.

                1. 1

                  The insiders aren’t just the OpenSSL people though. They are distros, vendors, etc.

                  On the other hand, if there wasn’t a weeks advance notice, many people, including distros, would not have enough time to prepare and test fixes, leaving everyone with no possibility to update at all!

                  Isn’t testing fixes the job of the project? Shouldn’t the OpenSSL team fix and test issues before announcing and telling everyone to update?

                  My point is that the embargo should be small(er) and as short as possible to not have an uneven ground of people aware of the issue and those who don’t for long, raising the likelihood of exploitation.

                  On top of that my assumption is that this is yet another small patch, not in need of huge amounts of testing, because something along the lines of some bounds checking not occurring, something overflowing, etc. that is a small obvious patch essentially without side effects. If that is the case, someone on the OpenSSL team would fix it, have someone else on the OpenSSL team review it, run it with a couple of pieces of software, to additionally verify nothing has been missed, announce that a serious issue has been found and push it out by the next day. Software and distribution maintainers essentially increase a minor version number, rebuild, done.

                  Of course if this is a more complex issue/patch or even requires any code change in projects depending on the library that’s a different story. I assume it’s not though.

                  So it’s not that I necessarily think that “OpenSSL folks are going to start using their inside knowledge to attack people”. One kind of has to, when using OpenSSL, and pretty much everyone somehow depends on it in their daily life. It’s everyone that information is shared with beforehand, like distros, etc.

                  Another topic, but that’s more a personal opinion is that usually smaller projects remain outside of the embargo. So again, it’s really not just about trusting the OpenSSL team, but everyone they inform (and everyone that they might inform) on top of it.