On Fri, Oct 30, 2020 at 11:15:31AM +0100, js-openbsd-m...@webkeks.org wrote: > > Am 30.10.2020 um 01:28 schrieb Theo de Raadt <dera...@openbsd.org>: > > > > js-openbsd-m...@webkeks.org wrote: > > > >> I just saw > >> https://ftp.openbsd.org/pub/OpenBSD/patches/6.8/common/002_icmp6.patch.sig, > >> however, it's unclear from the description and the context around the > >> patch if this is a read after free or write after free (or both). > > > > I think it is fair you can study the code yourself and make your own > > factual determination. > > As said, it is not immediately obvious to me if this is just read-after-free > or also write-after-free. Hence I was hoping someone who either wrote the fix > or who is more familiar with the code than me could enlighten me. It's not > one of those obvious fixes where you see the buffer overflow just below. > > >> In the case of a write after free, would this change "Only two remote > >> holes in the default install, in a heck of a long time!" to three? Or > >> does it need more than IPv6 being configured? > > > > First off, is ipv6 deployment really part of the default install? No, > > not really it takes some effort to configure v6, it is not natural. > > The same could be said for v4 though, so is networking not considered part of > the default install? How did the 2 remote holes happen without network then, > though? Please help me understand, because the installer asked me for IPv6 > just as it did for IPv4, so I would consider them both equally default. > > > It is active on the loopback, but then that's not remote.. > > What about link-local IPv6? That's active by default, isn't it? > > In any case, are you saying just removing the inet6 address from all > interfaces would be a sufficient workaround if an immediate update is not > possible? (Of course, only as a workaround until it's possible) > > > But there's a bigger assumption in your mail: > > > > We've released the errata as security because it is possibly exploitable > > or could cause a crash, and we have a rapid fix release process. It was > > released without even seeing any evidence of a remote crash, nor any > > evidence of a remote exploit. Incorrect code gets fixed, and if we > > judge it important we release a fix to the public in expedited fashion, > > and apparently get judged for doing so. > > And that is good. But it still does not help in determining the impact, i.e.: > Was this just a remote DoS (read-after-free) or a potential RCE > (write-after-free)? For the latter, I would just update, for the former, time > to reinstall my machines. > > > Now that the fix is released and deployed by most openbsd users, we > > quickly become uncurious and head back to other work. The only > > conversations related to this are asking how we can harden the mbuf > > layer to avoid similar issues in the future. > > Which seems like a good strategy, but still, don't you think it's valuable to > know what the maximum impact was in the worst-case? I fully agree with being > over cautious and calling something an RCE rather than a DoS when it's > unclear (a write-after-free could look like a DoS at first and turn out to be > RCE, after all), but some things are limited in impact (a read-after-free > usually isn't more than a DoS). > > > I guess many other operating systems would wait weeks or months to > > collect all the "facts" and make a fancy disclosure, but we shipped > > source and binary fixes in just over 24 hours. > > Again, I think that time is better spent fixing it fast than writing a fancy > disclosure. I am merely curious if this was just read-after-free or > write-after-free (or both) to make my own risk determination. > > > So, is it a remote crash? Possibly, but we'd like to see a packet > > that causes it. > > > > Next after that, is it a remote exploit? > > > > I think it is fair to wait for facts. > > So, what you're saying is, it is only tagged as a security out of caution, > not because it necessarily is exploitable? > > > I also think you are a troll. > > Not everybody trying to understand the impact of a security bug is a troll ;). > > I merely brought up the 2 remote holes because I was wondering if this could > be used as a signal that it's not remotely exploitable, as it's still 2.
Honestly, as one of the devs involved with this security fix, I can tell you that I don't know. It is a use-after-free in some situations. Is it reachable from remote? I don't know. Is it reachable from local? Maybe. Is the use-after-free exploitable? Damn hard to tell, it is for sure not easy. Was there a PoC exploit? No, there was no PoC. I will not invest hours of my time to figure out something that does not really interest me. The fix is out, everyone can update. -- :wq Claudio
