Security Issue

132 views
Skip to first unread message

Ritchie Young

unread,
May 5, 2014, 10:08:55 PM5/5/14
to nod...@googlegroups.com
As I'd mentioned previously on the mailing list, I have a security concern. I don't think that it applies to versions of NodeJS past 0.8.x but you may like to check that out.

Full details here:


TLDR: The .lock-wscript file contains a dump of your environment variables and may be inadvertently published along with your source-code.

Cheers
Ritchie



Aria Stewart

unread,
May 6, 2014, 12:21:53 AM5/6/14
to nod...@googlegroups.com
Aw, nice find. Not huge, but definitely worth knowing about!

Thanks for the responsible disclosure, too.

Alex Kocharin

unread,
May 6, 2014, 4:53:56 AM5/6/14
to nod...@googlegroups.com
 
Not a security issue.
 
If you're checking any machine-generated data in to a version control system, you're doing it wrong. The sole existence of an unknown file in "git commit -a" should be a red flag, and the data leak isn't because of the node.js but because of the person who committed it there.
 
Besides, environment variables shouldn't be used to store anything secret, so it sounds twice like "not a security issue".
 
 
06.05.2014, 08:19, "Ritchie Young" <ritc...@gmail.com>:
--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAJJUJJq7Bfq_ZRS%2BcVyXHaqLhwJ4-1FTZYvt9y3-N-FfJ8cxBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Peter Rust

unread,
May 7, 2014, 2:05:05 PM5/7/14
to nod...@googlegroups.com
Thanks, Ritchie, this is valuable.

> environment variables shouldn't be used to store anything secret

I was under the impression that it is common practice to include database creds embedded in a DATABASE_URL environment variable, as well as creds/tokens for other third-party services (s3, etc) -- isn't this what the 12 factor app (http://12factor.net/ - Heroku's manifesto) recommends?

> If you're checking any machine-generated data in to a version control system, you're doing it wrong

Some prominent node devs (including mikeal) encourage checking node_modules into source control. Wouldn't this include machine-generated data, including the .lock-wscript file? Or would that be excluded by a .gitignore rule?

-- peter rust

Alex Kocharin

unread,
May 8, 2014, 12:15:19 PM5/8/14
to nod...@googlegroups.com
 
08.05.2014, 00:14, "Peter Rust" <pe...@cornerstonenw.com>:
Thanks, Ritchie, this is valuable.
 
> environment variables shouldn't be used to store anything secret
 
I was under the impression that it is common practice to include database creds embedded in a DATABASE_URL environment variable, as well as creds/tokens for other third-party services (s3, etc) -- isn't this what the 12 factor app (http://12factor.net/ - Heroku's manifesto) recommends?
 
 
It's also a common practice to set "qwerty" as your password...
 
I'm not using Heroku (and don't like PaaS in general), so I don't know their reasons for it.
 
By the way, this approach fails when DATABASE_URL is different among multiple child processes. I remember an issue in pm2 bugtracker about preserving environment, there was a discussion about env keys reusing/collisions.
 
I'd say config files are preferred.
 
 
> If you're checking any machine-generated data in to a version control system, you're doing it wrong
 
Some prominent node devs (including mikeal) encourage checking node_modules into source control. Wouldn't this include machine-generated data, including the .lock-wscript file? Or would that be excluded by a .gitignore rule?
 
 
I very much doubt this practice. But if you're doing that for some reason, check manually every single file you add, at least its name.
 
Otherwise one can easily add npm-debug.log this way which contains even more sensitive information than is stored to environment. I hope I didn't just disclosed another security issue, did I?
 
Reply all
Reply to author
Forward
0 new messages