security considerations #23

Closed
bemurphy opened this Issue Jan 1, 2012 · 12 comments

Comments

Projects
None yet
3 participants
@bemurphy

bemurphy commented Jan 1, 2012

I think there's a security bug around the evaluation of the .envrc file. I've run through this scenario and it seems to misbehave like I'd guessed.

If for instance in /tmp, Alice creates a .envrc file with export PATH=/tmp:$PATH and drops a malicious ls wrapper script there, when Bob executes ls in /tmp, he runs /bin/ls and is compromised.

I think rvm, for instance, deals with this by notifying the user of an untrusted rc encountered, along with hashes of file contents to prevent post-trust tampering.

@zimbatm

This comment has been minimized.

Show comment Hide comment
@zimbatm

zimbatm Jan 1, 2012

Owner

Hey Brendon, thanks for reporting.

In my idea, executing the .envrc is not inherently less secure than executing a project's Makefile or installing anything on your computer. The same rule applies, people don't generally sabotage their project because their online identity is associated to it. That said, it could make sense to add a whitelist to your project folder with something like export DIRENV_ALLOW=$HOME/code

I am aware of the rvm feature but I always found it more annoying than useful. One big grief was that even authorized files would need to be re-authorized if the project got moved around. If I where to implement something similar it would just be hash-based. I would also need to add a cache directory for those authorizations and some latency for the checksum and make the code in general more complex. I'm not sure it's worth it but I'm open to counter-arguments (and pull requests :)).

Happy new year!

Owner

zimbatm commented Jan 1, 2012

Hey Brendon, thanks for reporting.

In my idea, executing the .envrc is not inherently less secure than executing a project's Makefile or installing anything on your computer. The same rule applies, people don't generally sabotage their project because their online identity is associated to it. That said, it could make sense to add a whitelist to your project folder with something like export DIRENV_ALLOW=$HOME/code

I am aware of the rvm feature but I always found it more annoying than useful. One big grief was that even authorized files would need to be re-authorized if the project got moved around. If I where to implement something similar it would just be hash-based. I would also need to add a cache directory for those authorizations and some latency for the checksum and make the code in general more complex. I'm not sure it's worth it but I'm open to counter-arguments (and pull requests :)).

Happy new year!

@bemurphy

This comment has been minimized.

Show comment Hide comment
@bemurphy

bemurphy Jan 1, 2012

@zimbatm Thanks for your reply on this. I have to run but when I get time time afternoon I'll reply with additional thoughts.

Happy new year to you as well!

bemurphy commented Jan 1, 2012

@zimbatm Thanks for your reply on this. I have to run but when I get time time afternoon I'll reply with additional thoughts.

Happy new year to you as well!

@pwaller

This comment has been minimized.

Show comment Hide comment
@pwaller

pwaller Aug 22, 2012

Owner

Some ideas:

There is a general problem here that direnv opens up a new attack surface. There are two obvious scenarios. There is the single-user environment where you download a package, and you don't realise that there exists a malicioius .envrc. Then there is the case on a multi-user environment where one user can drop a .envrc file into /tmp and any user who cds to a subdirectory of /tmp can then be owned.

For the multiuser case you could refuse to respect .envrc files which are under the control or writable by users other than the current user. The single user case is trickier. An idea I had would be to warn the user that there is a .envrc and prompt them to type "yes" to trust it. Then there is a list of trusted .envrcs (along with hashes of said .envrcs, disallowing an attacker to manipulate a trusted .envrc) stored somewhere in the user's .config directory.

Owner

pwaller commented Aug 22, 2012

Some ideas:

There is a general problem here that direnv opens up a new attack surface. There are two obvious scenarios. There is the single-user environment where you download a package, and you don't realise that there exists a malicioius .envrc. Then there is the case on a multi-user environment where one user can drop a .envrc file into /tmp and any user who cds to a subdirectory of /tmp can then be owned.

For the multiuser case you could refuse to respect .envrc files which are under the control or writable by users other than the current user. The single user case is trickier. An idea I had would be to warn the user that there is a .envrc and prompt them to type "yes" to trust it. Then there is a list of trusted .envrcs (along with hashes of said .envrcs, disallowing an attacker to manipulate a trusted .envrc) stored somewhere in the user's .config directory.

@zimbatm

This comment has been minimized.

Show comment Hide comment
@zimbatm

zimbatm Aug 22, 2012

Owner

@pwaller what do you think of the whitelist approach I described above, would it works with your current workflow ? By default it would only allow .envrc scripts from your $HOME and deeper.

Owner

zimbatm commented Aug 22, 2012

@pwaller what do you think of the whitelist approach I described above, would it works with your current workflow ? By default it would only allow .envrc scripts from your $HOME and deeper.

@pwaller

This comment has been minimized.

Show comment Hide comment
@pwaller

pwaller Aug 22, 2012

Owner

That doesn't deal with the case that a project covertly includes a .envrc.
I think the only secure way forward is to explicitly accept each one. Maybe
with a "direnv enable" command or some such. Then when a previously
unencountered or a modified envrc is seen instead of sourcing it the shell
invited you to enable it. What do you think?
On 22 Aug 2012 16:47, "Jonas Pfenniger" notifications@github.com wrote:

@pwaller https://github.com/pwaller what do you think of the whitelist
approach I described above, would it works with your current workflow ? By
default it would only allow .envrc scripts from your $HOME and deeper.


Reply to this email directly or view it on GitHubhttps://github.com/zimbatm/direnv/issues/23#issuecomment-7938722.

Owner

pwaller commented Aug 22, 2012

That doesn't deal with the case that a project covertly includes a .envrc.
I think the only secure way forward is to explicitly accept each one. Maybe
with a "direnv enable" command or some such. Then when a previously
unencountered or a modified envrc is seen instead of sourcing it the shell
invited you to enable it. What do you think?
On 22 Aug 2012 16:47, "Jonas Pfenniger" notifications@github.com wrote:

@pwaller https://github.com/pwaller what do you think of the whitelist
approach I described above, would it works with your current workflow ? By
default it would only allow .envrc scripts from your $HOME and deeper.


Reply to this email directly or view it on GitHubhttps://github.com/zimbatm/direnv/issues/23#issuecomment-7938722.

@zimbatm

This comment has been minimized.

Show comment Hide comment
@zimbatm

zimbatm Aug 22, 2012

Owner

Maybe I'm too naive but if someone at github would push an evil envrc (eg: rm -rf $HOME/* >/dev/null 2>&1 &), everyone would know and he would loose credibility. Isn't it a sufficient deterrent ? :)

Owner

zimbatm commented Aug 22, 2012

Maybe I'm too naive but if someone at github would push an evil envrc (eg: rm -rf $HOME/* >/dev/null 2>&1 &), everyone would know and he would loose credibility. Isn't it a sufficient deterrent ? :)

@pwaller

This comment has been minimized.

Show comment Hide comment
@pwaller

pwaller Aug 22, 2012

Owner

Just hypothetically, imagine direnv was put in the global bash profile on a
multi user system. This would not be a safe thing to do at the moment as it
would open up a new not-innately-obvious attack vector.

In your extreme example the consequences would be obvious and possibly
traceable. But imagine I untar or unzip some content that I was not
expecting to execute anything from. Oops, you were just owned. And it might
not be apparent.
On 22 Aug 2012 17:13, "Jonas Pfenniger" notifications@github.com wrote:

Maybe I'm too naive but if someone at github would push an evil envrc (eg: rm
-rf $HOME/* >/dev/null 2>&1 &), everyone would know and they would loose
credibility. Isn't it a sufficient deterrent ? :)


Reply to this email directly or view it on GitHubhttps://github.com/zimbatm/direnv/issues/23#issuecomment-7939615.

Owner

pwaller commented Aug 22, 2012

Just hypothetically, imagine direnv was put in the global bash profile on a
multi user system. This would not be a safe thing to do at the moment as it
would open up a new not-innately-obvious attack vector.

In your extreme example the consequences would be obvious and possibly
traceable. But imagine I untar or unzip some content that I was not
expecting to execute anything from. Oops, you were just owned. And it might
not be apparent.
On 22 Aug 2012 17:13, "Jonas Pfenniger" notifications@github.com wrote:

Maybe I'm too naive but if someone at github would push an evil envrc (eg: rm
-rf $HOME/* >/dev/null 2>&1 &), everyone would know and they would loose
credibility. Isn't it a sufficient deterrent ? :)


Reply to this email directly or view it on GitHubhttps://github.com/zimbatm/direnv/issues/23#issuecomment-7939615.

@pwaller

This comment has been minimized.

Show comment Hide comment
@pwaller

pwaller Aug 22, 2012

Owner

To add, "loss of credibility" won't be a deterrent to someone who has gained control of an account illegitimately.

Owner

pwaller commented Aug 22, 2012

To add, "loss of credibility" won't be a deterrent to someone who has gained control of an account illegitimately.

@pwaller

This comment has been minimized.

Show comment Hide comment
@pwaller

pwaller Aug 22, 2012

Owner

Also, echo -n $'\033[1A\033[K' is sufficient to eliminate the text saying that an environment has been sourced, so this is trivial to make entirely invisible. Plus the configuration is already in a dot-file. This would basically be invisible to novice and experienced users alike.

Owner

pwaller commented Aug 22, 2012

Also, echo -n $'\033[1A\033[K' is sufficient to eliminate the text saying that an environment has been sourced, so this is trivial to make entirely invisible. Plus the configuration is already in a dot-file. This would basically be invisible to novice and experienced users alike.

@zimbatm

This comment has been minimized.

Show comment Hide comment
@zimbatm

zimbatm Aug 22, 2012

Owner

Alright alright, you win the argument battle. Do you want to have a go at implementing this ?

Owner

zimbatm commented Aug 22, 2012

Alright alright, you win the argument battle. Do you want to have a go at implementing this ?

@pwaller pwaller referenced this issue Aug 22, 2012

Closed

Security fix #33

pwaller added a commit to pwaller/direnv that referenced this issue Aug 24, 2012

@zimbatm

This comment has been minimized.

Show comment Hide comment
@zimbatm

zimbatm Apr 7, 2013

Owner

@pwaller we can close this don't you think, or you want to keep it open until the 2.0.0 release ?

Owner

zimbatm commented Apr 7, 2013

@pwaller we can close this don't you think, or you want to keep it open until the 2.0.0 release ?

@pwaller

This comment has been minimized.

Show comment Hide comment
@pwaller

pwaller Apr 7, 2013

Owner

I agree it can be closed, I was thinking the same.

Owner

pwaller commented Apr 7, 2013

I agree it can be closed, I was thinking the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment