Re: Impact of 002_icmp6.patch
> 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. Thx, that was the answer I was hoping for! :) -- Jonathan
Re: Impact of 002_icmp6.patch
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 : >> >> 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 >
Re: Impact of 002_icmp6.patch
> Am 30.10.2020 um 01:28 schrieb Theo de Raadt : > > 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
Impact of 002_icmp6.patch
Hi! 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). 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? -- Jonathan
