3 ms·

Does anyone know what Apples policy on fixing this might be? I understand why they ship with an older version of bash and other GNU userspace tools but is there

Does anyone know what Apples policy on fixing this might be? I understand why they ship with an older version of bash and other GNU userspace tools but is there a precedent they've set for backporting?

skuhn 12y ago
They won't have to backport the fix, there is a patch directly against bash-3.2 (which ships in OSX): http://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 http://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 They do update bash occasionally, even though it is trapped forever in a pre-GPLv3 world: http://www.opensource.apple.com/source/bash/ http://www.opensource.apple.com/source/bash/. For instance, bash-86.1 shipped in 10.8 and bash-92 shipped in 10.9. I don't know if they will hop right on this (and personally I find the issue overblown), but I imagine it will get patched at some point.
- deleted 12y ago
  [deleted]
- bodyfour 12y ago
  OS/X does use bash as /bin/sh unfortunately so it is fairly vulnerable. Probably most people won't be affected though since there aren't many good attack vectors against a client machine, and not many people are still using macs for servers. I don't think that the issue is overblown at all though. CGI is old and crusty but it's sitting in all sorts of random places. All you need to do is to find a script that will call system()/popen()/etc and it's game over. Plus those are just the sorts of forgotten environments that people won't remember to patch. I'm sure there will be thousands of exploitations in the next couple days. This is a big deal.
  - skuhn 12y ago
    bash on OSX is vulnerable, but as you say, there are few attack vectors. A client OSX machine with a stock config is not vulnerable. At a minimum, you have to enable a network service like printer sharing (CUPS), remote login (ssh), web sharing (Apache). Then you have to configure the service in such a way to actually be vulnerable, and these are not commonly configured options. The attacker also has to have a local privilege escalation vulnerability to exploit as well, or they're trapped as the CUPS user once they do bust in. I don't think that the level of panic I have seen on other Hacker News threads and elsewhere on the Internet is warranted. Comparing this to Heartbleed is pretty absurd; TLS vs bash CGI is no contest in terms of deployment size. I'm mainly concerned with public-facing, large scale web services, and in that area: 1. CGI in general and bash CGI in particular are basically unheard of. 2. system() in other scripting languages might be used, BUT to be vulnerable you have to pass through user-supplied data as environment variables without sanitizing. This was always an exploit waiting to happen. 3. ssh accounts with a command forced in authorized_keys are potentially problematic, but this would only be from users who have some relationship to your service in the first place. Personally I think a restricted shell (rsh or git-shell or whatever) is a more common option, simply because who knows what bash might get up to. 4. DHCP client scripts on Linux is an interesting exploit path, and might be a problem for laptops on shared wifi, but for the majority of Linux servers there is no attack vector. They live on controlled networks where rogue DHCP servers can't be operated. So yes, patch the vulnerability and audit your systems and code. Also keep the response proportional to the vulnerability, this one needs a lot of other things to fall into place to be exploited.
    - bodyfour 12y ago
      I generally agree with this, but I do have a few nitpicks. > Comparing this to Heartbleed is pretty absurd They're such different bugs that they're hard to compare. Heartbleed definitely affected more high-value targets, however the exploit just gave you some RAM contents. It would still be some manual work to figure out what those values meant (whcih bits are ssh keys, which are passwords, ...) and leverage them. Shellshock is much better suited for a "sweep all of IPv4, build a botnet" scriptkiddie attack. > bash CGI in particular are basically unheard of The CGI doesn't have to be written in bash, it just has to call something that calls something that ends up calling system()/popen()/whatever. There are probably lots of such cases. Once httpd puts the poisonous string in your environment it's going to be passed down to all of your subprocesses. If you're using CGI at all on a machine with /bin/sh==bash you should assume you're vulnerable. > They live on controlled networks where rogue DHCP servers can't be operated. If you're on a network with nodes you don't trust (public wifi, large corporate networks, etc) there is a risk that machines other than the router will reply to broadcast DHCP requests. I don't know the full scope of this attack vector yet but I wouldn't be blasé about it.
      - skuhn 12y ago
        > They're such different bugs that they're hard to compare. I mentioned it because people are having a field day comparing the two (which results in some good old fashioned fear mongering). A random sampling: CNet: 'Bigger than Heartbleed' Gizmodo: Why the Bash Shellshock Bug Could Be Even Worse Than Heartbleed Mashable: Shellshock: The 'Bash Bug' That Could Be Worse Than Heartbleed The Independent: Shellshock: Bash bug 'bigger than Heartbleed' could undermine security of millions of websites Errata Security: Bash bug as big as Heartbleed > The CGI doesn't have to be written in bash This was covered in my second item, about using system(). I'm certain that there is software out there that does this, but it is in no way common or has ever been best practice. The panic over this presumes that people use CGI all the time. It's awful, it's always been awful, and should never be used for anything public facing for lots of other reasons. Note that FastCGI is not impacted. > If you're on a network with nodes you don't trust Correct, but this isn't the case for most (but not all) server deployments. In your own datacenter environment, you control the network and all of the hosts on it -- if someone busts in to run a DHCP server, you have bigger fish to fry.

skuhn 12y ago

They won't have to backport the fix, there is a patch directly against bash-3.2 (which ships in OSX): http://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 http://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 They do update bash occasionally, even though it is trapped forever in a pre-GPLv3 world: http://www.opensource.apple.com/source/bash/ http://www.opensource.apple.com/source/bash/. For instance, bash-86.1 shipped in 10.8 and bash-92 shipped in 10.9. I don't know if they will hop right on this (and personally I find the issue overblown), but I imagine it will get patched at some point.

deleted 12y ago
[deleted]
bodyfour 12y ago
OS/X does use bash as /bin/sh unfortunately so it is fairly vulnerable. Probably most people won't be affected though since there aren't many good attack vectors against a client machine, and not many people are still using macs for servers. I don't think that the issue is overblown at all though. CGI is old and crusty but it's sitting in all sorts of random places. All you need to do is to find a script that will call system()/popen()/etc and it's game over. Plus those are just the sorts of forgotten environments that people won't remember to patch. I'm sure there will be thousands of exploitations in the next couple days. This is a big deal.
- skuhn 12y ago
  bash on OSX is vulnerable, but as you say, there are few attack vectors. A client OSX machine with a stock config is not vulnerable. At a minimum, you have to enable a network service like printer sharing (CUPS), remote login (ssh), web sharing (Apache). Then you have to configure the service in such a way to actually be vulnerable, and these are not commonly configured options. The attacker also has to have a local privilege escalation vulnerability to exploit as well, or they're trapped as the CUPS user once they do bust in. I don't think that the level of panic I have seen on other Hacker News threads and elsewhere on the Internet is warranted. Comparing this to Heartbleed is pretty absurd; TLS vs bash CGI is no contest in terms of deployment size. I'm mainly concerned with public-facing, large scale web services, and in that area: 1. CGI in general and bash CGI in particular are basically unheard of. 2. system() in other scripting languages might be used, BUT to be vulnerable you have to pass through user-supplied data as environment variables without sanitizing. This was always an exploit waiting to happen. 3. ssh accounts with a command forced in authorized_keys are potentially problematic, but this would only be from users who have some relationship to your service in the first place. Personally I think a restricted shell (rsh or git-shell or whatever) is a more common option, simply because who knows what bash might get up to. 4. DHCP client scripts on Linux is an interesting exploit path, and might be a problem for laptops on shared wifi, but for the majority of Linux servers there is no attack vector. They live on controlled networks where rogue DHCP servers can't be operated. So yes, patch the vulnerability and audit your systems and code. Also keep the response proportional to the vulnerability, this one needs a lot of other things to fall into place to be exploited.
  - bodyfour 12y ago
    I generally agree with this, but I do have a few nitpicks. > Comparing this to Heartbleed is pretty absurd They're such different bugs that they're hard to compare. Heartbleed definitely affected more high-value targets, however the exploit just gave you some RAM contents. It would still be some manual work to figure out what those values meant (whcih bits are ssh keys, which are passwords, ...) and leverage them. Shellshock is much better suited for a "sweep all of IPv4, build a botnet" scriptkiddie attack. > bash CGI in particular are basically unheard of The CGI doesn't have to be written in bash, it just has to call something that calls something that ends up calling system()/popen()/whatever. There are probably lots of such cases. Once httpd puts the poisonous string in your environment it's going to be passed down to all of your subprocesses. If you're using CGI at all on a machine with /bin/sh==bash you should assume you're vulnerable. > They live on controlled networks where rogue DHCP servers can't be operated. If you're on a network with nodes you don't trust (public wifi, large corporate networks, etc) there is a risk that machines other than the router will reply to broadcast DHCP requests. I don't know the full scope of this attack vector yet but I wouldn't be blasé about it.
    - skuhn 12y ago
      > They're such different bugs that they're hard to compare. I mentioned it because people are having a field day comparing the two (which results in some good old fashioned fear mongering). A random sampling: CNet: 'Bigger than Heartbleed' Gizmodo: Why the Bash Shellshock Bug Could Be Even Worse Than Heartbleed Mashable: Shellshock: The 'Bash Bug' That Could Be Worse Than Heartbleed The Independent: Shellshock: Bash bug 'bigger than Heartbleed' could undermine security of millions of websites Errata Security: Bash bug as big as Heartbleed > The CGI doesn't have to be written in bash This was covered in my second item, about using system(). I'm certain that there is software out there that does this, but it is in no way common or has ever been best practice. The panic over this presumes that people use CGI all the time. It's awful, it's always been awful, and should never be used for anything public facing for lots of other reasons. Note that FastCGI is not impacted. > If you're on a network with nodes you don't trust Correct, but this isn't the case for most (but not all) server deployments. In your own datacenter environment, you control the network and all of the hosts on it -- if someone busts in to run a DHCP server, you have bigger fish to fry.