Vulnerabilities in meteor framework
Meteor is developed by the Meteor Development Group. The startup was incubated by Y combinator and received $11.2M in funding from Andressen Horowitz in July 2012. Meteor raised an additional $20M in Series B funding from Matrix Partners, Andreessen Horowitz and Trinity Ventures. It intends to become profitable by offering Galaxy, an enterprise-grade hosting environment for Meteor applications.
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.
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
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
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
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.
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 firstname.lastname@example.org.
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 email@example.com 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!
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 Legal Robot bug bounty program they operate through Hacker one.
At Valency Networks, we understand your web application and perform framework specific checks mentioned above. Our expertise in this matter enables us to be very accurate in terms of our vulnerability findings.