Unix資安存漏洞蘋果更新軟體

蘋果昨天發布更新軟體，以保護麥金塔電腦免於受到電腦臭蟲「Bash」入侵。近來甫被發現的Bash臭蟲威脅連網裝置的資安。

蘋果推出OS X Lion、Mountain Lion與Mavericks電腦作業系統軟體更新，修補Unix資安破洞，避免駭客入侵，控制電腦。

總部位在加州的蘋果表示，即使這個資安破洞存在以Unix為基礎的Mac OS與Linux作業系統，但蘋果電腦絕大多數用戶免驚啦，因麥金塔電腦的軟體預設，使得用戶受到保護。

蘋果發言人上週在電郵中表示：「電腦臭蟲Bash近來四處為患，但（麥金塔）OS X的絕大多數用戶沒有風險。」

蘋果終於釋出OS X Bash更新修補Shellshock漏洞

在Bash 傳出Shellshock漏洞多日之後，蘋果終於釋出OS X Bash Update 1.0更新，以修補存在於OS X Bash功能中的Shellshock漏洞。

不過蘋果只修補了Lion （Mac OS X 10.7.5）、Mountain Lion （Mac OS X 10.8.5）及Mavericks （Mac OS X 10.9.5）三個作業系統版本，舊版Mac OS無法獲得更新版，使用者必須升級到這三個版本之後才能修補 Bash漏洞。此外，代號為Yosemite的最新版Mac OS的開發者及公眾測試版目前也尚未提供更新，但蘋果表示之後會再釋出。

蘋果一開始對媒體宣稱大部份Mac電腦預設為安全狀態，未曝露於Bash遠端攻擊的風險下，除非使用者有做過進階的Unix組態設定，蘋果當時也表示正在加緊著手軟體更新。

無論如何，相較於Linux業者在漏洞一公開就立即釋出修補程式的積極做為，蘋果的慢半拍也受到外界批評。Bash維護工程師Chet Ramey就在Twitter上指出，早在漏洞公佈前就已通知蘋果，還提供修補程式給他們。

對於蘋果為何慢半拍，Ars Technica報導推測認為，Mac OS X目前採用的是3.2.51版GNU Bash而不是最新版的4.3，可能是因為蘋果並不採用GPL v3版授權的GNU Bash，因為GPL v3條件較為嚴格。因此即使大部份開放源碼作業系統已有Shellshock的修補程式釋出，但蘋果高層認為仍然應該自行開發Bash更新。

Bash specially-crafted environment variables code injection attack

Bash or the Bourne again shell, is a UNIX like shell, which is perhaps one of the most installed utilities on any Linux system. From its creation in 1980, bash has evolved from a simple terminal based command interpreter to many other fancy uses.

In Linux, environment variables provide a way to influence the behavior of software on the system. They typically consists of a name which has a value assigned to it. The same is true of the bash shell. It is common for a lot of programs to run bash shell in the background. It is often used to provide a shell to a remote user (via ssh, telnet, for example), provide a parser for CGI scripts (Apache, etc) or even provide limited command execution support (git, etc)

Coming back to the topic, the vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents. As a result, this vulnerability is exposed in many contexts, for example:

ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.
Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string).
PHP scripts executed with mod_php are not affected even if they spawn subshells.
DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.
Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.
Any other application which is hooked onto a shell or runs a shell script as using bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.

Like “real” programming languages, Bash has functions, though in a somewhat limited implementation, and it is possible to put these bash functions into environment variables. This flaw is triggered when extra code is added to the end of these function definitions (inside the enivronment variable). Something like:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
 vulnerable
 this is a test

The patch used to fix this flaw, ensures that no code is allowed after the end of a bash function. So if you run the above example with the patched version of bash, you should get an output similar to:

 $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
 bash: warning: x: ignoring function definition attempt
 bash: error importing function definition for `x'
 this is a test

We believe this should not affect any backward compatibility. This would, of course, affect any scripts which try to use environment variables created in the way as described above, but doing so should be considered a bad programming practice.

Red Hat has issued security advisories that fixes this issue for Red Hat Enterprise Linux. Fedora has also shipped packages that fixes this issue.

We have additional information regarding specific Red Hat products affected by this issue that can be found at https://access.redhat.com/site/solutions/1207723

Information on CentOS can be found at http://lists.centos.org/pipermail/centos/2014-September/146099.html.

我以為要複製貼上綠色的全部內容，結果只有「env x='() { :;}; echo vulnerable' bash -c "echo this is a test"」這個指令！