Meteor Package Scan

Written by Pete Corey on Apr 27, 2015.

In response to my last Meteor Black Box post about Package Scanning, I was inspired to build a tool to help improve the safety of the Meteor package ecosystem. That tool is Package Scan!

Package Scan is a Meteor package that will parse your .meteor/versions file and compare the packages being used by your project against a list of packages with known security issues. If a vulnerable package is detected, a warning will be shown in your server logs. Package Scan is debug only, so it will never be built into your production application.

The goal is Package Scan is to give Meteor developers an extra layer of knowledge and insight about the packages they’re using in their projects. My vision is that, with help from the community, Package Scan will enable developers to quickly discover and understand the security implications of the packages being used in their projects, or give some level of peace of mind if no vulnerable packages are detected.

The key to Package Scan will be community involvement. Without help from other package developers and users, I’ll have no hope of ever maintaining a comprehensive and up to date package warning list. It’s my hope that whenever a security problem is discovered in a version of a package, Package Scan will be updated with a new alert.

The mechanism I’m using for updating the Package Scan alert repository is to keep all of the alerts in a JSON file (data/alerts.json). That JSON file holds a list of alerts for each package, and each alert holds a semver range representing the vulnerable range of that package along with the actual alert text. This file is actually fetched directly from GitHub by the Package Scan package when it’s installed in a project, which means that the alert repository can be updated without having to update Package Scan itself. To contribute an alert, just submit a pull request against alerts.json.

Read more about the package on the GitHub project page!

Black Box Meteor - Package Scanning

Written by Pete Corey on Apr 24, 2015.

An interesting side effect of Meteor’s packing system is that all packages used in a project are visible to the client. Open up a browser and take a look at the global Package object:

Object.keys(Package);

For a simple project, you may see results like this:

["underscore", "meteor", "json", "base64", "ejson", "logging", "reload", "tracker", "random", "retry", "check", "id-map", "ordered-dict", "geojson-utils", "minimongo", "ddp", "insecure", "mongo", "autoupdate", "meteor-platform", "autopublish", "webapp", "deps", "reactive-dict", "session", "livedata", "jquery", "htmljs", "observe-sequence", "reactive-var", "blaze", "ui", "templating", "spacebars", "launch-screen"]

So what are the consequences of this? Immediately, we see that this application is using autopublish and insecure. A malicious user could quickly couple a search for autopublish or insecure with a search for any globally defined Collections:

Object.keys(window).filter(function(key) {
    return window[key] instanceof Meteor.Collection;
});

Or just directly look through the Mongo collections published to the client:

Meteor.connection._mongo_livedata_collections

In a fraction of a second, a malicious user can see if your application is overpublishing, or vulnerable to arbitrary Mongo modifications through the autopublish and insecure packages.

But what about other packages? What if a malicious user is aware of a vulnerability in an existing Meteor package. Using the Package object on the client, that user can quickly check to see if an application is making use of that package, and is therefore vulnerable.

One sidenote is that the Package object does not include the version of the package being used. If a malicious users knows that a vulnerability exists in some version of a package but not in other versions, they would not immediately know if your application were vulnerable to their exploit.

So what can you do to protect your application? First, in nearly all cases your production application should not being using autopublish or insecure. Remove those packages. After that, always be sure to keep your packages updated to ensure that you’re not shipping code that may contain known flaws or vulnerabilities.

Discover Meteor - Mentoring Session

Written by Pete Corey on Apr 20, 2015.

Last week I stumbled upon Sacha Greif’s Crater post about becoming a Discover Meteor tutor. I decided that this would be a great opportunity to flex my teaching muscles and help others learn about Meteor!

I’ve scheduled a Hangout at 9:00 AM, Pacific Time, this Wednesday morning (4/22). We’ll be going over the Templates chapter of Discover Meteor (Chapter 3). We’ll spend the first 40 minutes going through the chapter, followed by a 20 minute block set aside for questions and answers. If you’re interested, check out the CodeBuddies event and sign up. See you then!