5 ms·

so basically turn off AcceptEnv in sshd_config?

• hijinks 12y ago
  I don't think so. From what I've been reading it can be exploited via http requests. I'm sure a metasploit script is right around the corner. Edit: oh looks like only like mod_cgi related stuff is.. thats good then sort of
  • kevinr 12y ago
    Any software where adversary-controlled input can set environment variables which then execs bash is affected. mod_cgi is just really easy to exploit.
  • vidarh 12y ago
    It can potentially be exploited via anything that shells out to bash with an environment that contains environment variables with values (that ultimately comes from) an untrusted source. mod_cgi is just one of the most obvious attack vectors.
• justincormack 12y ago
  Also don't use bash for running any scripts. You never should anyway, in a sane environment /bin/sh should not be bash - in Debian/Ubuntu it is dash which is not vulnerable. Unfortunately the Redhat derived distros do use bash as default /bin/sh. In the BSDs it is a standards compliant posix sh too. bash is for users not scripts.
  • mhurron 12y ago
    > in a sane environment /bin/sh should not be bash Why, other than it is not the shell of the day?
    • justincormack 12y ago
      First it encourages people to use bash specific stuff that is non Posix. Second it is a huge bloated bit of code thats ok as user interface, but scripts should use something that is more minimal. To avoid this sort of issue.
      • mhurron 12y ago
        > scripts should use something that is more minimal. To avoid this sort of issue. Are you also against Perl and Python or does this scripts should be minimal only apply to bash? > First it encourages people to use bash specific stuff that is non Posix That's not a problem for most people. These are reasons you don't like bash, not reasons to not use bash.
        • bcoates 12y ago
          /bin/sh is the shell called by system(3) and used by portable scripts bundled with packages. Those things can't use anything but standard sh anyway, so having them run bash is overkill. "Don't use bash as your /bin/sh" isn't the same as "don't use bash as your interactive shell" or "don't write bash scripts"
  • kevinr 12y ago
    And don't put #!/bin/bash at the top of your scripts. And don't shell out in eg. Perl, or PHP, or Python, through bash. Or just take a patched bash.
  • diltonm 12y ago
    Dash sucks, bash rocks. Dash isn't even close to being as capable of a shell as Bash.
  • droopybuns 12y ago
    Anyone able to express how this affects the default client configuration on Mac desktops and servers?
    • droopybuns 12y ago
      I guess I'll answer one part- so if you run this: $ env x='() { :;}; echo vulnerable' bash -c "echo test" in your terminal, you certainly appear to be vulnerable. But I'm not knowledgable about all the default scripts that launch things on the mac. It's unclear to me if there are any standard processes on OSX that take advantage of Bash
  • vertex-four 12y ago
    > In the BSDs it is a standards compliant posix sh too. In FreeBSD, it is tcsh in sh mode. Bash does the same too when invoked as sh[0]. It's POSIX compliant with extensions. There's still all the shell's code there, it's just that some of it is switched off by default, or its behaviour modified, to be compliant. [0] http://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html http://www.gnu.org/software/bash/manual/html_node/Bash-POSIX...
• nknighthb 12y ago
  By the time AcceptEnv has any effect, the user is already logged in and can run whatever they want anyway. If you're allowing untrusted users to authenticate to ssh, then, yeah, sure, but you'd be in a niche (and know it).
• mdavidn 12y ago
  Don't forget SSH_ORIGINAL_COMMAND. GitHub and BitBucket had an exciting morning...