Prototype poisoning (2019)(fastify.dev)
fastify.dev
Prototype poisoning (2019)
https://fastify.dev/docs/latest/Guides/Prototype-Poisoning/
8 comments
Can you elucidate the very, very good reasons (at a high level) or link to somewhere that you feel is authoritative that does?
(I agree that if you don’t say ‘security update’ you may get fewer updates.)
(I agree that if you don’t say ‘security update’ you may get fewer updates.)
Sorry, it took me awhile to respond because I struggled to articulate this in a way that didn’t simply appeal to “this is the way literally everyone does it for obvious reasons” appeal-to-crowds (though it is, in fact, near-universal practice). The reasons I’m familiar with are below; there are likely others I’m not listing:
Because bad actors should be presumed to already be exploiting the vulnerability, so anything less than prudently fast and loud disclosure to as many of your users (direct or transitive) as possible increases the likely damage caused by the vulnerability.
Because, as you say, urgent needed-for-security updates are likely to motivate more people to update quickly. In addition to the scare factor, consider that many people want to update dependencies but can’t get the work prioritized. For those folks, a scary security bulletin may be what they need to get the ticket moved to the front of the queue.
Because release diffs, even “sneaky” semver-trivial ones, of popular libraries are some of the most scrutinized code by bad actors, both because new releases often contain vulnerabilities that can be exploited before anyone else knows about them, and because bad actors know about the sneaky-release trick so they know to look for code like this, even if you try to obfuscate it.
Because the potential downside of getting caught sneaking a fix into a trivial release when you knew that there was a significant vulnerability out there is much worse than the downside of telling all your users that your software was insecure before so-and-so version. If folks savvy to what you did after the fact and you respond with “well you should have been keeping your transitives updated anyway”, that will buy you precisely zero goodwill with people who have suffered a data breach. The best you can do is document loudly and publicly that you responded to the vulnerability as well as possible as soon as you learned about it, so that nobody can accuse you of dragging your feet or of sweeping it under the rug. Yeah, you’re gonna lose some users when you notify folks about a vuln, but you’re likely to lose more users if you end up known as someone who conceals vulnerabilities.
Because a lot of code that may be using your library in a vulnerable way is closed-source, so statements like "hapi was the only major attack vector” are not something you can accurately make. Sure, maybe that’s a reason why more folks should participate in Free Software. But those companies and their customers that just got hacked don’t care about that distinction, they care that you could have been louder about the issue--loud enough that automated CVE-found-in-library-you-use scanners they run against their proprietary codebases set off alarm bells--and were not.
Again, because you should assume that bad actors are already exploiting the issue by the time you discover it. It’s tempting to assume that subtle vulnerabilities aren’t being exploited because they’re subtle; that’s usually false--bad actors have time and regrettably impressive expertise in this area. It’s also tempting to assume that if exploits in the wild aren’t making headlines/getting reported to you, they aren’t happening; that’s usually false--many companies don’t know they’re being hacked until long after it happens, or ever. Even if users do know they were compromised, often don’t know what the vector was, so they can't attribute it to your software. Even if they do know the vector was your software, they often don’t reach out to the maintainers (seriously, the amount of monkey-patch/internal-and-dubiously-legal-fork code I’ve seen that remediates very significant security issues in popular libraries is large. Some of those libraries had corporate owners and impossible-to-miss instructions for security issue reporting, but the users chose to monkey patch instead). Sometimes they want to reach out but can't, for fear of internal reprisal, or due to language barriers, or some other reason.
Because bad actors should be presumed to already be exploiting the vulnerability, so anything less than prudently fast and loud disclosure to as many of your users (direct or transitive) as possible increases the likely damage caused by the vulnerability.
Because, as you say, urgent needed-for-security updates are likely to motivate more people to update quickly. In addition to the scare factor, consider that many people want to update dependencies but can’t get the work prioritized. For those folks, a scary security bulletin may be what they need to get the ticket moved to the front of the queue.
Because release diffs, even “sneaky” semver-trivial ones, of popular libraries are some of the most scrutinized code by bad actors, both because new releases often contain vulnerabilities that can be exploited before anyone else knows about them, and because bad actors know about the sneaky-release trick so they know to look for code like this, even if you try to obfuscate it.
Because the potential downside of getting caught sneaking a fix into a trivial release when you knew that there was a significant vulnerability out there is much worse than the downside of telling all your users that your software was insecure before so-and-so version. If folks savvy to what you did after the fact and you respond with “well you should have been keeping your transitives updated anyway”, that will buy you precisely zero goodwill with people who have suffered a data breach. The best you can do is document loudly and publicly that you responded to the vulnerability as well as possible as soon as you learned about it, so that nobody can accuse you of dragging your feet or of sweeping it under the rug. Yeah, you’re gonna lose some users when you notify folks about a vuln, but you’re likely to lose more users if you end up known as someone who conceals vulnerabilities.
Because a lot of code that may be using your library in a vulnerable way is closed-source, so statements like "hapi was the only major attack vector” are not something you can accurately make. Sure, maybe that’s a reason why more folks should participate in Free Software. But those companies and their customers that just got hacked don’t care about that distinction, they care that you could have been louder about the issue--loud enough that automated CVE-found-in-library-you-use scanners they run against their proprietary codebases set off alarm bells--and were not.
Again, because you should assume that bad actors are already exploiting the issue by the time you discover it. It’s tempting to assume that subtle vulnerabilities aren’t being exploited because they’re subtle; that’s usually false--bad actors have time and regrettably impressive expertise in this area. It’s also tempting to assume that if exploits in the wild aren’t making headlines/getting reported to you, they aren’t happening; that’s usually false--many companies don’t know they’re being hacked until long after it happens, or ever. Even if users do know they were compromised, often don’t know what the vector was, so they can't attribute it to your software. Even if they do know the vector was your software, they often don’t reach out to the maintainers (seriously, the amount of monkey-patch/internal-and-dubiously-legal-fork code I’ve seen that remediates very significant security issues in popular libraries is large. Some of those libraries had corporate owners and impossible-to-miss instructions for security issue reporting, but the users chose to monkey patch instead). Sometimes they want to reach out but can't, for fear of internal reprisal, or due to language barriers, or some other reason.
> If you rely on code I maintain, this is exactly the level of support, quality, and commitment you want (and lets be honest — expect)
This article is pretty funny. Talks about responsible disclosure, pumps the tires of his skill & efforts... and also implies the right solution to a devastating security issue is to sneak the fix out.
What a world.
This article is pretty funny. Talks about responsible disclosure, pumps the tires of his skill & efforts... and also implies the right solution to a devastating security issue is to sneak the fix out.
What a world.
Forget it, Jake. It's Javascript town.
I particularly enjoyed identifying a validation tool that ignores the prototype as a feature, not a glaring failure to be a validation tool, and the initial plan to change that under the name of refactoring to avoid the whole semver change a number problem.
Meets my priors about the javascript ecosystem. I'm not totally sure whether this is satire.
The GitHub for "joi" looks like a product, claims "The most powerful data validation library for JS". Associated issues amount to "doesn't work" in various dimensions. Which might also be an elaborate joke about how javascript validation is invalid.
Meets my priors about the javascript ecosystem. I'm not totally sure whether this is satire.
The GitHub for "joi" looks like a product, claims "The most powerful data validation library for JS". Associated issues amount to "doesn't work" in various dimensions. Which might also be an elaborate joke about how javascript validation is invalid.
I suppose that's the issue with JS, a map and an object are the same thing. You write this code to evaluate objects, but you're thinking maps.
To mitigate it, use `null` as prototype:
Object.create(null)
function PersonModel(person) {
const p = Object.assign(Object.create(null), person)
p.name ??= ''
p.age ??= 0
return p
}
const p1 = PersonModel(JSON.parse('{"__proto__": { "Mallory": 666 }}'))
p1.Mallory // undefined
> Sneaking a fix isn't the hardest thing to accomplish. If you combine it with an otherwise purposeless refactor of the code, and throw in a few unrelated bug fixes and maybe a cool new feature, you can publish a new version without drawing attention to the real issue being fixed.
Jesus. That is not how vulnerability disclosure and zero-day management work in most projects for very, very good reasons.
If you're considering "sneaking out" a fix as part of a larger bundle of redactors, don't. Notify your users and prominent dependent projects, agree (with adults in the room) on how and where you'll perform coordinated disclosure, and take your lumps. To do otherwise is to basically guarantee that larger numbers of bad actors will be exploiting your issue earlier and in worse ways than you could imagine.