14

In /etc/ssh/sshd_config, there is an option called AcceptEnv that allows the ssh client to send environment variables. I need to be able to send a large number of environment variables. These change on every connection from the client, so putting them in a login script on the server would be more difficult.

I've read that "AcceptEnv *" is insecure. I'd like to understand why before I try to get a list of all of the environment variables that are attempted to be set to put there.

Why is it considered insecure? Can I get an example?

TheDauthi
  • 143
  • 1
  • 1
  • 6

2 Answers2

15

Enabling environment processing may enable users to bypass access restrictions in some configurations using mechanisms such as LD_PRELOAD.

Not all version of the man pages for sshd_config mention this. If your environment variables are changed beforehand and certain privileged processes are executed with new libraries specified by this, issues can result.

Take a look at http://www.dankalia.com/tutor/01005/0100501004.htm and search for "LD_PRELOAD Exploit". Sorry, the page has no anchor links.

See also StackOverflow question: What is the LD_PRELOAD trick?

Setting environment variables after connection is fine, but when those variable are interpreted by the ssh daemon as set by AcceptEnv, Bad Things may occur.

pevik
  • 286
  • 1
  • 12
Jeff Ferland
  • 20,239
  • 2
  • 61
  • 85
  • 2
    How is it any different than when they set the variables manually after logging in? – Joseph Garvin Feb 09 '15 at 15:05
  • 2
    @JosephGarvin, some systems have restricted shells or only allow a single specific command, such that "they" *can't*. The concern, then, is providing a means by which such security measures can be bypassed. – Charles Duffy Mar 10 '17 at 22:49
-1

Do not accept environment variables:

See the Shellshock exploit that came out recently.. if you accept environment variables then you are opening up a really nasty exploit.

Charles Duffy
  • 946
  • 2
  • 10
  • 19
John Hunt
  • 428
  • 2
  • 10
  • 20
  • 1
    You are spreading fear IMO. If you are that worried why do they have SSH access? And btw you can't stop them from setting environment variables once they are in the shell or even functions. That exploit is about unauthorized shell access through stuff like nginx, not authorized shell access. – Jordon Bedwell Oct 18 '14 at 09:35
  • Anyway you accept at least one env. variable named TERM. There can be valid needs to accept other variables like PRINTER, EDITOR, PAGER, ... – ibre5041 Sep 11 '15 at 09:51
  • 1
    @JordonBedwell, not every SSH connection *is* authorized for shell access. I have several systems where there are accounts for which the only authentication is with a SSH key that allowed to run only a single, specific command (with the identity of the owner of that key, and other details, baked in). – Charles Duffy Mar 10 '17 at 22:51
  • ...that said, I agree that as of 2017, ShellShock is very much overblown here. With current implementations, generating an exported function requires control not only over an environment variable's *value*, but also its *name* (and the process of evaluating exported functions during shell startup is no longer itself prone to injection attacks). – Charles Duffy Mar 10 '17 at 22:52