Fix prototype pollution for Hapi v16

[mcollina]

As reported in https://hackerone.com/reports/310439, can we have the security fix backported to Hoek 4/Hapi v16 ASAP? Those are vulnerable, still supported, and highly used in production systems.

Snyk is currently flagging the remediation has "upgrade to hapi v17" which is not a good remediation strategy for this type of security fix (and have an extra cost).

[nlf]

I commented out of band, but it's worth mentioning here that actually exploiting this vulnerability in a hapi server requires that a user either neglect to validate user input entirely, or allow unknown keys on their payloads and pass one of those unvalidated/undervalidated payloads to one of merge, applyToDefault, or applyToDefaultWithShallow so this isn't as severe as it may sound on the surface.

That said, hoek@4.2.1 has been published with this fix backported.

[mcollina]

Thanks for the release!

[dgonzalez]

On my opinion prototype pollution can lead into a form of remote code execution hence fixing it makes a lot of sense. I deal with a lot of code from the security point of view and input validation is often missing or incomplete (which leads into why injection is the number one on the OWASP top 10). Also I don't think it is a low severity bug.

I have attached a screenshot on the CVSS score calculation on the best case scenario given that it is exploitable via network and assuming that the application needs credentials to login (which might not even be the case).

I can see that the CVE has been reserved but not completed in here: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3728 so I am not sure whether it will continue being a low.

[nlf]

It has been fixed.

To further discuss, while yes prototype pollution itself can lead to remote code execution this is a more difficult case wherein the attack must survive a JSON.parse. This means you can't pass in a function directly. This leaves you in a position where you could overwrite existing functions with a primitive value, causing a denial of service, but the likelihood of getting actual RCE is slim unless something somewhere in your request chain is running eval or similar on the parsed payload to convert a string representing a function into an actual function. That does not happen in this module, and as such the scope of that type of attack is outside of this finding.

[dgonzalez]

That makes perfect sense. Thanks for the explanation!

…

On 15 Feb 2018 20:46, "Nathan LaFreniere" ***@***.***> wrote: It has been fixed. To further discuss, while yes prototype pollution itself can lead to remote code execution this is a more difficult case wherein the attack must survive a JSON.parse. This means you can't pass in a function directly. This leaves you in a position where you could overwrite existing functions with a primitive value, causing a denial of service, but the likelihood of getting actual RCE is slim unless *something* somewhere in your request chain is running eval or similar on the parsed payload to convert a string representing a function into an actual function. That does not happen in this module, and as such the scope of that type of attack is outside of this finding. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#230 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHkOrPcSxXoGnwQM6lWau1p2QK9FsDqks5tVJelgaJpZM4SGiqM> .