61–70 of 157 posts
Earlier quoted context omitted.
so bash: warning: evil: ignoring function definition attempt bash: error importing function definition for `evil' would mean it's not?
That's the message you get on a patched machine. However, the patch is not sufficient: https://news.ycombinator.com/item?id=8365216 .
Earlier quoted context omitted.
Ubuntu 10.04LTS - 14.04LTS appears to be patched: http://www.ubuntu.com/usn/usn-2362-1/ Logging into my server, things look good -- this is why you turn on automatic security updates. :)
That update appears to only patch CVE-2014-6271 and not CVE-2014-7169 ( See: https://news.ycombinator.com/item?id=8365158 ) Although 7169 appears to be more difficult to exploit than 6271, you're not out of the woods until a patch gets distributed (+applied!) that covers both CVEs.
Earlier quoted context omitted.
Front page of the site of one of the major Australian newspapers: "Largest bug ever hits the internet" I think it will start to make its way out to the public with a bit more time.
I'm sure they've picked up now that the patch was bad. Should be an interesting day. Wow the comments there are...
The patch appears to have been a adequate fix to the bug that was discovered. The fact there is a second bug with a similar but not-identical attack vector, is a reflection on the robustness/correctness of the original code more than it is a reflection on the quality of the patch.
Earlier quoted context omitted.
I run no Linux/Unix/MacOS/compatible/etc machine which connects other machines How about "I don't run bash"? There are other perfectly good shells, you know...
Or "I don't run UNIXes that default to bash, or hide it under /bin/sh, etc." Unfortunately, bash shows up in surprising places, including default Solaris installs nowadays. On OSX and Solaris, I've chmod'ed 0000 /bin/bash with no apparent ill effect so far. I'll put more effort into establishing its acceptability as a solution tomorrow. BSDs won't have bash unless someone has gone out of their way to install it, whic…
In the case of OSX, /bin/sh is also bash. For some reason they are separate binaries (at least on my laptop running 10.9.5) but they're both really bash inside:
$ ls -ld /bin/sh /bin/bash
-r-xr-xr-x 1 root wheel 1228240 Sep 21 21:37 /bin/bash
-r-xr-xr-x 1 root wheel 1228304 Sep 21 21:37 /bin/sh
$ /bin/sh --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.
$ /bin/bash --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.
(ETA: as I've mentioned elsewhere in this thread most people running OSX probably aren't badly impacted since they're not running CGI-based web software or other high-risk activity. I'm just pointing out that your bash-ectomy of OSX isn't as complete as you think it was)
I didn't realize iOS and OS X DHCP could be vulnerable. This just went from "Man a lot of other people should be worried about this" to "shit, shit, shit, shit, shit", since I don't run a web server.
Earlier quoted context omitted.
This more of a "should be", right? Maybe most shell scripts should use "sh" but I see "bash" way more often.
I guess it comes down to how you interpret things. I specifically said any decent shell script. My logic is that if it is not using "sh", but instead relying on bash (or any other specific shell really), it's not a decent shell script. If I were to amend the sentence to make the meaning clearer, I would still not use "should be", I would use "must be".
I 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?
update bash ( https://apple.stackexchange.com/questions/146849/how-do-i-re... ) or switch to a different system default shell until bash is updated.
Are you running a Web server that uses CGI scripts written in shell or plain C that uses system() call? If you do, you have had other problems long before.
There are some grumblings about DHCP _client_ setups on Linux passing parameters via environment variables to shell scripts executed by bash, but I am yet to see this. This would be a problem, but probably easily fixable.
No need to panic or even patch anything (as always). If you running servers on your machine and allow inbound connections you should know exactly what those servers are and what they execute on behalf of external users.
This is NOT remotely exploitable.
It's an ad campaign for "security researchers" people.
Are you running a Web server that uses CGI scripts written in shell or plain C that uses system() call? If you do, you have had other problems long before.
There are some grumblings about DHCP _client_ setups on Linux passing parameters via environment variables to shell scripts executed by bash, but I am yet to see this. This would be a problem, but probably easily fixable.
No need to panic or even patch anything (as always). If you running servers on your machine and allow inbound connections you should know exactly what those servers are and what they execute on behalf of external users.
This is NOT remotely exploitable.
It's an ad campaign for "security researchers" people.