3 ms·

I run an Ubuntu server in my closet as a general-purpose file server and such, mostly just for my own use or for sending files to friends. I have just turned it

I run an Ubuntu server in my closet as a general-purpose file server and such, mostly just for my own use or for sending files to friends. I have just turned it off and disabled all port forwards to it, and I will wait at least a few days and check for a more definitive fix before opening it back up to the internet. I recommend anyone in a similar situation do the same.

Sanddancer 12y ago
No need to go to that length. Ubuntu uses dash as its standard /bin/sh. If you're super paranoid, chmod /bin/bash to 000 and fix any broken scripts that call that shebang; most likely, they don't use any bashisms and can use the stock bourne shell.
atmosx 12y ago
Why? Why don't you uninstall bash all-together? Most programs should be using '/bin/sh' and not bash.(IIRC Linux might have symlink between the two, which is awful) You could install zsh. You could add further security layers, harden your network-level access, monitor your logs and so forth. Security is a set of policies. If you think that there are users who have unauthorized access to your system or you run bash-enabled cgi scripts, well then disable them (you shouldn't be using those in first place anyway), lock-out unauthorized users, change your passwords, etc. The panic is for admins who handle systems with multiple users (universities, etc.) and offer (even restricted) shell access. For these guys might be hard to sleep at night, but for someone running a fileserver, shouldn't really make any diff.
- rcthompson 12y ago
  I don't have the time right now to figure out what the default shell is and whether Ubuntu supports switching it, and whether I have any custom scrips or some such that assume /bin/sh is bash. So the easiest thing to do is just disconnect it for now.
- Karunamon 12y ago
  >Most programs should be using '/bin/sh' and not bash. Why? There are some non-trivial things that you can do in bash but not sh (or dash)[1]. Remaining POSIX compatible by way of never adding additional features seems like a great way to never make any forward progress. [1]: http://mywiki.wooledge.org/Bashism http://mywiki.wooledge.org/Bashism
  - atmosx 12y ago
    From FreeBSD manual page for 'sh': DESCRIPTION The sh utility is the standard command interpreter for the system. The current version of sh is close to the IEEE Std 1003.1 (“POSIX.1”) specification for the shell. It only supports features designated by POSIX,plus a few Berkeley extensions. [...] Again from FreeBSD manual for 'bash': DESCRIPTION Bash is an sh-compatible command language interpreter that executes commands read from the standard input or from a file. Bash also incorporates useful features from the Korn and C shells (ksh and csh). Bash is intended to be a conformant implementation of the Shell and Utilities portion of the IEEE POSIX specification (IEEE Standard 1003.1). Bash can be configured to be POSIX-conformant by default. These two shells are different and the reason that FreeBSD keeps '/bin/sh' is because it was designed to be secure and reliable instead of full-featured. Makes sense as a choice, it is aligned with the general UNIX philosophy: do one thing, do it good, keep it as simple as possible. Given the fact that the bug was found in bash, I guess it's just (another) win for this harsh philosophy that so many geeks seem to strongly embrace.
bodyfour 12y ago
The only attack vectors I've seen so far are: * webservers that are configured to run things via the ancient CGI interface. There are lots of these on the internet (so that's bad) but most OSes aren't going to be vulnerable out of the box or anything. Also, the biggest risk is if you're on a server where /bin/sh is bash, which is not the case for Ubuntu. * people using sshd and have users that are allowed to ssh but not run a shell -- for instance by having "command=" settings in a .ssh/authorized_keys file. Most people won't have this. It's a pattern most associated with services like github which allows you to use git-over-ssh but not run arbitrary programs on their servers. Another example would be if you've set up a special key for a backup system to connect over ssh and run rsync. Most servers aren't going to have these things. If you're just using sshd for normal user logins there is no impact: you can "exploit" the bug and run arbitrary commands, but only if you have the same credentials you could have used to log in and run them yourself anyway. * DHCP clients could be affected, but only if the server is already compromised (or spoofed) which probably isn't a huge concern for your home network. So you're probably overreacting here. Certainly stay up-to-date on the patches as they come out for safety, though.

Sanddancer 12y ago

No need to go to that length. Ubuntu uses dash as its standard /bin/sh. If you're super paranoid, chmod /bin/bash to 000 and fix any broken scripts that call that shebang; most likely, they don't use any bashisms and can use the stock bourne shell.

atmosx 12y ago

Why? Why don't you uninstall bash all-together? Most programs should be using '/bin/sh' and not bash.(IIRC Linux might have symlink between the two, which is awful) You could install zsh. You could add further security layers, harden your network-level access, monitor your logs and so forth. Security is a set of policies. If you think that there are users who have unauthorized access to your system or you run bash-enabled cgi scripts, well then disable them (you shouldn't be using those in first place anyway), lock-out unauthorized users, change your passwords, etc. The panic is for admins who handle systems with multiple users (universities, etc.) and offer (even restricted) shell access. For these guys might be hard to sleep at night, but for someone running a fileserver, shouldn't really make any diff.

rcthompson 12y ago
I don't have the time right now to figure out what the default shell is and whether Ubuntu supports switching it, and whether I have any custom scrips or some such that assume /bin/sh is bash. So the easiest thing to do is just disconnect it for now.
Karunamon 12y ago
>Most programs should be using '/bin/sh' and not bash. Why? There are some non-trivial things that you can do in bash but not sh (or dash)[1]. Remaining POSIX compatible by way of never adding additional features seems like a great way to never make any forward progress. [1]: http://mywiki.wooledge.org/Bashism http://mywiki.wooledge.org/Bashism
- atmosx 12y ago
  From FreeBSD manual page for 'sh': DESCRIPTION The sh utility is the standard command interpreter for the system. The current version of sh is close to the IEEE Std 1003.1 (“POSIX.1”) specification for the shell. It only supports features designated by POSIX,plus a few Berkeley extensions. [...] Again from FreeBSD manual for 'bash': DESCRIPTION Bash is an sh-compatible command language interpreter that executes commands read from the standard input or from a file. Bash also incorporates useful features from the Korn and C shells (ksh and csh). Bash is intended to be a conformant implementation of the Shell and Utilities portion of the IEEE POSIX specification (IEEE Standard 1003.1). Bash can be configured to be POSIX-conformant by default. These two shells are different and the reason that FreeBSD keeps '/bin/sh' is because it was designed to be secure and reliable instead of full-featured. Makes sense as a choice, it is aligned with the general UNIX philosophy: do one thing, do it good, keep it as simple as possible. Given the fact that the bug was found in bash, I guess it's just (another) win for this harsh philosophy that so many geeks seem to strongly embrace.

bodyfour 12y ago

The only attack vectors I've seen so far are: * webservers that are configured to run things via the ancient CGI interface. There are lots of these on the internet (so that's bad) but most OSes aren't going to be vulnerable out of the box or anything. Also, the biggest risk is if you're on a server where /bin/sh is bash, which is not the case for Ubuntu. * people using sshd and have users that are allowed to ssh but not run a shell -- for instance by having "command=" settings in a .ssh/authorized_keys file. Most people won't have this. It's a pattern most associated with services like github which allows you to use git-over-ssh but not run arbitrary programs on their servers. Another example would be if you've set up a special key for a backup system to connect over ssh and run rsync. Most servers aren't going to have these things. If you're just using sshd for normal user logins there is no impact: you can "exploit" the bug and run arbitrary commands, but only if you have the same credentials you could have used to log in and run them yourself anyway. * DHCP clients could be affected, but only if the server is already compromised (or spoofed) which probably isn't a huge concern for your home network. So you're probably overreacting here. Certainly stay up-to-date on the patches as they come out for safety, though.