Does CVE-2014-6271 Bash Code Inject Vulnerability affect Shibboleth SP and/or IdP?

[Gernot Hassenpflug]

Hello,

Since 2014-09-24 there is a vulnerability CVE-2014-6271 reported [1]
regarding vulnerability in Bash shell, for Red Hat and CentOS (versions
4 through 7), explained in [3] by example.

Quote from [2]:
"This issue affects all software that uses the Bash shell and parses
values of environment variables. This issue is especially dangerous as
there are many possible ways Bash can be called by an application. Quite
often if an application executes another binary, Bash is invoked to
accomplish this. Because of the pervasive use of the Bash shell, this
issue is quite serious and should be treated as such."

Our company needs me to report on whether there is any vulnerability in
the Shibboleth-related software: Apache module and shibd daemon on the
SP side, in particular.

The shibd daemon communicates through the apache module to the browser,
using SAML, so I expect there to be no use of shell environment
variables here. However, perhaps the daemon calls a program from the
command line at some point, or some related use of environment
variables?

Could someone from the development team confirm whether or not there is
cause for concern or not?

Refs:

[1] http://lists.centos.org/pipermail/centos/2014-September/146099.html
[2] https://access.redhat.com/solutions/1207723
[3] https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

Best regards,

[Gernot Hassenpflug]

Gernot Hassenpflug

Post by Gernot Hassenpflug
Hello,
Since 2014-09-24 there is a vulnerability CVE-2014-6271 reported [1]
regarding vulnerability in Bash shell, for Red Hat and CentOS (versions
4 through 7), explained in [3] by example.

/../

Post by Gernot Hassenpflug
[1] http://lists.centos.org/pipermail/centos/2014-September/146099.html
[2] https://access.redhat.com/solutions/1207723
[3] https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

Followup:

I received a message from the Japanese Shibboleth Federation (Gakunin
Federation) in Japanese, in which it was stated that the bug does not
affect the Shibboleth software directly, but if one is running on an
affected host system, they recommend upgrading the copy of bash on that
system as soon as possible.

Regards,
Gernot Hassenpflug

I include the mail for reference below:

from: 国立情報学研究所　学認事務局　野田 <gakunin-***@nii.ac.jp>
reply-to: gakunin-***@nii.ac.jp
to: upki-***@nii.ac.jp, idp-***@nii.ac.jp, sp-***@nii.ac.jp
cc: gakunin-***@nii.ac.jp
date: 26 September 2014 15:32
subject: [upki-fed:00856] Bashの脆弱性について (CVE-2014-6271, CVE-2014-7169)

各位

　国立情報学研究所・学認事務局です。
平素より学認の事業にご協力を賜り，ありがとうございます。

　Bashに関する脆弱性 CVE-2014-6271, CVE-2014-7169 が公開されました。本脆
弱性では，Bashの環境変数の処理に起因する不具合により，リモートから任意
のコードを実行可能となります。

学認技術ガイドに従って構築したIdP/SP自身がBashを呼び出すことはありませ
んが，同居しているWebアプリケーションや他のCGIスクリプト等を配置してい
る場合に本脆弱性の影響を受ける可能性があります。

すでに修正パッケージがリリースされていますので速やかにアップデートいた
だくことをおすすめいたします。

CentOSでは以下に示すバージョンがCVE-2014-6271, CVE-2014-7169の両方が修
正されたパッケージです。

・CentOS 5
bash-3.2-33.el5_10.4 およびそれ以降のバージョン

・CentOS 6
bash-4.1.2-15.el6_5.2 およびそれ以降のバージョン

その他のディストリビューションをご利用の方は，各ディストリビュータの情
報をご参照ください。


参考情報：

・Bash Code Injection Vulnerability via Specially Crafted Environment
Variables (CVE-2014-6271, CVE-2014-7169)
https://access.redhat.com/articles/1200223

・CVE-2014-6271 bash: specially-crafted environment variables can be
used to inject shell commands
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6271

・CVE-2014-7169 bash: code execution via specially-crafted environment
(Incomplete fix for CVE-2014-6271)
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-7169

・CVE-2014-6271
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271

・CVE-2014-7169
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

--
=========================================================
　国立情報学研究所 学術基盤課 学認事務局　（担当：野田）
　TEL：[phone]　gakunin-***@nii.ac.jp
　学認Webページ https://www.gakunin.jp/
　申請システム https://office.gakunin.nii.ac.jp/
=========================================================

[Cantor, Scott]

On 9/25/14, 11:02 PM, "Gernot Hassenpflug"

Post by Gernot Hassenpflug
Our company needs me to report on whether there is any vulnerability in
the Shibboleth-related software: Apache module and shibd daemon on the
SP side, in particular.

I'm extremely curious as to why. I know that some bugs are things you have
to prioritize patching, but this one is a raging fire. You don't even
think about it, you just patch every web server you can get hold of, and
you're still too late.

Post by Gernot Hassenpflug
The shibd daemon communicates through the apache module to the browser,
using SAML, so I expect there to be no use of shell environment
variables here. However, perhaps the daemon calls a program from the
command line at some point, or some related use of environment
variables?

No.

-- Scott

[Gernot Hassenpflug]

Post by Cantor, Scott
On 9/25/14, 11:02 PM, "Gernot Hassenpflug"

Post by Gernot Hassenpflug
Our company needs me to report on whether there is any vulnerability in
the Shibboleth-related software: Apache module and shibd daemon on the
SP side, in particular.

I'm extremely curious as to why. I know that some bugs are things you have
to prioritize patching, but this one is a raging fire. You don't even
think about it, you just patch every web server you can get hold of, and
you're still too late.

Hello Scott,

Thanks for the reply. I realize the above is true, at a technical level,
but in terms of managing problems, tracking solutions, auditing past
logs, and communicating with customers, requires more detail, hence my
question.

Here are a couple of reasons, for reference.

(1) Organizational:

Customers using SSO must be told what possible levels of security risks
there are/were, including where (in which software, during which
actions, etc.), and audits done where necessary. To decide where company
resources must be allocated, it is important to get details first.

(2) Prioritizing, and application-level patching

OS level patches are critical, but application level patches can be done
more quickly, especially since OS-level patches are not final yet. (we
emergency-patched our in-house software to prevent use of shell).

(3) Reporting and knowledge-base

For dealing with customer queries, and in-house knowledge base, as for
any case where trouble affects or potentially affects customer services,
information must be collated and recorded for future reference.

Post by Cantor, Scott

Post by Gernot Hassenpflug
The shibd daemon communicates through the apache module to the browser,
using SAML, so I expect there to be no use of shell environment
variables here. However, perhaps the daemon calls a program from the
command line at some point, or some related use of environment
variables?

No.

Thank you.

Best regards,
Gernot Hassenpflug

[Cantor, Scott]

On 9/26/14, 11:46 PM, "Gernot Hassenpflug"

Post by Gernot Hassenpflug
Thanks for the reply. I realize the above is true, at a technical level,
but in terms of managing problems, tracking solutions, auditing past
logs, and communicating with customers, requires more detail, hence my
question.

I didn't realize you were kind of in the middle, as opposed to "just" a
deployer, hence my question.

Post by Gernot Hassenpflug
(2) Prioritizing, and application-level patching
OS level patches are critical, but application level patches can be done
more quickly, especially since OS-level patches are not final yet. (we
emergency-patched our in-house software to prevent use of shell).

My experience is the opposite, just because there's no way I can produce
patches on the timelines Red Hat or MS can (for one thing, they have
advance knowledge and I usually don't). So I view most of the applications
or middleware I use as much more precarious than the OS, which usually has
patches more ahead of the real threats.

-- Scott

[Gernot Hassenpflug]

Post by Cantor, Scott
On 9/26/14, 11:46 PM, "Gernot Hassenpflug"

Post by Gernot Hassenpflug
Thanks for the reply. I realize the above is true, at a technical level,
but in terms of managing problems, tracking solutions, auditing past
logs, and communicating with customers, requires more detail, hence my
question.

I didn't realize you were kind of in the middle, as opposed to "just" a
deployer, hence my question.

Hello Scott,

No worries, I added more details for the benefit of other people doing
searches, since all this communication should be of value. Seeing
different perspectives and assumptions here is a good thing for
reference.

Post by Cantor, Scott

Post by Gernot Hassenpflug
(2) Prioritizing, and application-level patching
OS level patches are critical, but application level patches can be done
more quickly, especially since OS-level patches are not final yet. (we
emergency-patched our in-house software to prevent use of shell).

My experience is the opposite, just because there's no way I can produce
patches on the timelines Red Hat or MS can (for one thing, they have
advance knowledge and I usually don't). So I view most of the applications
or middleware I use as much more precarious than the OS, which usually has
patches more ahead of the real threats.

Ah, I see. That is another issue I did not consider. I understand better
now how difficult it is now to make general assumptions without having
more communication with the other parties involved.

Just to conclude: we're rolled out OS-level patches last week and again
early this week to all our systems, including those using Shibboleth SP
(customer services) and IdP (in-house only).

Best regards,
Gernot Hassenpflug