To close this thread, I found this: https://twitter.com/m00nbsd/status/1321524807473782784
> Am 30.10.2020 um 11:15 schrieb js-openbsd-m...@webkeks.org: > >> 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. > > -- > Jonathan >
