Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[sevenlayermuddle]

I can imagine this might turn out to be very bad indeed, for many Linuxes, including of course many web servers and home routers, which we end-users are powerless to fix.   

http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/

[roseway]

Most devices with embedded Linux systems don't use Bash. They nearly all use BusyBox, which incorporates its own minimalist shell.

[hake]

It seems that devices that cannot execute remotely scripted requests are probably not not affected.  This should include most consumer routers.

I turned up the following words in https://community.rapid7.com/community/infosec/blog/2014/09/25/bash-ing-into-your-network-investigating-cve-2014-6271

They read : -

"Modern web frameworks are generally not going to be affected. Simpler web interfaces, like those you find on routers, switches, industrial control systems, and other network devices are unlikely to be affected either, as they either run proprietary operating systems, or they use Busybox or Ash as their default shell in order to conserve memory. A quick review of a approximately 50 firmware images from a variety of enterprise, industrial, and consumer devices turned up no instances where Bash was included in the filesystem."

It goes on to say : -
"The two most likely situations where this vulnerability will be exploited in the wild:
 1. Diagnostic CGI scripts that are written in Bash or call out to system() where Bash is the default shell
 2. PHP applications running in CGI mode that call out to system() and where Bash is the default shell.

Bottom line: This bug is going to affect an unknowable number of products and systems, but the conditions to exploit it are fairly uncommon for remote exploitation."

I don't use any client computers based on Linux.  Presumably these clients are potentially vulnerable to externally initiated scripts which might exploit the vulnerability if contaminated web sites are browsed, among other things.

All this makes me feel comparitively secure running flaky (allegedly) Windows XP.  The thing about XP and other Windows is that those operating systems have never been 100% trusted and so are under constant suspicion and subject to constant rectification.  Even Windows XP (in it's POSReady guise) is still being rectified if the appropriate registry entry indentifying that OS variant is in place.  I have been running XP since 2001 and have YET (note the conditional) to experience any intrusions whatsoever, let alone their effects.

[kitz]

I noticed someone on the Plusnet forums asked earlier if home routers were vulnerable.

http://community.plus.net/forum/index.php/topic,132164.0.html

No, they're not.

[sevenlayermuddle]

There would appear to be a well justified consensus that home routers will no be affected.   

Phew.   

[kitz]

Phew indeed

[Chrysalis]

routers mostly use busybox and sh.

Although I have put bash on mine :p

[boost]

Amazed this went undetected for so long...

[roseway]

Here's (something like) the full story: http://en.wikipedia.org/wiki/Shellshock_%28software_bug%29

[kitz]

I appreciate the effort made in patch bash43-026, but this patch doesn't even BEGIN to solve the underlying shellshock problem. This patch just continues the "whack-a-mole" job of fixing parsing errors that began with the first patch. Bash's parser is certain have many many many other vulnerabilities; it was never designed to be security-relevant…John Haxby recently posted that "A friend of mine said this could be a vulnerability gift that keeps on giving.” Bash will be a continuous rich source of system vulnerabilities until it STOPS automatically parsing normal environment variables; all other shells just pass them through! I've turned off several websites I control because I have *no* confidence that the current official bash patches actually stop anyone, and I am deliberately *not* buying products online today for the same reason. I suspect others have done the same. I think it's important that bash change its semantics so that it "obviously has absolutely no problems of this kind".

Kind of worrying

[Chrysalis]

4.3.26 disables the function by default which the exploit requires, this I dont see on debian etc. yet tho, only seen it on FreeBSD ports.

Bash supports a feature of exporting functions in the environment with
  export -f.  Running bash with exported functions in the environment will
  then import those functions into the environment of the script being ran.
  This resulted in security issues CVE-2014-6271 and CVE-2014-7169, commonly
  known as "shellshock".  It also can result in poorly written scripts being
  tricked into running arbitrary commands.

  To fully mitigate against this sort of attack we have applied a non-upstream
  patch to disable this functionality by default.  You can execute bash
  with --import-functions to allow it to import functions from the
  environment.  The default can also be changed in the port by selecting the
  IMPORTFUNCTIONS option.

[Berrick]

Further flaws render Shellshock patch ineffective!

The Shellshock vulnerability in the commonly used Bash command line interpreter shell is likely to require more patches, as security researchers continue to unearth further problems in the code.

http://www.itnews.com.au/News/396256,further-flaws-render-shellshock-patch-ineffective.aspx

[kitz]

Yes I read something the other day that implies that this is going to be no easy patch as now discovered the bugs keep coming and unless the underlying issue can be fixed then it was anticipated many more were to come.  I also saw mention that it bashdoor was far more serious than anything previously discovered... and any patches released so far were the equivalent of putting a band-aid on a wound that isnt going to stop bleeding anytime soon

I dont think we can blame the programmers, anyone who has programmed knows how easy it is to miss things.. and especially with OpenSource when programmers do it for free and the community..  The unusual thing with bashdoor is that it has remained undiscovered for so long.  IMHO Windows isnt quite so the easy target these days and hackers have perhaps turned their attention elsewhere.  With the vast majority of webhost choosing to use unix/linux based systems for the additional security its supposed to have over windows, I fear the time is now upon us where the exploiters are turning their attention else-where. 

So much more data and information is held online these days and we use e-commerce so very much more than just 5 years ago... so the rewards in finding exploits in *nix systems could be so much more attractive to exploits.. and hackers  

[sevenlayermuddle]

*nix exploits are nothing new.   Indeed, I feel reasonably confident in saying that the first ever malicious buffer overrun exploit was engineered on the Unix 'finger' command, nearly 30 years ago.

What *nix has traditionally offered is a safety net, thanks to the user privilege mechanism.   As long as you are logged in as a non privileged user', anybody exploiting your session is very restricted in the damage they can do to the system, even if they can wreak havoc with your own personal files.

However, web servers are a different matter.   If the web server daemon process can be tricked into revealing (say) the banking details of other customers then that's a pretty good result for the bad guys, even if the server survives in other respects.

My own biggest nightmare - not just with this exploit, but with *nix exploits in general, is probably an attack not on web servers, but on telecoms servers, which are also often Linux based these days.   Since deregulation, every time you make a land line phone call, or register a mobile with a base station, or your CP exchanges billing details with another CP, odds on a Linux server has a finger in the pie...

[kitz]

It is all rather worrying