there is an update out you want. badly.
debian/ubuntu admins may want to apt-get update/upgrade or whatever
freebsd similarly
can not speak for other systems
Can I presume you’re talking about the bash CVE-2014-6271?
- jared
See: oss-sec: Re: CVE-2014-6271: remote code execution through bash
sigh. i am well aware of it but saw no benefit for further blabbing a
vuln
randy
Keeping silent after the embargo is over isn't doing anyone any favors. I think Florian said it best in his most recent message:
"In this particular case, I think we had to publish technical details so that those who cannot patch immediately can at least try to mitigate this vulnerability using filters on devices in front of web servers, or tools like mod_security. And without the technical details, I doubt this vulnerability would have received the attention it deserves until someone figures things out. We could easily have obfuscated the patch to delay this, but what's the point?"
For anyone that would like to see if a system is vulnerable:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"|
If you receive the echo output, your version of bash is affected.
Regards,
SG
debian/ubuntu admins may want to apt-get update/upgrade or whatever
debian/ubuntu aren't really all that immediately impacted.
$ grep "bash$" /etc/passwd | wc -l
2
^^ both of those are user accounts, not system/daemon accounts.
-Jim P.
The scope of the issue isn't limited to SSH, that's just a popular
example people are using. Any program calling bash could potentially
be vulnerable.
Agreed. My point was that bash is not all that popular on
debian/ubuntu for accounts that would be running public facing
services that would be processing user defined input (www-data,
cgi-bin, list, irc, lp, mail, etc). Sure some non-privileged user
could host their own cgi script on >:1024, but that's not really a
critical "stop the presses!!" upgrade issue, imho.
-Jim P.
This is already made it to /. so I'm not sure why Randy was being so hush hush...
But my read is that this could affect anything that calls bash to do processing, like
handing off to CGI by putting in headers to p0wn the box. Also: bash is incredibly
pervasive though any unix disto, in not at all obvious places, so I wouldn't be
complacent about this at all.
Mike
The scope of the issue isn't limited to SSH, that's just a popular
example people are using. Any program calling bash could potentially
be vulnerable.Agreed. My point was that bash is not all that popular on
debian/ubuntu for accounts that would be running public facing
services that would be processing user defined input (www-data,
cgi-bin, list, irc, lp, mail, etc). Sure some non-privileged user
could host their own cgi script on >:1024, but that's not really a
critical "stop the presses!!" upgrade issue, imho.This is already made it to /. so I'm not sure why Randy was being so hush
hush...
But my read is that this could affect anything that calls bash to do
processing, like
handing off to CGI by putting in headers to p0wn the box. Also: bash is
incredibly
pervasive though any unix disto, in not at all obvious places, so I
wouldn't be
complacent about this at all.
Mike
If someone is already invoking #!/bin/bash from a cgi, then they are
already doing it wrong (bash has massive bloat/overhead for a CGI script).
But I do agree, it's hard to know exactly what idiots do. 
-Jim P.
The scope of the issue isn't limited to SSH, that's just a popular
example people are using. Any program calling bash could potentially
be vulnerable.Agreed. My point was that bash is not all that popular on
debian/ubuntu for accounts that would be running public facing
services that would be processing user defined input (www-data,
cgi-bin, list, irc, lp, mail, etc). Sure some non-privileged user
could host their own cgi script on >:1024, but that's not really a
critical "stop the presses!!" upgrade issue, imho.This is already made it to /. so I'm not sure why Randy was being so hush
hush...
But my read is that this could affect anything that calls bash to do
processing, like
handing off to CGI by putting in headers to p0wn the box. Also: bash is
incredibly
pervasive though any unix disto, in not at all obvious places, so I
wouldn't be
complacent about this at all.
Mike
If someone is already invoking #!/bin/bash from a cgi, then they are
already doing it wrong (bash has massive bloat/overhead for a CGI script).
But I do agree, it's hard to know exactly what idiots do.
Maybe just mis-informed, they become idiots if they keep doing it
after someone pointed it to them =D
You sure you don't have *any* cgi's that do something like
system("mail -s 'cgi program xxyz hit fatal error' webadmin@localhost");
because all it takes is finding a way to force the fatal error while you
send a crafted User-Agent: header....
As Jim Popovitch said, bash usage is incredibly pervasive....
> If someone is already invoking #!/bin/bash from a cgi, then they are
> already doing it wrong (bash has massive bloat/overhead for a CGI
script).
You sure you don't have *any* cgi's that do something like
system("mail -s 'cgi program xxyz hit fatal error' webadmin@localhost");
because all it takes is finding a way to force the fatal error while you
send a crafted User-Agent: header....
That won't automatically invoke bash on Debian/Ubuntu....unless someone
intentionally changed default shells....
-Jim P.
People seem not to know that Debian and derivatives use a variant Almquist shell rather than bash for system accounts.
Daniel
Once upon a time, Daniel Jackson <fdj@mindspring.com> said:
>That won't automatically invoke bash on Debian/Ubuntu....unless someone
>intentionally changed default shells....People seem not to know that Debian and derivatives use a variant
Almquist shell rather than bash for system accounts.
It doesn't have much to do with default shells or system account
settings; it has everything to do with what is /bin/sh. I think /bin/sh
has been dash (derived from NetBSD's Almquist shell) on Debian-derived
systems for a while now. Other major Linux distributions, e.g.
RHEL/Fedora family and IIRC SuSE, use bash as /bin/sh though, so should
be patched ASAP (especially if they are web servers).
Has anybody looked to see if the popular web software the users install
and don't maintain (e.g. Wordpress, phpBB, Joomla, Drupal) use system()
or the like to call out to external programs? What about service
provider type stuff like RT? I know Nagios calls out to shell scripts
for notifications and such, and passes some things in environment
variables (don't know if it can be tricked in this fashion though).
Has anybody looked to see if the popular web software the users install
and don't maintain (e.g. Wordpress, phpBB, Joomla, Drupal) use system()
Wouldn't it be great if it was JUST system()? It's also popen(),
shell_exec(), passhru(), exec(), backtic operator.
I am pretty sure ALL of them use at least 1 of these in various places
out of the box, and many plugins use these as well, such that a
shell could be invoked, but popen() on $sendmail is particularly
common.
You're both wrong.
$ cat /etc/issue
Debian GNU/Linux 7 \n \l
$ ls -laF /bin/sh
lrwxrwxrwx 1 root root 4 Nov 17 2011 /bin/sh -> bash*
$ grep root /etc/passwd
root:x:0:0:root:/root:/bin/bash
If you installed Debian from scratch in the last couple of years you
might have gotten a different system shell. Those of us who have been
using Debian for a *long time* were asked once during one upgrade
whether we wanted the upgrade to change our defaults and generally
said no.
Welcome to production fellas, where the bleeding edge latest thing
isn't what's installed.
Regards,
Bill Herrin
You have done something wrong/different than what appears on a
relatively clean install:
$ cat /etc/issue
Debian GNU/Linux 7 \n \l
$ cat /etc/debian_version
7.6
$ ls -laF /bin/sh
lrwxrwxrwx 1 root root 4 Mar 1 2012 /bin/sh -> dash*
$ grep root /etc/passwd
root:x:0:0:root:/root:/bin/sh
I'm curious now... did you install a server or desktop version of
Debian? Was if from netinst or cds, etc.?
-Jim P.
Since you didn't read it, I'm gonna repeat it:
"If you installed Debian from scratch in the last couple of years you
might have gotten a different system shell. Those of us who have been
using Debian for a *long time* were asked once during one upgrade
whether we wanted the upgrade to change our defaults and generally
said no.
Welcome to production fellas, where the bleeding edge latest thing
isn't what's installed."
-Bill
I *did* read that, and it doesn't change anything about what I wrote.
Debian didn't make those changes for you...... Debian has never set
root's shell to bash, ever. PEBKAC?
-Jim P.