Yep. We're currently basically waiting to see which completes first: a) a patch for bash which actually works gets released and then trickles into the various ways to get it on every machine in the world or b) someone writes ~10 lines of payload code (download rootkit, execute, connect to IRC channel, join botnet, etc) and then just hits everything in IP4 space with a for loop. Optionally, the for loop gets distribut…
It won't be as simple as scanning all IP4 space because for most vulnerable hosts you still will need to know a URL of a cgi program that can cause bash to be executed (either because they're written in shell or, more likely, that there is some path found that can cause popen()/system()/etc to be called) If you read Robert Graham's blog post about his scan for this (posted to HN earlier today) he mentioned that the h…
Bash 'shellshock' bug is wormable
91–100 of 157 posts
Re: Bash 'shellshock' bug is wormable
#92Earlier quoted context omitted.
I suspect that many folks who "don't run bash" actually do use bash quite a bit, e.g. in initscripts and various software packages.
Any decent shell script is written to use "sh" not bash, and on debian/etc sh is provided by dash not bash. So while a lot of people are affected, your reasoning points to other issues that are very solveable
Re: Bash 'shellshock' bug is wormable
#93I have a macbookpro which is my developer workstation. It is in a default configuration, it is on 12 hours a day, always behind a NAT. What do I need to do to protect myself?
Re: Bash 'shellshock' bug is wormable
#94Shellshock is a perfect name coming after Heartbleed. But this bug is suffering from lack of marketing, lagging in the news behind the iOS update being pulled. It's sad to see an RCE somewhere so widespread and so interwoven with other software. It's also costly because now I'm questioning server integrity, thinking about what should really be re-imaged. I assume there are many more like this in the CVE pipeline... A…
Re: Bash 'shellshock' bug is wormable
#95Honest question: does this mean this vulnerability has been in bash for essentially its entire history and someone only discovered it now? Seems quite likely that someone would have discovered it sooner, especially since it's so simple to exploit.
Ease of exploitation and ease of discovery have basically nothing to do with each other. Relatedly, "many eyes makes all bugs shallow" is, and always has been, totally horsepuckey. (And despite it being horsepuckey, and horsepuckey which is trivially exploitable in that if you believe it you'll produce software which can get owned by people who are better at e.g. counting to four than you are, people still believe it…
Consider that the contraction of the more complete saying "Many eyes make bugs shallower than they would be if there were only few eyes".
Re: Bash 'shellshock' bug is wormable
#96Earlier quoted context omitted.
It won't be as simple as scanning all IP4 space because for most vulnerable hosts you still will need to know a URL of a cgi program that can cause bash to be executed (either because they're written in shell or, more likely, that there is some path found that can cause popen()/system()/etc to be called) If you read Robert Graham's blog post about his scan for this (posted to HN earlier today) he mentioned that the h…
I think you underestimate attack vectors. d6c477a79ea7a633c2bb0e358e32399c1b18eb7d <-- Will ruin 1+ HNers' day sooner rather than later if they don't patch. Successful exploit doesn't require the exploit writer even knowing that vector existed to say nothing of successfully guessing a URL.
Also, I'm learning about this and am primarily concerned about the possibility of remote exploits -- if a web server returns 404 for an invalid URL, how does the attack vector work if the exploit writer does not successfully guess a URL? Thanks.
Re: Bash 'shellshock' bug is wormable
#97Earlier quoted context omitted.
I think you underestimate attack vectors. d6c477a79ea7a633c2bb0e358e32399c1b18eb7d <-- Will ruin 1+ HNers' day sooner rather than later if they don't patch. Successful exploit doesn't require the exploit writer even knowing that vector existed to say nothing of successfully guessing a URL.
What does "d6c477a79ea7a633c2bb0e358e32399c1b18eb7d" mean? Also, I'm learning about this and am primarily concerned about the possibility of remote exploits -- if a web server returns 404 for an invalid URL, how does the attack vector work if the exploit writer does not successfully guess a URL? Thanks.
Re: Bash 'shellshock' bug is wormable
#98Earlier quoted context omitted.
Is it connected to the internet? Then patch it. While you can't think of anything that could remotely execute it, you'd be damn surprised how large the attack surface is for this exploit, and how flexible it is. It's a Big Deal(TM). Everything in a Linux system uses bash (hyperbole, but not too far from the truth), and all it takes is one of those not sanitizing input and it's game over :( Basically, it may not be as…
Yeah, the annoying thing is it sounds like there isn't a full patch yet and new vulnerabilities are being discovered. Just trying to understand if I should shut the machine down until everything is sorted out.
A fair bit of warning though that some scripts might break, but at least you know why (if the alternative is to turn off the machine until you trust bash again then you may have to wait forever).
On a standard Ubuntu or Debian most shell scripts uses dash anyway so it shouldn't be too bad.
Re: Bash 'shellshock' bug is wormable
#99Earlier quoted context omitted.
Any decent shell script is written to use "sh" not bash, and on debian/etc sh is provided by dash not bash. So while a lot of people are affected, your reasoning points to other issues that are very solveable
Still, isn't sh quite often implemented as an alias/symlink for bash nowdays?
Re: Bash 'shellshock' bug is wormable
#100Earlier quoted context omitted.
Still, isn't sh quite often implemented as an alias/symlink for bash nowdays?
Yes, but Debian and Ubuntu has changed their default shell to Dash (in 2006 I think), and embedded systems usually use some lightweight shell such as BusyBox. So far from all systems do.