[ANNOUNCEMENT] Updated: bash-4.1.14-7

[ANNOUNCEMENT] Updated: bash-4.1.14-7

[Eric Blake (cygwin)]

[-- Attachment #1: Type: text/plain, Size: 7464 bytes --]

A new release of bash, 4.1.14-7, has been uploaded and will soon reach a
mirror near you; leaving the previous version at 4.1.13-6.

NEWS:
=====
This is a minor rebuild which picks up an upstream patch to fix
CVE-2014-7169 and all other ShellShock attacks (4.1.13-6 was also safe,
but used a slightly different downstream patch that used '()' instead of
'%%' in environment variables, and which was overly restrictive on
importing functions whose name was not an identifier).  There are still
known parser crashers (such as CVE-2014-7186, CVE-2014-7187, and
CVE-2014-6277) where upstream will probably issue patches soon; but
while those issues can trigger a local crash, they cannot be exploited
for escalation of privilege via arbitrary variable contents by this
build.  Left unpatched, a vulnerable version of bash could allow
arbitrary code execution via specially crafted environment variables,
and was exploitable through a number of remote services, so it is highly
recommended that you upgrade
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/
https://access.redhat.com/articles/1200223
https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00238.html

I also hope to have a build of bash 4.3 available soon, but wanted to
get the CVE fixed as soon as possible due to its severity.

There are a few things you should be aware of before using this version:
1. When using binary mounts, cygwin programs try to emulate Linux.  Bash
on Linux does not understand \r\n line endings, but interprets the \r
literally, which leads to syntax errors or odd variable assignments.
Therefore, you will get the same behavior on Cygwin binary mounts by
default.
2. d2u is your friend.  You can use it to convert any problematic script
into binary line endings.
3. Cygwin text mounts automatically work with either line ending style,
because the \r is stripped before bash reads the file.  If you
absolutely must use files with \r\n line endings, consider mounting the
directory where those files live as a text mount.  However, text mounts
are not as well tested or supported on the cygwin mailing list, so you
may encounter other problems with other cygwin tools in those directories.
4. This version of bash has a cygwin-specific set option, named "igncr",
to force bash to ignore \r, independently of cygwin's mount style.  As
of bash-3.2.3-5, it controls regular scripts, command substitution, and
sourced files.  I hope to convince the upstream bash maintainer to
accept this patch into a future bash release even on Linux, rather than
keeping it a cygwin-specific patch, but only time will tell.  There are
several ways to activate this option:
4a. For a single affected script, add this line just after the she-bang:
 (set -o igncr) 2>/dev/null && set -o igncr; # comment is needed
4b. For a single script, invoke bash explicitly with the option, as in
'bash -o igncr ./myscript' rather than the simpler './myscript'.
4c. To affect all scripts, export the environment variable BASH_ENV,
pointing to a file that sets the shell option as desired.  Bash will
source this file on startup for every script.
4d. Added in the bash-3.2-2 release: export the environment variable
SHELLOPTS with igncr included in it.  It is read-only from within bash,
but you can set it before invoking bash; once in bash, it auto-tracks
the current state of 'set -o igncr'.  If exported, then all bash child
processes inherit the same option settings; with the exception added in
3.2.9-11 that certain interactive options are not inherited in
non-interactive use.
4e. bash-4.1.9-1 dropped support for 'shopt -s igncr'; it did not make
sense to support the option through both set and shopt, and SHELLOPTS
proved to be more powerful.
5. You can also experiment with the IFS variable for controlling how
bash will treat \r during variable expansion.
6. There are varying levels of speed at which bash operates.  The
fastest is on a binary mount with igncr disabled (the default behavior).
 Next would be text mounts with igncr disabled and no \r in the
underlying file. Next would be binary mounts with igncr enabled.  And
the slowest that bash will operate is on text mounts with igncr enabled.
7. As additional cygwin extensions, this version of bash includes:
7a. EXECIGNORE - a colon-separated list of glob patterns to ignore
when completing on executables.  EXECIGNORE=*.dll is common.
7b. completion_strip_exe - using 'shopt -s completion_strip_exe'
makes completion strip .exe suffixes
8. This version of bash is immune to ShellShock (CVE-2014-6271 and
friends) because it exports functions via 'BASH_FUNC_foo%%=' rather than
'foo=' environment variables.  However, doing this has exposed
weaknesses in some other utilities like 'ksh' or 'at' that fail to scrub
their environment to exclude what is not a valid name for them.
9. If you don't like how bash behaves, then propose a patch, rather than
proposing idle ideas.  This turn of events has already been talked to
death on the mailing lists by people with many ideas, but few patches.
Thanks to Dan Colascione for providing the EXECIGNORE and
completion_strip_exe patches.

Remember, you must not have any bash or /bin/sh instances running when
you upgrade the bash package.  This release requires cygwin-1.7.32-1 or
later; and it requires libreadline7-6.1.2-2 or later.  See also the
upstream documentation in /usr/share/doc/bash/.

DESCRIPTION:
============
Bash is an sh-compatible shell that incorporates useful features from
the Korn shell (ksh) and C shell (csh).  It is intended to conform to
the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard.  It offers
functional improvements over sh for both programming and interactive
use. In addition, most sh scripts can be run by Bash without modification.

As of the bash 3.0 series, cygwin /bin/sh defaults to bash, not ash,
similar to some Linux distributions (although /bin/sh may swap to dash
at some future time).

UPDATE:
=======
To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system. Save it and run setup, answer the questions and pick up 'bash'
in the 'Base' category (it should already be selected).

DOWNLOAD:
=========
Note that downloads from cygwin.com aren't allowed due to bandwidth
limitations.  This means that you will need to find a mirror which has
this update, please choose the one nearest to you:
http://cygwin.com/mirrors.html

QUESTIONS:
==========
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

-- 
Eric Blake
volunteer cygwin bash package maintainer

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=================================
To unsubscribe to the cygwin-announce mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message.  Send
email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-YOU=YOURDOMAIN.COM@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

Re: [ANNOUNCEMENT] Updated: bash-4.1.14-7

[Alive]

On 30/09/2014 4:22, Eric Blake (cygwin) wrote:
> A new release of bash, 4.1.14-7, has been uploaded and will soon reach a
> mirror near you; leaving the previous version at 4.1.13-6.

I've checked for updates several time, but I don't find bash version
4.1.14-7. I get version 4.1.13-7 instead.

I just want to clarify, which version is right? The version downloaded
from mirrors or this version from announcement?

Thanks.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: [ANNOUNCEMENT] Updated: bash-4.1.14-7

[Buchbinder, Barry (NIH/NIAID) [E]]

Alive sent the following at Tuesday, September 30, 2014 1:49 PM
>On 30/09/2014 4:22, Eric Blake (cygwin) wrote:
>> A new release of bash, 4.1.14-7, has been uploaded and will soon reach a
>> mirror near you; leaving the previous version at 4.1.13-6.
>
>I've checked for updates several time, but I don't find bash version
>4.1.14-7. I get version 4.1.13-7 instead.
>
>I just want to clarify, which version is right? The version downloaded
>from mirrors or this version from announcement?

4.1.14-7

On my machine:

$ cygcheck -c bash
Cygwin Package Information
Package              Version        Status
bash                 4.1.14-7       OK

See also
https://cygwin.com/packages/x86/bash/
https://cygwin.com/packages/x86_64/bash/

Wait.  Give it time and 4.1.14-7 will show up on your preferred mirror.
Or try a different mirror.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

Re: [ANNOUNCEMENT] Updated: bash-4.1.14-7

[Andy]

Eric Blake (cygwin <ebb9 <at> byu.net> writes:
> This is a minor rebuild which picks up an upstream patch to fix
> CVE-2014-7169 and all other ShellShock attacks (4.1.13-6 was also safe,
> but used a slightly different downstream patch that used '()' instead of
> '%%' in environment variables, and which was overly restrictive on
> importing functions whose name was not an identifier).  There are still
> known parser crashers (such as CVE-2014-7186, CVE-2014-7187, and
> CVE-2014-6277) where upstream will probably issue patches soon; but
> while those issues can trigger a local crash, they cannot be exploited
> for escalation of privilege via arbitrary variable contents by this
> build.  Left unpatched, a vulnerable version of bash could allow
> arbitrary code execution via specially crafted environment variables,
> and was exploitable through a number of remote services, so it is highly
> recommended that you upgrade

I found this to be a good test site, with a comprehensive list of
exploits and explicit description of what to expect in order to decide
whether an exploit is still active: http://shellshocker.net


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: bash-4.1.14-7

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 2731 bytes --]

On 09/30/2014 07:42 PM, Andy wrote:
> Eric Blake (cygwin <ebb9 <at> byu.net> writes:
>> This is a minor rebuild which picks up an upstream patch to fix
>> CVE-2014-7169 and all other ShellShock attacks (4.1.13-6 was also safe,
>> but used a slightly different downstream patch that used '()' instead of
>> '%%' in environment variables, and which was overly restrictive on
>> importing functions whose name was not an identifier).  There are still
>> known parser crashers (such as CVE-2014-7186, CVE-2014-7187, and
>> CVE-2014-6277) where upstream will probably issue patches soon; but
>> while those issues can trigger a local crash, they cannot be exploited
>> for escalation of privilege via arbitrary variable contents by this
>> build.  Left unpatched, a vulnerable version of bash could allow
>> arbitrary code execution via specially crafted environment variables,
>> and was exploitable through a number of remote services, so it is highly
>> recommended that you upgrade
> 
> I found this to be a good test site, with a comprehensive list of
> exploits and explicit description of what to expect in order to decide
> whether an exploit is still active: http://shellshocker.net

That site is not 100% accurate.

Among others, it claims that:

env X=' () { }; echo hello' bash -c 'date'

can output hello on vulnerable bash.  That is untrue; no version of bash
exists with that behavior (the shellshock behavior REQUIRES the first
four bytes of a vulnerable variable to be "() {", but that example
started with space).

Furthermore, it claims that:

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF
<<EOF <<EOF <<EOF <<EOF <<EOF' ||
echo "CVE-2014-7186 vulnerable, redir_stack"

proves that bash is vulnerable to shellshock.  This is a half-truth.  It
proves that bash's parser is buggy (and cygwin's bash-4.1.14-7 STILL has
that bug, because the bug is still present upstream), but you are ONLY
vulnerable to ShellShock if the parser can be called by arbitrary
variable contents.  That is, to prove you are vulnerable, you have to
test something like:

env x='() { true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF
<<EOF <<EOF <<EOF <<EOF <<EOF' bash -c :

and if THAT dumps core, then you are vulnerable to shellshock. If you
apply all the latest upstream bash patches, it is impossible for that
sequence to dump core, because arbitrary variable assignments no longer
trigger calls into the (still-buggy) parser.

So please don't spread FUD.  Cygwin bash is no longer vulnerable to
shellshock, even if it still has parser bugs.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]