Re: Object.safeAssign
The real risk are the exploits that are not made public In my opinion __proto__ as a whole should be the one to be dropped, unfortunately this is not happening in the near future. My hope is that one day, years after now, the usage is so low that it can be removed from the language. That would solve a big list of exploits. I don't see that much of a problem with setting constructor or prototype though. Maybe we should promote a more aggressive deprecation? Discuss with browsers to log warnings and make more explicit in documentation the hazards with counting on it. Anyway maybe the problem are not serious enough to get that attention. Em sex., 1 de mai. de 2020 às 13:31, Mike Sherov escreveu: > So, I've firmed up my understanding here. The goal of a safeAssign would > not be to prevent all prototype pollution, which seems impossible to solve > generically at a library level. But rather to prevent the assignment > specifically of `__proto__`, `constructor`, and `prototype` properties of > the target. This mitigates a specific, well understood vulnerability: > manipulating a prototype with a "src" object that can surive a > JSON.parse(JSON.stringify(src)) roundtrip. > > > Can you explain or support your assertion of "increased prevalence"? > > I should probably have said visibility, not prevalence. MITRE shows 31 > CVEs for prototype pollution: > https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prototype+pollution including > another new one in lodash today. https://snyk.io/vuln/npm:lodash:20180130 > > On Fri, May 1, 2020 at 12:13 PM Isiah Meadows > wrote: > >> Missed the list. Also, it apparently does trigger setters. Crossed it up >> with spread properties (which don't). >> >> On Fri, May 1, 2020 at 06:28 Isiah Meadows >> wrote: >> >>> I thought `Object.assign`already used the `Object.keys` + >>> `Object.defineProperty` algorithms under the hood and thus were immune to >>> this. Am I misremembering or misunderstanding? >>> >>> On Fri, May 1, 2020 at 05:51 Mike Sherov wrote: >>> Given the increased prevalence of prototype pollution vulnerabilities in many popular javascript libraries, is it time to reconsider the fact that Object.assign allows for prototype pollution by default? I see two options: 1. Change Object.assign to disallow PP by default. Look at real world usages and see what would break if prototype pollution was disabled? Almost certainly this is not a viable option, but wanted to raise it here just in case there was appetite to do so. 2. Introduce something like Object.safeAssign (bikeshedding aside), that is the same as Object.assign except is safe from prototype pollution. The reason I think this is important is that the common advice of freezing Object.prototype is something only the end user can do, and not something a library can do. Yes, a library can also know to do its own PP fixes, but having a reified way to avoid PP allows us to have a secure-by-default method in the language. Thoughts? Mike Sherov ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss >>> -- >>> - >>> >>> Isiah Meadows >>> [email protected] >>> www.isiahmeadows.com >>> >> -- >> - >> >> Isiah Meadows >> [email protected] >> www.isiahmeadows.com >> > > > -- > Mike Sherov > > ___ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Atenciosamente, Augusto Borges de Moura ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
Re: Object.safeAssign
I'll drop this thread for now, and come back when I've actually thought this all through. Sorry for wasting your time! On Fri, May 1, 2020 at 12:30 PM Mike Sherov wrote: > So, I've firmed up my understanding here. The goal of a safeAssign would > not be to prevent all prototype pollution, which seems impossible to solve > generically at a library level. But rather to prevent the assignment > specifically of `__proto__`, `constructor`, and `prototype` properties of > the target. This mitigates a specific, well understood vulnerability: > manipulating a prototype with a "src" object that can surive a > JSON.parse(JSON.stringify(src)) roundtrip. > > > Can you explain or support your assertion of "increased prevalence"? > > I should probably have said visibility, not prevalence. MITRE shows 31 > CVEs for prototype pollution: > https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prototype+pollution including > another new one in lodash today. https://snyk.io/vuln/npm:lodash:20180130 > > On Fri, May 1, 2020 at 12:13 PM Isiah Meadows > wrote: > >> Missed the list. Also, it apparently does trigger setters. Crossed it up >> with spread properties (which don't). >> >> On Fri, May 1, 2020 at 06:28 Isiah Meadows >> wrote: >> >>> I thought `Object.assign`already used the `Object.keys` + >>> `Object.defineProperty` algorithms under the hood and thus were immune to >>> this. Am I misremembering or misunderstanding? >>> >>> On Fri, May 1, 2020 at 05:51 Mike Sherov wrote: >>> Given the increased prevalence of prototype pollution vulnerabilities in many popular javascript libraries, is it time to reconsider the fact that Object.assign allows for prototype pollution by default? I see two options: 1. Change Object.assign to disallow PP by default. Look at real world usages and see what would break if prototype pollution was disabled? Almost certainly this is not a viable option, but wanted to raise it here just in case there was appetite to do so. 2. Introduce something like Object.safeAssign (bikeshedding aside), that is the same as Object.assign except is safe from prototype pollution. The reason I think this is important is that the common advice of freezing Object.prototype is something only the end user can do, and not something a library can do. Yes, a library can also know to do its own PP fixes, but having a reified way to avoid PP allows us to have a secure-by-default method in the language. Thoughts? Mike Sherov ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss >>> -- >>> - >>> >>> Isiah Meadows >>> [email protected] >>> www.isiahmeadows.com >>> >> -- >> - >> >> Isiah Meadows >> [email protected] >> www.isiahmeadows.com >> > > > -- > Mike Sherov > > -- Mike Sherov ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
Re: Object.safeAssign
So, I've firmed up my understanding here. The goal of a safeAssign would not be to prevent all prototype pollution, which seems impossible to solve generically at a library level. But rather to prevent the assignment specifically of `__proto__`, `constructor`, and `prototype` properties of the target. This mitigates a specific, well understood vulnerability: manipulating a prototype with a "src" object that can surive a JSON.parse(JSON.stringify(src)) roundtrip. > Can you explain or support your assertion of "increased prevalence"? I should probably have said visibility, not prevalence. MITRE shows 31 CVEs for prototype pollution: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prototype+pollution including another new one in lodash today. https://snyk.io/vuln/npm:lodash:20180130 On Fri, May 1, 2020 at 12:13 PM Isiah Meadows wrote: > Missed the list. Also, it apparently does trigger setters. Crossed it up > with spread properties (which don't). > > On Fri, May 1, 2020 at 06:28 Isiah Meadows > wrote: > >> I thought `Object.assign`already used the `Object.keys` + >> `Object.defineProperty` algorithms under the hood and thus were immune to >> this. Am I misremembering or misunderstanding? >> >> On Fri, May 1, 2020 at 05:51 Mike Sherov wrote: >> >>> Given the increased prevalence of prototype pollution vulnerabilities in >>> many popular javascript libraries, is it time to reconsider the fact that >>> Object.assign allows for prototype pollution by default? >>> >>> I see two options: >>> 1. Change Object.assign to disallow PP by default. Look at real world >>> usages and see what would break if prototype pollution was disabled? Almost >>> certainly this is not a viable option, but wanted to raise it here just in >>> case there was appetite to do so. >>> 2. Introduce something like Object.safeAssign (bikeshedding aside), that >>> is the same as Object.assign except is safe from prototype pollution. >>> >>> The reason I think this is important is that the common advice of >>> freezing Object.prototype is something only the end user can do, and not >>> something a library can do. >>> >>> Yes, a library can also know to do its own PP fixes, but having a >>> reified way to avoid PP allows us to have a secure-by-default method in the >>> language. >>> >>> Thoughts? >>> >>> Mike Sherov >>> ___ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> -- >> - >> >> Isiah Meadows >> [email protected] >> www.isiahmeadows.com >> > -- > - > > Isiah Meadows > [email protected] > www.isiahmeadows.com > -- Mike Sherov ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
Re: Object.safeAssign
I'm confused about that as well; there were a spate of CVEs about it a year or two ago (2 or 3 of my libraries were "affected"), but just like the minimist/mkdirp ones, they were only actually vulnerabilities for a minority of the use cases. Have there been any recent vulnerabilities you're aware of? On Fri, May 1, 2020 at 9:22 AM Bob Myers wrote: > Can you explain or support your assertion of "increased prevalence"? > > On Fri, May 1, 2020, 05:51 Mike Sherov wrote: > >> Given the increased prevalence of prototype pollution vulnerabilities in >> many popular javascript libraries, is it time to reconsider the fact that >> Object.assign allows for prototype pollution by default? >> >> I see two options: >> 1. Change Object.assign to disallow PP by default. Look at real world >> usages and see what would break if prototype pollution was disabled? Almost >> certainly this is not a viable option, but wanted to raise it here just in >> case there was appetite to do so. >> 2. Introduce something like Object.safeAssign (bikeshedding aside), that >> is the same as Object.assign except is safe from prototype pollution. >> >> The reason I think this is important is that the common advice of >> freezing Object.prototype is something only the end user can do, and not >> something a library can do. >> >> Yes, a library can also know to do its own PP fixes, but having a reified >> way to avoid PP allows us to have a secure-by-default method in the >> language. >> >> Thoughts? >> >> Mike Sherov >> ___ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > ___ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
Re: Object.safeAssign
Can you explain or support your assertion of "increased prevalence"? On Fri, May 1, 2020, 05:51 Mike Sherov wrote: > Given the increased prevalence of prototype pollution vulnerabilities in > many popular javascript libraries, is it time to reconsider the fact that > Object.assign allows for prototype pollution by default? > > I see two options: > 1. Change Object.assign to disallow PP by default. Look at real world > usages and see what would break if prototype pollution was disabled? Almost > certainly this is not a viable option, but wanted to raise it here just in > case there was appetite to do so. > 2. Introduce something like Object.safeAssign (bikeshedding aside), that > is the same as Object.assign except is safe from prototype pollution. > > The reason I think this is important is that the common advice of freezing > Object.prototype is something only the end user can do, and not something a > library can do. > > Yes, a library can also know to do its own PP fixes, but having a reified > way to avoid PP allows us to have a secure-by-default method in the > language. > > Thoughts? > > Mike Sherov > ___ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
Re: Object.safeAssign
Missed the list. Also, it apparently does trigger setters. Crossed it up with spread properties (which don't). On Fri, May 1, 2020 at 06:28 Isiah Meadows wrote: > I thought `Object.assign`already used the `Object.keys` + > `Object.defineProperty` algorithms under the hood and thus were immune to > this. Am I misremembering or misunderstanding? > > On Fri, May 1, 2020 at 05:51 Mike Sherov wrote: > >> Given the increased prevalence of prototype pollution vulnerabilities in >> many popular javascript libraries, is it time to reconsider the fact that >> Object.assign allows for prototype pollution by default? >> >> I see two options: >> 1. Change Object.assign to disallow PP by default. Look at real world >> usages and see what would break if prototype pollution was disabled? Almost >> certainly this is not a viable option, but wanted to raise it here just in >> case there was appetite to do so. >> 2. Introduce something like Object.safeAssign (bikeshedding aside), that >> is the same as Object.assign except is safe from prototype pollution. >> >> The reason I think this is important is that the common advice of >> freezing Object.prototype is something only the end user can do, and not >> something a library can do. >> >> Yes, a library can also know to do its own PP fixes, but having a reified >> way to avoid PP allows us to have a secure-by-default method in the >> language. >> >> Thoughts? >> >> Mike Sherov >> ___ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > -- > - > > Isiah Meadows > [email protected] > www.isiahmeadows.com > -- - Isiah Meadows [email protected] www.isiahmeadows.com ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
Re: Object.safeAssign
After a conversation on twitter ( https://twitter.com/mikesherov/status/1256193257626836998?s=20), to firm up what I'm proposing here is that preventing prototype pollution isn't really possible with Object.assign as is because it would have to change to not execute setters, which is a non-starter. I'm mostly left with a desire to discuss/learn what it would actually take to make a prototype pollution safe version of Object.assign, and this may not be the forum for that. On Fri, May 1, 2020 at 8:50 AM Mike Sherov wrote: > Given the increased prevalence of prototype pollution vulnerabilities in > many popular javascript libraries, is it time to reconsider the fact that > Object.assign allows for prototype pollution by default? > > I see two options: > 1. Change Object.assign to disallow PP by default. Look at real world > usages and see what would break if prototype pollution was disabled? Almost > certainly this is not a viable option, but wanted to raise it here just in > case there was appetite to do so. > 2. Introduce something like Object.safeAssign (bikeshedding aside), that > is the same as Object.assign except is safe from prototype pollution. > > The reason I think this is important is that the common advice of freezing > Object.prototype is something only the end user can do, and not something a > library can do. > > Yes, a library can also know to do its own PP fixes, but having a reified > way to avoid PP allows us to have a secure-by-default method in the > language. > > Thoughts? > > Mike Sherov -- Mike Sherov ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
