Stunned by Shellshock Bash bug? Patch all you can – or be punished The UK's privacy watchdog is urging organisations to protect their systems against the infamous Shellshock vulnerability in Bash – even though the full scope of the security bug remains unclear. The Shellshock flaw affects Bash up to and including version 4.3. It's a vital component of many Linux and Unix systems, as well as …
Take a closer look at that TrustSec proof-of-concept:
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
That's an evil DHCP server sending shell script to the client, which will get executed under root (if the dhcpclient is configured to use bash at all)
So may be a rather bigger attack surface than just "LOL! Lame CGI!" - what other services have helpful extensions like this?
"So if I replaced the echo 'foo' command with rm -rf /, a DHCP server could essentially wipe out any linux machine that requested an IP address which runs bash."
dhcpclient normally runs as a daemon under the root user ... which almost never has bash as its shell. Solaris has the good old bourne shell (sh) for its root user. Linux doesn't have a bourne shell, so its root user runs the Korn shell instead, in bourne shell mode.
This is mainly because the bourne shell is statically linked, so still functions if your system is b0rked and half your file system isn't mounted.
Only interactive users tend to be configured with bash ... but you find a lot of sysadmins have set up web service daemon logins which are configured with bash because they're used to running it as their interactive shell and write scripts using bash syntax and builtins which aren't available in Korn shell.
Mongo: "That's an evil DHCP server sending shell script to the client,"
That's a disturbing application of the shellschok misfeature. I might change my mind on the scope now.
Then again, this example is then also about the insecurity of DHCP client-server model (unauthorized DHCP servers being a well known and unpatched attack vector). Plus the proof of concept will probably work only with the DHCP client using the dhclient-script process (written by Ted Lemon). For some reason they found it nice to pass parameters to the subprocess by setting environment variables. It's the naive, 80-90's somewhat lame but also consistent "CGI approach" -- deeply embedded (in my view) in some of the UNIX philosophy of the time: everything a file, composite approach, interconnecting well made general tools through simple, transparent mechanisms, etc. But it makes it too easy to trick as well ("worse is better?") with all the current day security challenges.
So, whilst being thorough in one's investigations and not download the first patch that one comes across could well lead to one being fined.
Sometimes I think that these bodies are all about revenue gathering rather than being there to provide advice and support to those who need it.
Not everyone who hosts a server, this could be anyone on the end of a fixed IP address (and in fact not necessarily that), has the knowledge to understand all this stuff but enough to host their own stuff and threatening them with fines isn't really the way forward.
I did a web search before purchase and picked one that was hackable. There is a magic sequence of buttons on the remote control that gives you the service/retail menu. One of the options enables shell access on a serial port on two unused pins on the VGA input. Just solder a VGA connector to a 3.3V serial to USB converter, plug it into your Pi and start miniterm. I picked an old TV, so most of the work had already been posted on the internet already. Take a look here to see what sort of things are available.
I strongly recommend searching for a hackable device before purchase - especially for long lifetime items like a TV. If you cannot recompile and install the firmware yourself then you are dependant on the vendor producing patches. Plenty of vendors think that ending support for a product is a good way to force users to buy a new toy. Just imagine how bad things would get if computers used secure boot so people could not install their own BIOS...
Ahh, thanks - good plan. I will keep that in mind in the future.
Also reminds me of the Hewlett Packard 486's in the early 90's that had passworded BIOS so the user couldn't mess about, and the Compaq models that had non-standard sized floppy discs and shit so you couldn't replace anything from off the shelf, but had to pay £50+ more to get a Compaq one :)
This post has been deleted by its author
Debian and Rasbian use dash not bash by default so a default install wouldn't have a problem. Similarly busybox, which is often used in embedded systems, uses ash so no problem. It would only be when one has specifically configured one of these systems to use bash where they would have a problem.
After heartbleed and now this, which was apparently lurking in plain sight for 22 years, one has to wonder what else can be found in long-trusted code. I would imagine miscreants will be paying a lot more attention than before to common open source software as it seems it could be rather fertile ground for exploits that have long been overlooked.
I am loath to say it - but Microsoft's 'security through obscurity' might be a better option sometimes. But as you say, how many 1000's of exploits are in their code that will never be patched.
At least the *nix guys have started to fix this within hours of the first post.
"Microsoft's 'security through obscurity' "
Microsoft have never taken that approach.
"how many 1000's of exploits are in their code that will never be patched."
Statistic show that the quality of Open Source code is generally no better than commercial code, and often much worse. Open SSL springs to mind...
bash is like a gun - powerful and dangerous, but fairly safe if kept in a locked cabinet ("Authentication"). If you leave it lying around or your kids get the keys to the cabinet, bypassing the safety mechanisms - Then you have a problem!
John Leyden, thank you for describing it as "vulnerability" or "flaw" rather than a bug in bash
bash is like a gun - powerful and dangerous, but fairly safe if kept in a locked cabinet ("Authentication"). If you leave it lying around or your kids get the keys to the cabinet, bypassing the safety mechanisms - Then you have a problem!
The problem with shellshock is that this is true, but bash was not being kept in the cabinet - most Linux distros use bash as their shell interpreter "/bin/sh" which means that every single time you invoke a command using the shell, it invokes bash. Most other UNIX like operating systems do not use bash as their "/bin/sh", they use "sh".
The attack vectors for shell shock involve passing spurious environment variables to bash - Linux servers that invoke CGI shell scripts are particularly vulnerable, because the CGI spec specifies that arguments are passed as environment variables, making it trivial to provide a URL argument - without authentication - that triggers the parsing bug (and it is a bug, bash executes commands that it should not. There is expected behaviour for this scenario - ie it is not the result of undefined behaviour - and bash fails to meet the expectation. Classic bug).
"most Linux distros use bash as their shell interpreter "/bin/sh"
WTF? When did they change that?? Just checked a RedHat system I develop on, and you're quite correct ...
/bin/sh -> bash
Last I knew, /bin/sh was symlinked to the Korn shell on Linux. /bin/sh is supposed to be a statically linked binary so you can rescue your system without all the shared libraries available.
FFS.
"bash is like a gun - powerful and dangerous"
Windows has a much more powerful scripting language than BASH in Powershell - and that's secure by default - it will only run signed scripts remotely. So I guess following your analogy - a heavy machine gun / grenade launcher - but locked in a gun safe. A much higher level of security that BASH could clearly benefit from...
Well, the attack is based on a feature of Bash. This means that it's been "out in the open" for the entire existence of the feature, not hidden as an oopsie-daisy bug in the source code. It also points out why it's a bad idea to have so much running with root permissions, besides not sanitizing input. And why it's a bad idea to allow just any server to throw whatever traffic it likes out onto the network.
The equivalent on a Windows system would be to pass in PowerShell script and .NET binaries through the http request, and then run it all with Administrator permissions. Attacks like these should be in the category of GET root!
> Well, the attack is based on a feature of Bash.
No - it is a *bug*. The ability to define functions in env vars was the feature. The unintended consequence of using a poorly implemented parser was that it proceeded to *execute* text that may come *after* the function definition in the env var.
> This means that it's been "out in the open" for the entire existence of the feature
Nope. Nobody ever considered the possibility that extraneous text following such a function definition would be executed *directly*. At least, we *hope* that it was the good guys who found this first. But we really don't know.
> It also points out why it's a bad idea to have so much running with root permissions, besides not sanitizing input.
Yes. And why SUID/setuid is such a monumentally bad idea. It is a deliberate hole in a too simplistic security model.
> The equivalent on a Windows system would be to pass in PowerShell script and .NET binaries through the http request, and then run it all with Administrator permissions.
Not sure I agree. That is such an obviously bad idea that nobody would ever do it. Shellshock is - after all - a bug (unintended behavior). However, there are multiple historic reasons on Unix/Linux that tend to amplify this bug:
1: The (dumb) decision to use env vars to pass parameters through the Common Gateway Interface (CGI). Env vars are stubbornly persistent: They are inherited by all child processes. This serves to make security auditing much harder: You cannot simply audit the script that *received* control directly from CGI; you also has to consider all processes that can ever be launched from the script, its child processes or descendants.
2: Inadequate and too restrictive Unix security model. This led to the invention of SUID/setuid (a hole in the security boundary) because there were still a lot of tasks that "plain users" (or least privilege daemons) legitimately needed to perform - such as printing, listen on sockets etc. Rather than refining the security model, SUID punched a deliberate hole in it. However, this means that user accounts are frequently not granted rights to access a *resource* or a syscall - rather they are granted right to launch an *executable* (SUID) that will execute with an effective user (often root, sadly) who has access to the resource. Which means that you have created a culture where you all but *need* to launch processes through system() calls to get the job done. With a proper security model where such right could be *delegated* you would not have to invoke external executables.
3: Old software that lingers on even in modern operating systems. It has long been accepted that the bash parser is, well, quirky. The way that it is semi-line oriented, for instance (definitions only take effect on a line-by-line basis). Today, parser construction is under-graduate stuff, all the principles are well known. The bash code in question was written in another era and by another community where those principles were perhaps not as well known as they are today.
>1: The (dumb) decision to use env vars to pass parameters through the Common Gateway Interface (CGI). <
I tried to convice the openVPN people that internal use of environment variables to run executables on Windows was a known security flaw, which could lead to unintended consequences if an exploit was developed. They weren't convinced.
I think that perhaps the idea of using environement variables was too deeply embedded in the culture.
Posted this on another article but it warrants repeating. I'm seeing a spike in phishing emails from obviously compromised domains today, enough that a couple has slipped through the net and one of the clients is now being cleansed by PXE fire after contracting a bit of ransomware. Might be a good time to remind the prolies that nobody sends confidential finanicial information in a link to an obscure building contractor's website, and that clicking links in emails that are obviously sus is grounds for cruel and unusual punishment.
. . . clicking links in emails that are obviously sus is grounds for cruel and unusual punishment.
Dylbot is spot on. Clicking on these links is the IT equivalent of engaging in unprotected sex with monkeys.
However, as the US CAN-SPAM regulations are implemented in practice, this is exactly what the recipients of SPAM and phishing e-mails are expected to do to "opt" out unsolicited e-mails.
This points up the insanity of relying on badly worded laws and even more arcane and convoluted regulations to address real technical problems.
As a side note, my personal take is that the US FISMA puts any chance of serious computer security into the "too-hard-to-do" box. It effectively requires constant patching and updates of programs by third party vendors. These are invisible to most small and medium business users. (Being proprietary, they are also invisible to most system administrators.) This deprives the business users at the application level of essential knowledge of the configuration and functions of the system.
The f* impossible to comply (ITC) defense.Embedded and appliance business users should have no problem there -- at least in court. But that'll be cold comfort when all your customers leave in anger because they have no one else to blame. IT is a swamp. Appliances are sinkholes masquerading as bridges. It isn't the public's fault that modern day snakeoil sales go unregulated -- except to the degree that they keep electing legislatures who are too stupid, lazy and greedy to deal with the problem.
This post has been deleted by its author
"This flaw could be allowing criminals to access personal data held on computers or other devices. For businesses, that should be ringing real alarm bells, because they have legal obligations to keep personal information secure."
This article points to a discernible trend on the part of governments and regulators to push responsibility legal liability for information security to the average business user. . .the vast majority of whom are categorically incapable of effective action.
These "legal obligations" and the threat of action against businesses who fail to maintain security beg several critical questions. . . How do the average small to medium-sized business, running out-of-the-box consumer software and dependent on commercial internet service providers determine their vulnerability? What practical steps can they possibly take to ensure that they can demonstrate due diligence in a court of law when held liable?
Finally what, if any, responsibilities do the big IT companies, special interests, legislators, and regulators--all of whom are in a position to address the issues and all of whom in some tangible or intangible way profit from the status quo--bear.
in a logical world, the person who takes the money for the product.
This isn't one of those worlds.
The govt can leave social security / criminal record data lying around for anyone to grab whenever they want, but know beyond doubt that they don't pay any fines or face any real sanctions themselves (when was the last time you heard of a civil servant being held personally liable for fines?), and yet can threaten small organisations with all kinds of things from behind their safe "someone else will pay-"wall.
The shop I work in used to be just FreeBSD. When I started about ten years ago, the boss was still insisting that everyone use csh, and I threw a fit - "This is the noughties, we have bash and it is good!". He relented, and we got bash rolled out everywhere as an optional shell.
This week, he has absolutely loved it - "It's all your fault BOY" he thundered from across the room. I did have to point out that actually we still aren't exposed as all our scripts are still sh and not bash, and remember all those new linux servers you bought because you won't pay enough for FreeBSD administrators, they're ALL vulnerable.
How he remembers who proposed installing a package 9 years ago when he can't remember approving new SSDs for our DB servers last week...
@theodore > Um... isn't /bin/sh linked to /bin/bash?
Simplifying: Only on systems that don't have the Bourne shell installed.
Because Bash is considered to be a superset of Bourne, many OS distributions assume that genuine Bourne shell scripts will run perfectly if passed to Bash. In which case they dispense with Bourne shell. That seems to be how most Linux distributions treat the Bourne Shell. /bin/sh is not a link to /bin/bash on the OS X 10.9.5 system that I'm typing on and although the executables are the same size, they're not identical. However the /bin/sh does allow me to assign an array variable, so it probably is bash. In Solaris up to version 10, /bin/sh is the Bourne shell, whereas in Solaris 11 it's linked to ksh93! A proper Bourne shell is still available: /usr/sunos/bin/sh. I'll get my coat before this delves into every Unix variant!
So, just tell them in writing it's not vulnerable? Or better yet put a message somewhere on your main support site...
And, just because they are running windows, doesn't mean they are not vulnerable to stuff embedded in products.
Which is easier when making your previously UNIX only product run on windows, re-write all your scripts in powershell or compile and ship a bash interpreter for windows and just change some paths...
Cygwin based services can use bash, including apache with cgi etc.
These things can happen in the real world.
People usually want things in writing to document a legal position. My concern would be that if a variant of the attack to which they were vulnerable emerged, the customer might claim that they were damaged by relying on faulty information.
The fact that the advice might have been right at the time may not hold up, if the customer trots out a parade of "experts" to testify that the emergence of a Windows threat was reasonably predictable.
@jJusticesays's point about things happening in the real world, is correct--and the technical thrust of the post is sound. The concern is that the legal system is often ill-equipped to sort out the complex technical arguments when litigation is the thing that happens.
Running Windows is no protection if you run a bash shell under it, either directly or via Cygwin, for example, I assume.
It's not the operating system. It's the shell programme and the web server software.
Has anyone proved bash is the only shell that has this behaviour (older implementations)?
Regarding the chap asserting that sh is a link to bash: only on Linux unless your friendly SA has copied this on your OS X or Solaris or AIX or BSD.
"Apache system, software which includes the Bash component." ... errr ....
"Unix is an operating system on which many others are built, such as Linux and Mac OS" ... errr ....
and this gem:
"That such key parts of everyday technology are maintained in this way is a cause for concern, said Tony Dyhouse from the UK's Trustworthy Software Initiative."
This, from a man who can't even maintain his own profile on the UK's Trustworthy Software Initiative's website.
Next we'll have the Beeb saying that PwC are nice, kind and considerate people for stealing iPhone prepayments from Phones4U customers while also publishing the email addresses of the affected people.
This post has been deleted by its author
I'm patched ... phew!
GNU bash, version 4.3.26(1)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
-`NO WARRANTY` :P
Uh Oh, what about my router? That's *nix, let's hope it's busybox. TaDahh! We now have 'Security by assumption'
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
