Re: Impact of 002_icmp6.patch
he is real ... but from the Linux side :) but maybe the second troll of the thread. I cannot imagine anyone being that ignorant. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 30 October 2020 13:36, Florian Obser wrote: > On Fri, Oct 30, 2020 at 11:58:41AM +0100, Martin Schröder wrote: > > > Am Fr., 30. Okt. 2020 um 11:54 Uhr schrieb Denis Fondras > > open...@ledeuns.net: > > > > > Please, fix your tweet. The default install answer for IPv6 is 'none'. > > > > This borders on "switch off v6 for security reasons", which would be just > > wrong. > > since you like to put words in our mouths... > > > I'd much prefer that the project adopted a" v6 first, vintage ip > > second" approach. > > But I'm not a dev. > > ... you are saying if you were a dev things would be better? > > Thanks for ignoring all the hard work we put into making IPv6 better > in OpenBSD. > > > Best > > Martin > > -- > > I'm not entirely sure you are real.
Re: Impact of 002_icmp6.patch
we battered the IETF, and even government interest, on this for years back in late 2007, and beyond ... any remember IPv5? :) IPv6 is a massive security risk in so many ways. No real NAT so you are distributed into the worldwide even if billions of addresses there is no protection. There is NAT64 / DS-lite so you don't need IPv6, even PCP, 1:1 million ratios :) I could write a book on IPv6 insecurities, failings of the open multicast, RA timers, NPD holes and link local omg 30 years I have written protocols, solutions and systems, my advice is switch IPv6 off by default! And anyone who suggests different is off my Christmas list and Santa will put you on the naughty list. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 30 October 2020 11:58, Martin Schröder wrote: > Am Fr., 30. Okt. 2020 um 11:54 Uhr schrieb Denis Fondras open...@ledeuns.net: > > > Please, fix your tweet. The default install answer for IPv6 is 'none'. > > This borders on "switch off v6 for security reasons", which would be just > wrong. > > I'd much prefer that the project adopted a" v6 first, vintage ip > second" approach. > But I'm not a dev. > > Best > Martin
Re: Impact of 002_icmp6.patch
Am Fr., 30. Okt. 2020 um 13:36 Uhr schrieb Florian Obser : > On Fri, Oct 30, 2020 at 11:58:41AM +0100, Martin Schröder wrote: > > I'd much prefer that the project adopted a" v6 first, vintage ip > > second" approach. > > But I'm not a dev. > > ... you are saying if you were a dev things would be better? Now who's putting words in whose mouth? :-) I respect your decisions. And since I'm not a dev, my words don't carry much value here. > Thanks for ignoring all the hard work we put into making IPv6 better > in OpenBSD. I'm not. Thanks for your work. Best Martin
Re: Impact of 002_icmp6.patch
On Fri, Oct 30, 2020 at 11:58:41AM +0100, Martin Schröder wrote: > Am Fr., 30. Okt. 2020 um 11:54 Uhr schrieb Denis Fondras > : > > Please, fix your tweet. The default install answer for IPv6 is 'none'. > > This borders on "switch off v6 for security reasons", which would be just > wrong. since you like to put words in our mouths... > > I'd much prefer that the project adopted a" v6 first, vintage ip > second" approach. > But I'm not a dev. ... you are saying if you were a dev things would be better? Thanks for ignoring all the hard work we put into making IPv6 better in OpenBSD. > > Best > Martin > -- I'm not entirely sure you are real.
Re: Impact of 002_icmp6.patch
On Fri, Oct 30, 2020 at 11:15:31AM +0100, js-openbsd-m...@webkeks.org wrote: | What about link-local IPv6? That's active by default, isn't it? It is not. You need to enable IPv6 on an interface to get a link-local address on it, only the loopback interface is special in this sense that it gets ::1 (localhost) and fe80::1%lo0 (link-local for the loopback interface) by just bringing it up. This has been the case since 23 June 2014 (5.6 was the first release with this change): http://cvsweb.openbsd.org/src/sys/net/if.c?rev=1.291=text/x-cvsweb-markup Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Impact of 002_icmp6.patch
On Fri, Oct 30, 2020 at 11:58:41AM +0100, Martin Schröder wrote: > Am Fr., 30. Okt. 2020 um 11:54 Uhr schrieb Denis Fondras > : > > Please, fix your tweet. The default install answer for IPv6 is 'none'. > > This borders on "switch off v6 for security reasons", which would be just > wrong. > > I'd much prefer that the project adopted a" v6 first, vintage ip > second" approach. > But I'm not a dev. > The question is 'Is IPv6 enabled by default ?'. Fact tells NO. The rest is a matter of opinion.
Re: Impact of 002_icmp6.patch
Am Fr., 30. Okt. 2020 um 11:54 Uhr schrieb Denis Fondras : > Please, fix your tweet. The default install answer for IPv6 is 'none'. This borders on "switch off v6 for security reasons", which would be just wrong. I'd much prefer that the project adopted a" v6 first, vintage ip second" approach. But I'm not a dev. Best Martin
Re: Impact of 002_icmp6.patch
On Fri, Oct 30, 2020 at 11:36:33AM +0100, js-openbsd-m...@webkeks.org wrote: > To close this thread, I found this: > https://twitter.com/m00nbsd/status/1321524807473782784 > Please, fix your tweet. The default install answer for IPv6 is 'none'.
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
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 : > > > > 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
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
Re: Impact of 002_icmp6.patch
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. > 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. It is active on the loopback, but then that's not remote.. 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. 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. 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. 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. I also think you are a troll.
