First Shellshock Botnet Attacking Akamai, US DoD Networks 236
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."
Confused. (Score:5, Funny)
Italian? wopbot?
I'm at a loss for words - other than that seems offensive, even for non-politically-correct me.
Re: (Score:2)
Re:Confused. (Score:5, Funny)
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.
its on ! (Score:4, Interesting)
no venerability should be without a logo :
https://twitter.com/johnjonesname [twitter.com]
quality reporting! 16.7 addresses! (Score:5, Funny)
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! (Score:4, Funny)
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: (Score:2)
Just kidding. They use a late 80s anti-piracy decoder wheel and some silly putty.
Whew ... (Score:2)
... how many [wikipedia.org] Linux servers are there?
And there's not many D0D IP addresses, either ... (Score:2)
From TFA:
The US DoD network in question is the 215.0.0.0/8 range, with approximately 16.7 addresses.
Bold is mine.
Re: (Score:2)
To clarify:
Each /8 block contains 16,777,216 addresses. [wikipedia.org]
Suspicious screenshot (Score:4, Insightful)
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: (Score:2)
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: (Score:2)
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 (Score:5, Informative)
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
Ugly.
Only the beginning (Score:5, Informative)
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 [trustedsec.com] for example).
You can check if you've been scanned for exploitable CGIs using something like (adjust apache logs path accordingly):
grep cgi
And you can check if your bash is vulnerable using:
env x='() {
If 'vulnerable' appears, it is.
Re: (Score:2)
Re: (Score:2)
Scanned Twice... (Score:2)
I saw scans today starting just after noon Pacific Time.
Re:Only the beginning (Score:4, Informative)
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: (Score:2)
Re: (Score:2)
...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: (Score:3)
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: (Score:2)
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.
Re: (Score:2)
shellshock-scan started hitting me yesterday:
209.126.230.72 - - [25/Sep/2014:00:06:09 +0200] "GET / HTTP/1.0" 200 677 "() {
Then real bad guys
89.207.135.125 - - [25/Sep/2014:07:50:56 +0200] "GET
Hello Rackspace!
Re: Only the beginning (Score:2, Informative)
Re: (Score:2)
You're incorrect. The default shell is tcsh on FreeBSD [freebsd.org], and bash isn't even installed by default.
Re: (Score:2)
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 (Score:3, Interesting)
Re: (Score:2)
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 (Score:2)
Re: (Score:2)
Re: (Score:3)
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: (Score:2)
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 [ubuntu.com] if you like.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:2)
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: (Score:3)
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:
and the Karma Bonus
Who cares about
Re: (Score:3)
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 u
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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: (Score:3)
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 thin
Re: (Score:2)
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: (Score:2)
I put together a small example [debian.net] for you.
Re: (Score:2)
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: (Score:2)
You're right, and Linux actually ignores the setuid bit on shell scripts. I forgot about that earlier.
Re: (Score:2)
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: (Score:2)
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 (Score:4, Informative)
only on 14.04... 1.3 is coming [launchpad.net], I'm told..
Bash needs to remove env-based procedure passing (Score:5, Interesting)
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
Re: (Score:2)
Amazing... (Score:2, Interesting)
... 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: (Score:3, Insightful)
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... (Score:5, Interesting)
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: (Score:2, Interesting)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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
Re:Amazing... (Score:4, Informative)
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 ...
Use the bug to patch the bug (Score:5, Insightful)
Re: (Score:2)
Ah, who am I kidding? Debian's bash version is so ancient it probably doesn't even support environment variables yet....
Re: (Score:2)
Debian's bash version is so ancient it probably doesn't even support environment variables yet....
There's something after 4.3?
Too much scripting in Linux (Score:3)
bash accessible from outside? (Score:3)
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:Question about how this works (Score:5, Informative)
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 (Score:5, Informative)
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 (Score:4, Informative)
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: (Score:2, Insightful)
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 s
Re: (Score:2)
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 hotsp
Re: (Score:2)
Case in point, perhaps...
Mediawiki has:
$wgDiff3 = "/usr/bin/diff3";
Maybe nobody uses Mediawiki anymore...
Re: Question about how this works (Score:2)
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: (Score:3)
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 (Score:5, Insightful)
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 (Score:4, Informative)
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: (Score:3)
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 (Score:5, Informative)
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 (Score:5, Informative)
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: (Score:3)
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: (Score:2)
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 e
Re: Question about how this works (Score:2)
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:patched my servers last month (Score:4, Insightful)
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: (Score:3)
Well...
As a software engineer they expect me to be a sysadmin.
I know that feeling all too well...
Re: (Score:2)
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.
Re:patched my servers last month (Score:4)
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.
Re: (Score:2)
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 (Score:2)
Are you joking or trying to mislead?
Re: (Score:2)
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: (Score:2)
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: (Score:2)
> 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 (Score:5, Informative)
Fix for CVE-2014-7169 was posted only a small bit ago:
http://www.openwall.com/lists/oss-security/2014/09/26/1
Re: (Score:2, Flamebait)
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: (Score:2)
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 [imagicity.com] 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
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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... [gnu.org]
Re: (Score:2)
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).
Re: (Score:3)
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.