All Meteor developers should be aware of a recently discovered security vulnerability. Please read this disclosure for full details.

The vulnerability has already been fixed in Meteor and developers should see the Resolution section below for a meteor update command which patches existing applications.

In short, we recommend all developers update and deploy, however applications using the attachSchema method from aldeed:collection2 (or a similar method from another package) on the same collection where allow or deny rules are in place should pay particular attention.

Description

An exploitable security vulnerability has been discovered in Meteor through a downstream project’s bug bounty program which affects a commonly used application configuration, and could be used to access users’ private data or circumvent other protections an application may have in place.

By sending a specially crafted WebSocket payload, a malicious client can execute an update operation on individual MongoDB documents in violation of the collection’s allow and deny rules, when particular third-party packages are installed. When the malicious WebSocket frame is evaluated against the developer-configured rules, the exploit disables specific rules which would have blocked the operation, thus allowing the operation to be executed.

Impact

While a default Meteor configuration using Meteor’s core packages (for example, the accounts-* packages and allow-deny) is not automatically vulnerable, the exploit becomes possible when certain commonly-used third-party packages are also installed.

An application may be affected if it utilizes a MongoDB collection’s Mongo.Collection#allow or Mongo.Collection#deny methods to define collection-level rules and also uses any third-party packages to enforce a schema on the same collection. This consideration applies whether the application uses <CollectionName>.allow({...}) or <CollectionName>.deny({...}) directly, or the third-party packages manage the collection’s allow or deny rules on its behalf. Furthermore, Meteor.Collection is a (deprecated) alias for Mongo.Collection and is therefore subject to identical considerations.

Only Mongo update operations for documents which a user was allowed to update are affected. In the case where an update is allowed, this exploit may permit updates to unexpected parts of that document. This nuance becomes particularly relevant if an application has top-level properties which dictate a user’s permission level, such as an isAdmin (or similar) field.

Other protected operations such as insert, remove, or fetch are not affected.

If an application does not use any Mongo.Collection#allow methods directly or indirectly, we have no evidence of exploitability. Additionally, if a collection explicitly denies all updates with <CollectionName>.deny, then it will not be vulnerable.

If an application includes one of the following third-party packages, combined with allow rules without explicit deny rules (as outlined above), it may become vulnerable. The packages themselves are not to blame, though their presence may enable the exploit. These particular packages were chosen according to their popularity, not for any special role or fault in the exploit. Other packages which provide similar functionality should also be regarded with caution:

aldeed:collection2 or aldeed:collection2-core or any other package which may be used for schema validation and enforcement.
While these packages are functioning as designed, in some configurations they remove certain update parameters, which can change the behavior of the update. A collection which has not had a schema attached to it (for example, using <CollectionName>.attachSchema) should not be vulnerable.
ongoworks:security
Versions of this package after 2.0 no longer create allow and deny rules automatically, which means the exploit should not work, though appending allowInClientCode() to a normal permission chain may result in the addition of vulnerable allow and deny rules.
alanning:roles
This package stores permission information as a top-level roles property on the user document, which, if exploited properly, could be modified.
Resolution

The vulnerability has been fixed with the release of version 1.0.9 of the allow-deny Meteor package.

Regardless of whether you believe your application is affected, we highly recommend any application update to allow-deny@1.0.9.

After updating and deploying the fix, applications which match the criteria for being affected should audit sensitive Mongo documents to ensure no user permissions have been maliciously elevated and no sensitive fields have been modified.

Meteor 1.4 or later

The command to update the allow-deny package and patch the vulnerability is:

meteor update allow-deny
After running this command, please verify that allow-deny@1.0.9 was installed, either by examining the output of the command or looking at your .meteor/versions file.

Prior to Meteor 1.4

Any application running less than Meteor 1.4 should update to at least Meteor 1.4.x and apply this update using the above instructions. Meteor versions prior to 1.4 utilize Node.js 0.10.x, which is no longer receiving security updates from the Node Foundation and might already be susceptible to security vulnerabilities unrelated to this disclosure.

Running an unmaintained Node.js version is not recommended!

Credit

Meteor fully believes in ethical disclosure of vulnerabilities by security researchers who notify us with details and provide us time to address and fix the issues before public disclosure.

Credit for the discovery of this vulnerability goes to Sam Sun who reported the bug in Meteor as part of the LegalRobot bug bounty program they operate through HackerOne.