Is hoek prototype pollution vulnerable for firebase package?

Question

This is regarding the prototype pollution security vulnerability in a npm packages 'hoek' which is a sub dependency of [email protected]

Hackone Url: https://hackerone.com/reports/310439

Snyk Url: https://snyk.io/test/npm/firebase/3.9.0?severity=high&severity=medium&severity=low

Although firebase team has fixed it in this pr: https://github.com/firebase/firebase-js-sdk/issues/515 in package [email protected]

I want to understand if this is really a security threat for firebase, because people depending on [email protected] can't directly just upgrade to @4.x.x as it's a breaking change especially if they're using [email protected] which doesn't support firebase@4. Open issue: https://github.com/firebase/angularfire/issues/934

According to the above hackone url, the impact of the issue is:

This shows that an attacker can add attributes to all existing object on the server. Additional attribute can be used to change the execution code flow or cause error on every subsequent request by replacing "toString" or "valueOf".

This vulnerability is guaranteed to at least obtain denial of service as all the library allow the property "toString" and "valueOf" to be replaced by a "String". This breaks the express module and forces the server to either crash or return a 500 to every subsequent request.

More complex payload can be crafted to gain remote code execution (see PoC in #309391).

From reading this I understand an application consuming directly/indirectly hoek package is vulnerable only if it's run on the server.

So since an application consuming [email protected] that's using [email protected] is only served to the client & not ran on the server.

Is it still vulnerable ?

Answer 1

Update!!

I just published a npm package to fix prototype pollution issue for people who are unable to update to the patched version of a vulnerable package. You can install the following package:

yarn add no-pollution

And simply require it at the entry point of your javascript project.

require('no-pollution');

Tested against extend, merge, clone type of vulnerable methods that cause prototype pollution. However, currently doesn't work against vulnerable path-assignment methods but this should be enough for your firebase package.

Old Answer

It is true that prototype pollution vulnerability has more serious risk on the server side than on the client side. Since it can be easily leveraged to do a Denial of Service(DoS) attack or a Remote Code Execution(RCE) attack.

Generally all the business logic happen on the backend and only the available information is displayed on the frontend. But that doesn't change the fact that someone can pollute your object's prototype and can perform unindented code execution on your application.

This gives rise to a serious vulnerability on your application which will also allow the attacker to do both DoS or RCE but it is constrained by a level of difficulty and the level of resources the client can access. But that doesn't change the fact that your application has a security flaw that can be leveraged to do a serious damage. Read more about this on Snyk

Re-writing your entire code base for firebase 4 could be a difficult and time consuming process but it is something you will have to do eventually unless angular fire decides to offer support to firebase 4...