Apple says most customers not vulnerable to 'shellshock,' patch coming for advanced users

Posted:
in macOS edited September 2014
Apple on Friday sought to calm OS X users who feared their computers may be at risk from a widespread vulnerability in popular UNIX command interpreter bash -- which is included in Apple's UNIX-based desktop operating system -- saying that most consumers are not at risk, while advanced users will receive a patch in the coming days.




"The vast majority of OS X users are not at risk to recently reported bash vulnerabilities," an Apple spokesperson said in a statement to iMore. "With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services," the spokesperson added, before noting that Apple is "working to quickly provide a software update for our advanced UNIX users."

The bug, nicknamed "shellshock" by members of the computer security community, is thought to be present in every version of bash since its introduction in 1989. By passing specially-crafted commands to computers running vulnerable releases of bash, an attacker could -- without authentication --?remotely execute arbitrary commands that could modify systems or exfiltrate data.

Because bash is present on nearly every Linux and UNIX system that has shipped in last 20 years, the potential for damage is immense if machines are not quickly patched. Fortunately for most OS X users, their computers are rarely directly exposed to the internet, and even more rarely are they configured to expose potentially vulnerable endpoints -- like HTTP servers --?to the network.

Advanced users who have OS X machines in a situation where they may be remotely exploited, such as systems administrators with internet-facing OS X servers, can mitigate the issue by recompiling bash with the official patches from GNU until Apple issues its own update.
«13

Comments

  • Reply 1 of 57
    malaxmalax Posts: 1,598member
    I blame that Maps and 8.0.1 QA guy. They should fire him again for this.
  • Reply 2 of 57
    rcfarcfa Posts: 1,124member
    Badly explained article: for someone to exploit bash, they would have to be able to log in first.
    If a web server allows accessing bash, then the web server must also have an exploit.
    So unless one has a guest account with shell login or is worried about illegitimate privilege escalation by legitimate users (e.g. students in a computer lab), or is stupid enough to run random shell scripts, then I don't see how this is a problem, certainly not in the way it's phrased, unless there are additional exploits/vulnerabilities besides what's in bash.
  • Reply 3 of 57
    rob53rob53 Posts: 3,241member
    Quote:

    Originally Posted by rcfa View Post



    Badly explained article: for someone to exploit bash, they would have to be able to log in first.

    If a web server allows accessing bash, then the web server must also have an exploit.

    So unless one has a guest account with shell login or is worried about illegitimate privilege escalation by legitimate users (e.g. students in a computer lab), or is stupid enough to run random shell scripts, then I don't see how this is a problem, certainly not in the way it's phrased, unless there are additional exploits/vulnerabilities besides what's in bash.

    Not what I've read. Applications use terminal-type commands in the background to create log files for one example. These don't require a logon. Look at your log files through Console and see everything that's done. Apple probably uses some bash to create crash reports, which can automatically be sent to Apple. I've seen the same thing with other applications. You're helping them fix their code by sending error messages and crash reports. I'm not saying this is how this exploit works but people need to realize there's a lot of background code that runs that they never see or understand and anything can happen behind the scenes.

  • Reply 4 of 57

    One thing that worries me quite a lot is whether or not the OS X DHCP client can/does run scripts. That would make it a very big deal non-advanced users as well. Likewise, I'm curious as to whether iOS uses bash as its underlying shell and similarly concerned about DHCP there. It would be much better if Apple were to be more forthcoming with such information when these kinds of things come up. 

  • Reply 5 of 57
    Quote:
    Originally Posted by malax View Post



    I blame that Maps and 8.0.1 QA guy. They should fire him again for this.

     

    This comment wins!

     

     

    Quote:

    Originally Posted by rcfa View Post



    Badly explained article: for someone to exploit bash, they would have to be able to log in first.

    If a web server allows accessing bash, then the web server must also have an exploit.

    So unless one has a guest account with shell login or is worried about illegitimate privilege escalation by legitimate users (e.g. students in a computer lab), or is stupid enough to run random shell scripts, then I don't see how this is a problem, certainly not in the way it's phrased, unless there are additional exploits/vulnerabilities besides what's in bash.

     

    Yup, that's usually how most exploits work these days.  It's no longer, one simple hack and the hacker now has root access.  It's now usually a complex dance of exploits strung together in a specific order and way.  Read, for example, how hackers have to jailbreak the iPhone (which *still* requires physical access to the device).

     

    So, yes, this requires a vulnerable web server (which is certainly isn't that extraordinary) that also has mod_cgi enabled, which is also a not-out-of-the-ordinary configuration if they're doing some custom development.

     

    That said, the Apple spokesman is right-- vast majority of Mac users wouldn't be running this config on their Macs.

  • Reply 6 of 57
    mjtomlinmjtomlin Posts: 2,673member
    Quote:

    Originally Posted by rob53 View Post

     

    Not what I've read. Applications use terminal-type commands in the background to create log files for one example. These don't require a logon. Look at your log files through Console and see everything that's done. Apple probably uses some bash to create crash reports, which can automatically be sent to Apple. I've seen the same thing with other applications. You're helping them fix their code by sending error messages and crash reports. I'm not saying this is how this exploit works but people need to realize there's a lot of background code that runs that they never see or understand and anything can happen behind the scenes.


     

     

    The console is just a bunch of error messages, it has nothing to with bash or any other shell. "Commands" are just executables and also don't have anything to with shells. The only time you need to run something through the "shell" is if you have a shell script or, actually run the shell in a terminal. When an application needs to run a Unix "command", they can do so through the "exec" APIs, which launches the executable - these are the same APIs any of the shells use to launch executables. When you double click on a Unix executable in the Finder, the system will open the terminal, because it assumes there may some form of user interaction required, and that of course happens through standard Unix input and output.

     

    A lot of those message you see in the console are put there by applications via the NSLog function.

  • Reply 7 of 57
    Quote:

    Originally Posted by apple_badger View Post

     

    One thing that worries me quite a lot is whether or not the OS X DHCP client can/does run scripts. That would make it a very big deal non-advanced users as well. Likewise, I'm curious as to whether iOS uses bash as its underlying shell and similarly concerned about DHCP there. It would be much better if Apple were to be more forthcoming with such information when these kinds of things come up. 


     

    Something like DHCP would not be using middleware like BASH for direct communication with the DHCP server, or even for logging to the console.  BASH is a shell environment, not something that commands like DHCP would be using.

     

    Also, any input something like DHCP would accept would be completely sanitized, and malformed data would simply be rejected.  For illustrative example, DHCP would not accept input of any number larger than 255. Or any negative numbers, or even letters at all, etc.

     

     

  • Reply 8 of 57
    mjtomlinmjtomlin Posts: 2,673member
    Quote:

    Originally Posted by apple_badger View Post

     

    One thing that worries me quite a lot is whether or not the OS X DHCP client can/does run scripts. That would make it a very big deal non-advanced users as well. Likewise, I'm curious as to whether iOS uses bash as its underlying shell and similarly concerned about DHCP there. It would be much better if Apple were to be more forthcoming with such information when these kinds of things come up. 




    OS X and iOS do not have an underlying shell. People need to understand that a shell such as bash is just an application, it serves the same purpose as the "Finder"; an application that gives you access to the "system."

  • Reply 9 of 57
    Quote:

    Originally Posted by malax View Post



    I blame that Maps and 8.0.1 QA guy. They should fire him again for this.



    good one and let's not forget the default trope - it's Tim Cook's fault and would never have happened under Steve Jobs.  

  • Reply 10 of 57
    Windows users are not vulnerable for once.
  • Reply 11 of 57
  • Reply 12 of 57
    malaxmalax Posts: 1,598member
    Quote:

    Originally Posted by markbyrn View Post

     



    good one and let's not forget the default trope - it's Tim Cook's fault and would never have happened under Steve Jobs.


    How long until a troll includes this (e.g., "shellshock patch debacle") in their bulleted list of "disasters" that proves that Apple has lost its way?  Fortunately this story doesn't (yet) include nude celeb pics or an "in the name of science" alarming video, so maybe it will blow over.  "Could the bash shell on your Mac be exploited? Tune in at 11:00 to find out!"  I don't think so.  (Unfortunately I can imagine some station going with "In the wake of the recent iCloud scare, are Apple products vulnerable to yet another hacker exploit?")

  • Reply 13 of 57
    Quote:

    Originally Posted by _Rick_V_ View Post

     
    Quote:
    Originally Posted by apple_badger View Post

     

    One thing that worries me quite a lot is whether or not the OS X DHCP client can/does run scripts. That would make it a very big deal non-advanced users as well. Likewise, I'm curious as to whether iOS uses bash as its underlying shell and similarly concerned about DHCP there. It would be much better if Apple were to be more forthcoming with such information when these kinds of things come up. 


     

    Something like DHCP would not be using middleware like BASH for direct communication with the DHCP server, or even for logging to the console.  BASH is a shell environment, not something that commands like DHCP would be using.

     

    Also, any input something like DHCP would accept would be completely sanitized, and malformed data would simply be rejected.  For illustrative example, DHCP would not accept input of any number larger than 255. Or any negative numbers, or even letters at all, etc.

     

     

     


     

    It is primarily services (daemons) such as DHCP that call bash internally that are likely to be vulnerable. DHCP input should be sanitized, but then so should any daemon input string. Historically that has not always been the default. However, that's also the reason that most user OSX installations should be safe - they are not running external service daemons. Servers, such as websites, mail relays, DHCP, and other open ports etc., would presumably be the immediate concern.

  • Reply 14 of 57
    Quote:
    Originally Posted by malax View Post



    I blame that Maps and 8.0.1 QA guy. They should fire him again for this.

     

    Yeah. And keep firing him until the phones don't bend any more! And the US gets a single payer health care system. And until my wife comes back with the kids.

  • Reply 15 of 57
    Quote:
    Originally Posted by SolipsismX View Post

    Windows users are not vulnerable for once.

     

    Not if they're running Cygwin or MinGW =P
  • Reply 16 of 57
    Quote:
    Originally Posted by muppetry View Post

     

     

    It is primarily services (daemons) such as DHCP that call bash internally that are likely to be vulnerable. DHCP input should be sanitized, but then so should any daemon input string. Historically that has not always been the default. However, that's also the reason that most user OSX installations should be safe - they are not running external service daemons. Servers, such as websites, mail relays, DHCP, and other open ports etc., would presumably be the immediate concern.


     

    A service using bash would be pretty inefficient except maybe to start them. Usually they're not given more access to the box their in than they actuallly need. Scheduled jobs are more likely to use shell interpreters of some sort; of course a console running it as its shell is quite frequent on Unix systems. Oh, forgot to add, the shell and should be running with no more access than it needs, which again limits exposure considerably.

     

    I always find blanket statement about vulnerability quite annoying really.

     

    So, yes, unless Apple really badly designed security. It is only a problem to advanced users and even then, the vulnerabilty is limited.

  • Reply 17 of 57
    MarvinMarvin Posts: 15,309moderator
    rcfa wrote: »
    Badly explained article: for someone to exploit bash, they would have to be able to log in first.
    If a web server allows accessing bash, then the web server must also have an exploit.

    Not quite, there's a proof of concept here:

    http://security.stackexchange.com/questions/68122/what-is-a-specific-example-of-how-the-shellshock-bash-bug-could-be-exploited

    The wget command, which can download web pages is used to show switching a user-agent string with an exploit command on a CGI script. When the CGI script is accessed (assuming it has shell privileges), it executes the user-agent string (the exploit code). A single page being accessed can wipe out an entire server, which is why this exploit is rated 10/10 in severity, Heartbleed was 5/10. I think this exploit can even be done from a browser because Safari lets you set a custom user-agent so pointing it at a CGI script location should be able to compromise a server.

    Most user-facing websites don't use CGI scripts but the admin panels like CPanel do so one of those pages can potentially be exploited. Someone here tested out getting servers to ping him back and found thousands of vulnerable servers and one server compromised can be used to exploit more exponentially:

    http://blog.erratasec.com/2014/09/bash-shellshock-bug-is-wormable.html

    You can test if a bash shell is vulnerable by pasting the following into a terminal either via ssh or locally and hit return:
    x='() { :;}; echo VULNERABLE' bash -c "echo hello"
    

    The word 'vulnerable' shouldn't appear but 'hello' should. If both appear then the shell is vulnerable to the exploit. Unix servers should be updated immediately and the following command can be run (not on Macs) to do this via SSH or use WHM > Software > Update System Software:

    yum -y update bash

    It would be nice if Apple's updates could be done that way but it can make lots of programs out of sync in versions so harder to test against. I think it would be wise to make an exception in this case and not issue a whole point system update for it but a small installer. It's only around 1MB in size.

    I hope routers aren't vulnerable to this but most of them should have things like telnet disabled.

    OS X desktop and iOS users don't have to worry about this. Some jailbroken iOS devices manually enable shell access but I doubt even that's exploitable. iOS isn't in the list of vulnerable systems:

    https://www.us-cert.gov/ncas/alerts/TA14-268A

    In both cases for client use, some channel has to be open to allow someone to run the exploit on. I don't know if Facetime, iMessage or other services hook into a shell but even if they did, they'd need a custom exploit.

    Everyone running OS X Server or OS X Client as a publicly-facing server needs an immediate update (whenever Apple provides one), everyone else should be ok.

    edit: there's a proof of concept exploit for DHCP servers here:

    https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/

    They inject the exploit into the DHCP server offering up dynamic IPs when a client asks for a connection. The exploit is then executed on the client device. So a public wifi hotspot could exploit a vulnerable computer system just by it connecting to the wifi. This has been around for 20 years apparently so there's no telling how much it has been used.
  • Reply 18 of 57

    Unless your Mac is web facing and offering services you don't have much risk. There are ways to patch your Mac using Brew but it is not worth it unless you are a security professional or IT admin. Regular desktop users have nothing to worry about between now and when Apple releases the update.

     

    The biggest concern for regular users is visiting a compromised website that may try to install some other malware on your machine which updating your version of Bash has nothing to do with.

  • Reply 19 of 57
    cpsrocpsro Posts: 3,192member

    Why hasn't Apple pushed a patch already? It takes more effort to construct a press release than to patch. And it's not like pushing an album out to everyone that relatively few people want.

  • Reply 20 of 57
    ddawson100 wrote: »
    Yeah. And keep firing him until the phones don't bend any more! And the US gets a single payer health care system. And until my wife comes back with the kids.
    lol.
Sign In or Register to comment.