Q: CVE-2014-6271 bash vulnerability

OK. Some details, AFAIK:

• The OS X dhcp client is an Apple-written package, and is reportedly not vulnerable to rogue dhcp servers.  There's a proof-of-concept rogue dhcp server available, so you can verify vulnerable clients locally.
• bash-based Apache CGI scripts are vulnerable.  Very few folks have those bash scripts around.  Check your local system.
• local privilege escalations are possible, so folks with command line login access can get root.  On most Macs, it's usually only admins and support folks and occasionally the end-user that are accessing the command line anyway, and those folks already have root.

Current list of "Shellshock" bash-related CVEs:

• CVE-2014-6271
• CVE-2014-7169
• CVE-2014-7186
• CVE-2014-7187

There are issues for folks with local bash access.  But then folks with local access can toss a fork bomb at your computer, or fill your disks, or otherwise cause you problems.   As for remote access, you need to have Apache or another web server running or some other way to get at some local bash scripts (captive bash logins or software using scripts and AJAX), and you need to have some bash scripts around to exploit, so... I've checked for scripts, set up some filters, and am going to wait for Apple to issue a patch.

As for the more general mess, it's not OS X.  It's likely embedded devices running vulnerable versions of bash.  These can include NAS devices, network load balancers, and other such gizmos.  OS X client is not likely vulnerable without locally having opened up remote (web, command line, etc) access, and OS X Server vulnerabilities are presently apparently quite limited, but there are reportedly shellshock-based bugs in (for instance) the F5 BIG-IP load balancer web administration.

If you have a decent firewall in front of your network and if haven't opened ports (save via VPN) through that firewall, then nobody can even get at your Macs.

Mr Hoffman

What are CVE-2014-7186/7?

I get an error message: HOME >  CVE > ERROR: COULDN'T FIND 'CVE-2014-7186'

Does this mean, that there are further vulnerabilities which haven't been published yet?

Thanks

LL

Long Lane wrote:

 

Mr Hoffman

 

What are CVE-2014-7186/7?

 

I get an error message: HOME >  CVE > ERROR: COULDN'T FIND 'CVE-2014-7186'

 

Does this mean, that there are further vulnerabilities which haven't been published yet?

There are a total of four bash bugs outstanding, and potentially more will be found.

Click on the CVE links for what's been published in the CVE database.

There are presently discussions around changing how bash processes its imports (adding a "import-functions" flag), and around adding prefixing to environment variables akin to what Apache does — both of which would greatly reduce the exposure to this general class of bash parser bug.   Discussions in these areas are very active, as should be obvious and more details should settle out over the next few days as folks are able to research.

What  has in mind here for patches or when, I don't know.

My OSX Lion system has /bin/zsh installed by Apple. This isn't vulnerable to the shell shock quirks.

Its conceptionally simple enough to preserve a version of /bin/bash as /bin/bashOld and make /bin/bash a symbolic link to zsh.

I've done this, but I went through several roundabout steps making one admin user with /bin/zsh as the shell and another with /bin/bashOld as the shell.

I've also got a version of bash installed thru Macports as /opt/local/bin/bash. Its not vulnerable either.

First of all, most Mac users are not at risk. If you aren't running a server, there is nothing to worry about.

Second, wait for official patches. Don't try to hack the system yourself. The procedure you describe will not work. Zsh is not bash. Any bash scripts that you want to run will not work correctly. However, if you were running a web server, any hacks that attempted to exploit this bug would still work just fine. Why is that? If you don't know, then you shouldn't attempt to fix it.

I'm aware that zsh is not bash, but if there are scripts that really need the specific version of bash that came with the system I'll change the shebang line to reference bashOld

After a restart, all the daemons came up OK. I carefully left functional admin users around that will work even if I mess up the symlink.

Because I'm a Macports user, my terminal scripts don't see /bin/bash -> /bin/zsh anyway; I actually use /opt/local/bin/bash .

If there is any service that dies on start up I'll find out about it.

I really don't want to take my laptop to the outside world exposed to rogue servers.

(Way outside the discussion: turn on the firewall, enable stealth mode and turn off most services. My Console window shows port sniffers hammering on my machine.)

There may be other scripts, perhaps running under different users, that may call bash directly. Scripting languages like Perl will involve a shell depending on how you construct a system() call. I wouldn't recommend that anyone have a Mac directly connected to the Internet. That simply isn't Apple's focus and you would be on your own doing that. If you want to run Apache for development purposes, as I so, then make sure to configure it so that no one can access your server other than localhost. I don't consider the OS X firewall adequate for the task because it allows access by default and ignores signed applications by default.

I have heard that Apple has now released bash patches going all the way back to Lion. Too bad for the 10.5 and 10.6 users.

OS X bash Update 1.0 – OS X Mavericks

I read this morning that the patch only patch 2 of 3 vulnerabilities.  Any info/knowledge/comment from anybody on that?

see:   http://www.cnet.com/news/apples-shellshock-patch-incomplete-say-experts/#ftag=YH F65cbda0

ChangeAgent wrote:

 

I read this morning that the patch only patch 2 of 3 vulnerabilities.

 

Actually, it's two of six, but Apple is also on record as saying:

The vast majority of OS X users are not at risk to recently reported bash vulnerabilities," an Apple spokesperson told iMore. "Bash, a UNIX command shell and language included in OS X, has a weakness that could allow unauthorized users to remotely gain control of vulnerable systems. With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services.

So currently there really is little reason for anybody not running a server service to be concerned whether they are patched or not.

Ah thanks, I did not know that.