Object.safeAssign
# Mike Sherov (4 years ago)
After a conversation on twitter ( 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.
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 <mike.sherov at gmail.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20200501/2bfb2a07/attachment.html>
# Isiah Meadows (4 years ago)
Missed the list. Also, it apparently does trigger setters. Crossed it up with spread properties (which don't).
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 <contact at isiahmeadows.com> 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 <mike.sherov at gmail.com> 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 >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > -- > ----- > > Isiah Meadows > contact at isiahmeadows.com > www.isiahmeadows.com > -- ----- Isiah Meadows contact at isiahmeadows.com www.isiahmeadows.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20200501/9942bdcb/attachment.html>
# Bob Myers (4 years ago)
Can you explain or support your assertion of "increased prevalence"?
Can you explain or support your assertion of "increased prevalence"? On Fri, May 1, 2020, 05:51 Mike Sherov <mike.sherov at gmail.com> 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 > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20200501/a994d727/attachment-0001.html>
# Jordan Harband (4 years ago)
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?
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 <rtm at gol.com> wrote: > Can you explain or support your assertion of "increased prevalence"? > > On Fri, May 1, 2020, 05:51 Mike Sherov <mike.sherov at gmail.com> 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 >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20200501/53b3b127/attachment.html>
# Mike Sherov (4 years ago)
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: cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prototype+pollution including another new one in lodash today. snyk.io/vuln/npm:lodash:20180130
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 <contact at isiahmeadows.com> 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 <contact at isiahmeadows.com> > 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 <mike.sherov at gmail.com> 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 >>> es-discuss at mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> -- >> ----- >> >> Isiah Meadows >> contact at isiahmeadows.com >> www.isiahmeadows.com >> > -- > ----- > > Isiah Meadows > contact at isiahmeadows.com > www.isiahmeadows.com > -- Mike Sherov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20200501/7a9957d3/attachment.html>
# Mike Sherov (4 years ago)
I'll drop this thread for now, and come back when I've actually thought this all through. Sorry for wasting your time!
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 <mike.sherov at gmail.com> 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 <contact at isiahmeadows.com> > 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 <contact at isiahmeadows.com> >> 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 <mike.sherov at gmail.com> 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 >>>> es-discuss at mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> -- >>> ----- >>> >>> Isiah Meadows >>> contact at isiahmeadows.com >>> www.isiahmeadows.com >>> >> -- >> ----- >> >> Isiah Meadows >> contact at isiahmeadows.com >> www.isiahmeadows.com >> > > > -- > Mike Sherov > > -- Mike Sherov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20200501/e29863e2/attachment-0001.html>
# Augusto Moura (4 years ago)
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 <mike.sherov at gmail.com>
escreveu:
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 <mike.sherov at gmail.com> 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 <contact at isiahmeadows.com> > 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 <contact at isiahmeadows.com> >> 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 <mike.sherov at gmail.com> 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 >>>> es-discuss at mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> -- >>> ----- >>> >>> Isiah Meadows >>> contact at isiahmeadows.com >>> www.isiahmeadows.com >>> >> -- >> ----- >> >> Isiah Meadows >> contact at isiahmeadows.com >> www.isiahmeadows.com >> > > > -- > Mike Sherov > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- Atenciosamente, Augusto Borges de Moura -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20200508/909f20b1/attachment.html>
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:
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