On Fri, 26 Sep 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
On 26/09/2014 5:22 AM, Douglas Ray wrote:
those of you who haven't been up into the small hours looking at the
... if you were looking at this then, then you were already probably far too late on this.
wget -U "() { test;};/usr/bin/touch /tmp/VULNERABLE" \ http://www.example.com/cgi-bin/whatever Above is a test for a vulnerable cgi-bin script courtesy of https://twitter.com/hernano . ssh root@localhost "() { :;} ; touch /tmp/ohno" Above is a test I wrote for ssh where ~root/.ssh/authorized_keys allows access but with the "command=" option (which sets the original command to the SSH_ORIGINAL_COMMAND variable). Note that this doesn't do anything useful in the case where unrestricted ssh access is granted.
This looks like something that must be fixed ASAP. In relation to Debian, it's been patched for Wheezy or Squeeze-LTS -- big problem if you are still on Squeeze.
I've just tested the new version of bash for Wheezy, it fixes the bug.
This looks like a very serious issue that very quickly become exploited.
I would hate to think about all those boxes running busybox and how they might or might not be effected, but definitely a case of making sure that such equipment is NOT Internet accessible by any process ... lock down access to internal IP addresses, better still limit specific IP address(es).
It seems that interpreted languages aren't a good choice when taking unsanitised input from untrusted sources. The cgi-bin issue should have been dealt with by the web server sanitising input (as well as Bash not working in that way). The ssh issue is due to sshd not being a good replacement for sudo. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/