Discussion:
Bash bug issue
(too old to reply)
Jonathan Adams
2014-09-25 08:42:11 UTC
Permalink
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/

does anyone know if this affects us?
Krzysztof Grzempa
2014-09-25 08:44:32 UTC
Permalink
I guess you can test it yourself:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Post by Jonathan Adams
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
does anyone know if this affects us?
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Predrag Zecevic [Unix Systems Administrator]
2014-09-25 08:45:42 UTC
Permalink
Hi,

I have already upgraded from /hipster-2014.1 which has fix in it:
http://github.com/OpenIndiana/oi-userland/commit/35d2023cdaeba3486586ffb59e4f8a1ecc7a2c24

So, it affects all I guess, until bash is updated.

Regards.
Post by Jonathan Adams
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
does anyone know if this affects us?
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
--
Predrag Zečević, Technical Support Analyst, 2e Systems GmbH

Telephone: +49 6196 9505 815, Facsimile: +49 6196 9505 894
Mobile: +49 174 3109 288, Skype: predrag.zecevic
E-mail: ***@2e-systems.com

Headquarter: 2e Systems GmbH, Königsteiner Str. 87,
65812 Bad Soden am Taunus, Germany
Company registration: Amtsgericht Königstein (Germany), HRB 7303
Managing director: Phil Douglas

http://www.2e-systems.com/ - Making your business fly!

[***]===---
Your code should be more efficient!
Udo Grabowski (IMK)
2014-09-25 08:46:48 UTC
Permalink
Post by Jonathan Adams
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
The bug "works", so we are affected with everything that
is based on bash, as well as all users using bash in their
projects.
This is a bug with high impact and risks, so a fix should be
available for oi dev and hipster as fast as possible.
--
Dr.Udo Grabowski Inst.f.Meteorology & Climate Research IMK-ASF-SAT
http://www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology http://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026
Alexander Pyhalov
2014-09-25 08:50:07 UTC
Permalink
Post by Udo Grabowski (IMK)
Post by Jonathan Adams
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
The bug "works", so we are affected with everything that
is based on bash, as well as all users using bash in their
projects.
This is a bug with high impact and risks, so a fix should be
available for oi dev and hipster as fast as possible.
Hello.
I've seen fix for CVE-2014-6271, which I've already committed, but not
for CVE-2014-7169...
--
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department
Carl Brewer
2014-09-25 11:08:39 UTC
Permalink
Post by Alexander Pyhalov
Post by Udo Grabowski (IMK)
Post by Jonathan Adams
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
The bug "works", so we are affected with everything that
is based on bash, as well as all users using bash in their
projects.
This is a bug with high impact and risks, so a fix should be
available for oi dev and hipster as fast as possible.
Hello.
I've seen fix for CVE-2014-6271, which I've already committed, but not
for CVE-2014-7169...
I'm stuck on 151a8 at the moment, is there any chance a fixed bash
binary could be made available somewhere?
Alexander Pyhalov
2014-09-25 11:20:18 UTC
Permalink
Post by Carl Brewer
Post by Alexander Pyhalov
Post by Udo Grabowski (IMK)
Post by Jonathan Adams
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
The bug "works", so we are affected with everything that
is based on bash, as well as all users using bash in their
projects.
This is a bug with high impact and risks, so a fix should be
available for oi dev and hipster as fast as possible.
Hello.
I've seen fix for CVE-2014-6271, which I've already committed, but not
for CVE-2014-7169...
I'm stuck on 151a8 at the moment, is there any chance a fixed bash
binary could be made available somewhere?
Binary will likely not work, because it was compiled with later libc
version. But you can try compile it yourself (you can look at using
oi-userland on /dev - https://github.com/OpenIndiana/oi-userland, it can
work with some tweaks to configs).
--
С уважением,
Александр Пыхалов,
программист отдела телекоммуникационной инфраструктуры
управления информационно-коммуникационной инфраструктуры ЮФУ
Udo Grabowski (IMK)
2014-09-25 11:20:17 UTC
Permalink
Post by Carl Brewer
Post by Alexander Pyhalov
Post by Udo Grabowski (IMK)
Post by Jonathan Adams
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
The bug "works", so we are affected with everything that
is based on bash, as well as all users using bash in their
projects.
This is a bug with high impact and risks, so a fix should be
available for oi dev and hipster as fast as possible.
Hello.
I've seen fix for CVE-2014-6271, which I've already committed, but not
for CVE-2014-7169...
I'm stuck on 151a8 at the moment, is there any chance a fixed bash
binary could be made available somewhere?
Recent discussions seem to lead to a general security concern
with the crippled bash parser, so there nearly certainly will
be more and more security issues in the next days to come up.
I think the better alternative is to provide 'dash' and symlink
bash to dash instead, as dash much cleaner, faster, and POSIX -
compliant. Although, as it has not been widely used as bash
yet, could have its own bugs not yet discovered....
--
Dr.Udo Grabowski Inst.f.Meteorology & Climate Research IMK-ASF-SAT
http://www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology http://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026
Bob Friesenhahn
2014-09-25 13:48:01 UTC
Permalink
Post by Udo Grabowski (IMK)
Recent discussions seem to lead to a general security concern
with the crippled bash parser, so there nearly certainly will
be more and more security issues in the next days to come up.
I think the better alternative is to provide 'dash' and symlink
bash to dash instead, as dash much cleaner, faster, and POSIX -
compliant. Although, as it has not been widely used as bash
yet, could have its own bugs not yet discovered....
Unfortunately, 'dash' is not completely compatible with scripts
written for 'bash'. It is not clear to my why people write shell
scripts targeting bash, but it seems to happen often.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Predrag Zecevic [Unix Systems Administrator]
2014-09-25 13:51:14 UTC
Permalink
Post by Udo Grabowski (IMK)
Recent discussions seem to lead to a general security concern
with the crippled bash parser, so there nearly certainly will
be more and more security issues in the next days to come up.
I think the better alternative is to provide 'dash' and symlink
bash to dash instead, as dash much cleaner, faster, and POSIX -
compliant. Although, as it has not been widely used as bash
yet, could have its own bugs not yet discovered....
Unfortunately, 'dash' is not completely compatible with scripts written for 'bash'. It is not clear to my why people write shell
scripts targeting bash, but it seems to happen often.
Bob
Probably because they are coming from Linux background...

I had to leave ksh because of that ...

Regards.
--
Predrag Zečević, Technical Support Analyst, 2e Systems GmbH

Telephone: +49 6196 9505 815, Facsimile: +49 6196 9505 894
Mobile: +49 174 3109 288, Skype: predrag.zecevic
E-mail: ***@2e-systems.com

Headquarter: 2e Systems GmbH, Königsteiner Str. 87,
65812 Bad Soden am Taunus, Germany
Company registration: Amtsgericht Königstein (Germany), HRB 7303
Managing director: Phil Douglas

http://www.2e-systems.com/ - Making your business fly!

[***]===---
Never put off till run-time what you can do at compile-time. -- D. Gries
Tim Mooney
2014-09-25 17:04:00 UTC
Permalink
Unfortunately, 'dash' is not completely compatible with scripts written for
'bash'. It is not clear to my why people write shell scripts targeting bash,
but it seems to happen often.
Two reasons:

- It's the "all the world's a VAX" syndrome for the current generation.

- bash (and ksh) do provide some handy features that traditional Bourne
shell does not, and for a large portion of inexperienced programmers,
convenience/laziness trumps portability

Both things drive me crazy, but they've been going on for my entire
career in computing, so I have no reason to expect that either are going
to ever disappear.

Tim
--
Tim Mooney ***@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
Gary Gendel
2014-09-25 17:18:33 UTC
Permalink
I believe we mostly skirt the issue because, unlike Linux, the default
shell (/bin/sh) is ksh93 not bash. This means that under normal
conditions we shouldn't have an issue. Only if your cgi scripts
actually request bash will apache be a problem. As for ssh, it depends
upon the login shell for the user.
In regard to: Re: [OpenIndiana-discuss] Bash bug issue, Bob
Post by Bob Friesenhahn
Unfortunately, 'dash' is not completely compatible with scripts
written for 'bash'. It is not clear to my why people write shell
scripts targeting bash, but it seems to happen often.
- It's the "all the world's a VAX" syndrome for the current generation.
- bash (and ksh) do provide some handy features that traditional Bourne
shell does not, and for a large portion of inexperienced programmers,
convenience/laziness trumps portability
Both things drive me crazy, but they've been going on for my entire
career in computing, so I have no reason to expect that either are going
to ever disappear.
Tim
Jonathan Adams
2014-09-25 18:27:50 UTC
Permalink
I know I created the original post that sparked this debate, but I have to
say that we've been checking our servers all day, and we cannot get any of
them to act compromised ... we don't use bash scripts in our cgi-bin and
nothing seems to try to run bash at all (fuser `which bash` only returns my
shells)

The ssh things could be an issue, but we're nuking all ssh authorized_keys
wherever we find them, and we don't have accounts restricted to running
specific applications via ssh, so the users who can ssh in should know what
they're doing, or not know so much that they aren't a threat.

I do have bash scripts on our system that users run manually, but that is
because the old Solaris 10 /bin/sh is brain-dead, csh is a nasty piece of
work for scripting and ksh scripts don't seem as portable to Linux/old
Solaris boxes.

Jon
Post by Gary Gendel
I believe we mostly skirt the issue because, unlike Linux, the default
shell (/bin/sh) is ksh93 not bash. This means that under normal conditions
we shouldn't have an issue. Only if your cgi scripts actually request bash
will apache be a problem. As for ssh, it depends upon the login shell for
the user.
In regard to: Re: [OpenIndiana-discuss] Bash bug issue, Bob
Unfortunately, 'dash' is not completely compatible with scripts written
for 'bash'. It is not clear to my why people write shell scripts targeting
bash, but it seems to happen often.
- It's the "all the world's a VAX" syndrome for the current generation.
- bash (and ksh) do provide some handy features that traditional Bourne
shell does not, and for a large portion of inexperienced programmers,
convenience/laziness trumps portability
Both things drive me crazy, but they've been going on for my entire
career in computing, so I have no reason to expect that either are going
to ever disappear.
Tim
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Harry Putnam
2014-09-26 21:02:08 UTC
Permalink
Post by Gary Gendel
I believe we mostly skirt the issue because, unlike Linux, the default
shell (/bin/sh) is ksh93 not bash. This means that under normal
conditions we shouldn't have an issue. Only if your cgi scripts
actually request bash will apache be a problem. As for ssh, it
depends upon the login shell for the user.
So, do you mean that ksh93 does not have the vulnerability?
Nemo
2014-09-26 23:41:44 UTC
Permalink
Post by Harry Putnam
Post by Gary Gendel
I believe we mostly skirt the issue because, unlike Linux, the default
shell (/bin/sh) is ksh93 not bash. This means that under normal
conditions we shouldn't have an issue. Only if your cgi scripts
actually request bash will apache be a problem. As for ssh, it
depends upon the login shell for the user.
So, do you mean that ksh93 does not have the vulnerability?
Whence does the OI bash source originate? On the bash that comes with
Solaris 10,
the vulnerability is not present:

[~]=> bash --version
GNU bash, version 3.00.16(1)-release (sparc-sun-solaris2.10)
Copyright (C) 2004 Free Software Foundation, Inc.
[~]=> env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
completed


N.
Saso Kiselkov
2014-09-26 23:44:31 UTC
Permalink
Post by Nemo
Post by Harry Putnam
Post by Gary Gendel
I believe we mostly skirt the issue because, unlike Linux, the default
shell (/bin/sh) is ksh93 not bash. This means that under normal
conditions we shouldn't have an issue. Only if your cgi scripts
actually request bash will apache be a problem. As for ssh, it
depends upon the login shell for the user.
So, do you mean that ksh93 does not have the vulnerability?
Whence does the OI bash source originate? On the bash that comes with
Solaris 10,
[~]=> bash --version
GNU bash, version 3.00.16(1)-release (sparc-sun-solaris2.10)
Copyright (C) 2004 Free Software Foundation, Inc.
[~]=> env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
completed
In general, bash != /bin/sh on either Solaris or Illumos-derived
systems. Rerun the env test with bash instead of /bin/sh.
--
Saso
Nemo
2014-09-26 23:59:41 UTC
Permalink
[...]
Post by Saso Kiselkov
Post by Nemo
Whence does the OI bash source originate? On the bash that comes with
[~]=> bash --version
GNU bash, version 3.00.16(1)-release (sparc-sun-solaris2.10)
Copyright (C) 2004 Free Software Foundation, Inc.
[~]=> env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
completed
In general, bash != /bin/sh on either Solaris or Illumos-derived
systems. Rerun the env test with bash instead of /bin/sh.
[~]=> echo $SHELL
/bin/bash
[~]=> env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
completed

Note that I put bash into /bin to avoid GNUisms.

N.
Bill Sommerfeld
2014-09-27 00:00:49 UTC
Permalink
Post by Nemo
[~]=> echo $SHELL
/bin/bash
[~]=> env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
completed
Note that I put bash into /bin to avoid GNUisms.
Try:

$ env X="() { :;} ; echo busted" /bin/bash -c "echo completed"
Saso Kiselkov
2014-09-27 00:04:58 UTC
Permalink
Post by Nemo
[...]
Post by Saso Kiselkov
Post by Nemo
Whence does the OI bash source originate? On the bash that comes with
[~]=> bash --version
GNU bash, version 3.00.16(1)-release (sparc-sun-solaris2.10)
Copyright (C) 2004 Free Software Foundation, Inc.
[~]=> env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
completed
In general, bash != /bin/sh on either Solaris or Illumos-derived
systems. Rerun the env test with bash instead of /bin/sh.
[~]=> echo $SHELL
/bin/bash
[~]=> env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
completed
Note that I put bash into /bin to avoid GNUisms.
The invoking shell is irrelevant. Here's your problem:

vvvvvvv
env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
^^^^^^^

Put bash in there and you'll get a vulnerable "busted" result.
--
Saso
Nemo
2014-09-27 14:41:56 UTC
Permalink
Post by Saso Kiselkov
vvvvvvv
env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
^^^^^^^
Put bash in there and you'll get a vulnerable "busted" result.
Of course, thank you, I never noticed that I was runing /bin/sh, not /bin/bash.

Moral of the story: Neverl operate heavy machinery or shell scripts when tired.

N.
Gary Gendel
2014-09-26 23:47:06 UTC
Permalink
The current maintainer says it's been in bash for ~20 years, why it's
not in Solaris 10 is a mystery.
Post by Nemo
Post by Harry Putnam
Post by Gary Gendel
I believe we mostly skirt the issue because, unlike Linux, the default
shell (/bin/sh) is ksh93 not bash. This means that under normal
conditions we shouldn't have an issue. Only if your cgi scripts
actually request bash will apache be a problem. As for ssh, it
depends upon the login shell for the user.
So, do you mean that ksh93 does not have the vulnerability?
Whence does the OI bash source originate? On the bash that comes with
Solaris 10,
[~]=> bash --version
GNU bash, version 3.00.16(1)-release (sparc-sun-solaris2.10)
Copyright (C) 2004 Free Software Foundation, Inc.
[~]=> env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
completed
N.
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Nemo
2014-09-27 00:00:52 UTC
Permalink
The current maintainer says it's been in bash for ~20 years, why it's not in
Solaris 10 is a mystery.
If you which files, I can dig out the source from the companion disc
and compare.

N.
Brandon Hume
2014-10-02 14:00:27 UTC
Permalink
Post by Gary Gendel
The current maintainer says it's been in bash for ~20 years, why it's
not in Solaris 10 is a mystery.
It is in Solaris 10. (And 11.) The test being used is flawed:

env X="() { :;} ; echo busted" /bin/sh -c "echo completed"

This just tests whether or not /bin/sh is vulnerable, and on Solaris
/bin/sh != /bin/bash (unless your admin is insane and dropped it in
place, which can't really be ruled out). On many (most? all?) Linuxes,
/bin/sh *is* /bin/bash.

So Solaris and derivatives have the bug, but the attack surface isn't
anywhere near as massive as on a Linux distribution. But if someone has
written scripts explicitly using /bin/bash, or if you have sudo
configurations that don't clean out the environment, you can get bitten.
Bob Friesenhahn
2014-10-02 14:20:09 UTC
Permalink
Post by Nemo
The current maintainer says it's been in bash for ~20 years, why it's not
in Solaris 10 is a mystery.
env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
The good news is that if you have a support contract, there is a
Solaris 10 bash patch which seems to solve all the reported attack
vectors (in my own testing). It took Oracle two patches to get things
right.

The obvious replacement for Solaris 10 has been OpenIndiana but
unfortunately, OpenIndiana has not been issuing any fixes for even the
most high-profile security issues (like this one).

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Alan Coopersmith
2014-10-02 15:10:00 UTC
Permalink
Post by Nemo
The current maintainer says it's been in bash for ~20 years, why it's not in
Solaris 10 is a mystery.
env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
The good news is that if you have a support contract, there is a Solaris 10 bash
patch which seems to solve all the reported attack vectors (in my own testing).
It took Oracle two patches to get things right.
People found more bugs after the first patch went out. There are 6 CVE's for
bash announced in the last week after all.
--
-Alan Coopersmith- ***@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
outsider
2014-10-02 20:37:27 UTC
Permalink
It is very strange with the oracle updates for Solaris 10 & 11

Is far as I can see, Solaris 10 and Solaris 11 get different bash versions
after the patch.
I don't know what is allowed to say about it in public, but both test
negative on the (simple) shockshell tests I found.
(so they seem secured)







-----Oorspronkelijk bericht-----
Van: Alan Coopersmith [mailto:***@oracle.com]
Verzonden: donderdag 2 oktober 2014 17:10
Aan: Discussion list for OpenIndiana
Onderwerp: Re: [OpenIndiana-discuss] Bash bug issue
Post by Bob Friesenhahn
Post by Nemo
Post by Gary Gendel
The current maintainer says it's been in bash for ~20 years, why
it's not in Solaris 10 is a mystery.
env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
The good news is that if you have a support contract, there is a
Solaris 10 bash patch which seems to solve all the reported attack vectors
(in my own testing).
Post by Bob Friesenhahn
It took Oracle two patches to get things right.
People found more bugs after the first patch went out. There are 6 CVE's
for
bash announced in the last week after all.
--
-Alan Coopersmith- ***@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
Alan Coopersmith
2014-10-02 20:41:44 UTC
Permalink
Post by outsider
It is very strange with the oracle updates for Solaris 10 & 11
Is far as I can see, Solaris 10 and Solaris 11 get different bash versions
after the patch.
They had different bash versions before the patch too. Upstream released
fixes for bash versions from 2.0 to 4.3, so that distros/packagers weren't
forced to update to the latest just to get the fixes.

There is nothing strange here, just don't expect to have the same
software versions in two OS's released 7 years apart.
--
-Alan Coopersmith- ***@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
Roelof van der Wal
2014-10-02 17:00:43 UTC
Permalink
The -07 version of the solaris 10 Oracle patch is from last monday. Seems
to me it fixes all. But had little time to test it.
Post by Gary Gendel
Post by Nemo
Post by Gary Gendel
The current maintainer says it's been in bash for ~20 years, why it's
not in
Post by Nemo
Post by Gary Gendel
Solaris 10 is a mystery.
env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
The good news is that if you have a support contract, there is a Solaris
10 bash
patch which seems to solve all the reported attack vectors (in my own
testing).
It took Oracle two patches to get things right.
People found more bugs after the first patch went out. There are 6 CVE's for
bash announced in the last week after all.
--
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Alan Coopersmith
2014-10-02 15:12:52 UTC
Permalink
On many (most? all?) Linuxes, /bin/sh *is* /bin/bash.
Many, but not all - the Debian family and some others use a lighter weight,
POSIX compatible shell instead, dash, the Debian Almquist Shell; and many
embedded distros use BusyBox instead.

https://en.wikipedia.org/wiki/Almquist_shell
http://lwn.net/Articles/343924/
--
-Alan Coopersmith- ***@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
cpforum
2014-10-04 15:05:29 UTC
Permalink
First : building openindiana a10 with updated commands (including a secure bash) urge :-)

Second : because ksh is ten time powerfull and reliable than bash leave bash and adopt ksh. If you want history put ' set -o emacs' inside your .profile
For exemple ksh can be compiled (shcomp), has object oriented programming features and many other features bash has'nt.

Third : while waiting for openindiana a10 compile bash. It takes 15 minutes.

Get bash and patch from ftp.gnu.org/gnu/bash


$ ls
bash-4.3 bash43-007.sig bash43-015.sig bash43-023.sig
bash-4.3.tar.gz bash43-008 bash43-016 bash43-024
bash-4.3.tar.gz.sig bash43-008.sig bash43-016.sig bash43-024.sig
bash43-001 bash43-009 bash43-017 bash43-025
bash43-001.sig bash43-009.sig bash43-017.sig bash43-025.sig
bash43-002 bash43-010 bash43-018 bash43-026
bash43-002.sig bash43-010.sig bash43-018.sig bash43-026.sig
bash43-003 bash43-011 bash43-019 bash43-027
bash43-003.sig bash43-011.sig bash43-019.sig bash43-027.sig
bash43-004 bash43-012 bash43-020 bash43-028
bash43-004.sig bash43-012.sig bash43-020.sig bash43-028.sig
bash43-005 bash43-013 bash43-021 bash43-029
bash43-005.sig bash43-013.sig bash43-021.sig bash43-029.sig
bash43-006 bash43-014 bash43-022
bash43-006.sig bash43-014.sig bash43-022.sig
bash43-007 bash43-015 bash43-023

Go under ksh Important for {1-29%03d}

$ ksh

$ cd bash-4.3

Apply all patch 001 to 029

$ for p in {1..29%03d} <<< ksh is powerfull than bash
do
gpatch -p0 < ../bash43-$p
done
$ ./configure
$ gmake


$ gmake install



/usr/local/bin/bash --version
GNU bash, version 4.3.29(1)-release (i386-pc-solaris2.11)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


/usr/local/bin/bash
Verify it's OK

Then

cd /usr/bin

mv bash bash-oi_151a9

ln -s /usr/local/bin/bash bash
Message du 02/10/14 17:13
De : "Alan Coopersmith"
A : "Discussion list for OpenIndiana"
Objet : Re: [OpenIndiana-discuss] Bash bug issue
On many (most? all?) Linuxes, /bin/sh *is* /bin/bash.
Many, but not all - the Debian family and some others use a lighter weight,
POSIX compatible shell instead, dash, the Debian Almquist Shell; and many
embedded distros use BusyBox instead.
https://en.wikipedia.org/wiki/Almquist_shell
http://lwn.net/Articles/343924/
--
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Bob Friesenhahn
2014-10-04 15:27:56 UTC
Permalink
Post by cpforum
First : building openindiana a10 with updated commands (including a secure bash) urge :-)
Second : because ksh is ten time powerfull and reliable than bash
leave bash and adopt ksh. If you want history put ' set -o emacs'
inside your .profile
ksh provided by OpenIndiana is also outdated and broken. :-(

Your instructions are useful.

It is always good to execute 'gmake check' before installing sofware
that comes with a test suite. Some bash tests seem to fail.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
cpforum
2014-10-04 16:43:55 UTC
Permalink
Message du 04/10/14 17:28
De : "Bob Friesenhahn"
A : "Discussion list for OpenIndiana"
Objet : Re: [OpenIndiana-discuss] Bash bug issue
ksh provided by OpenIndiana is also outdated and broken. :-(
Your instructions are useful.
It is always good to execute 'gmake check' before installing sofware
that comes with a test suite. Some bash tests seem to fail.
Bob
Ian Collins
2014-10-05 20:14:21 UTC
Permalink
Post by Bob Friesenhahn
It is always good to execute 'gmake check' before installing sofware
that comes with a test suite. Some bash tests seem to fail.
If you check the comments printed by the tests, it looks like the
"failures" seen on Solaris based OS are expected.

I've been using 4.1.15 build on Solaris 10 for most systems.
--
Ian.
Bob Friesenhahn
2014-10-05 20:40:17 UTC
Permalink
Post by Bob Friesenhahn
It is always good to execute 'gmake check' before installing sofware
that comes with a test suite. Some bash tests seem to fail.
If you check the comments printed by the tests, it looks like the "failures"
seen on Solaris based OS are expected.
Under OpenIndiana I saw some differences in output which may be due to
small issues with internationalized character sets ("locales").
OpenIndiana uses different internationalization code than "Solaris"
since it was written from scratch by the Illumos project.

The bash I built (4.3.29) seems to be working fine for my purposes but
I don't use bash as an interactive shell.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Nikola M.
2014-10-06 06:00:15 UTC
Permalink
Post by Bob Friesenhahn
Post by Ian Collins
Post by Bob Friesenhahn
It is always good to execute 'gmake check' before installing sofware
that comes with a test suite. Some bash tests seem to fail.
If you check the comments printed by the tests, it looks like the
"failures" seen on Solaris based OS are expected.
Under OpenIndiana I saw some differences in output which may be due to
small issues with internationalized character sets ("locales").
OpenIndiana uses different internationalization code than "Solaris"
since it was written from scratch by the Illumos project.
Yeah as I understand it was closed source/proprietary part in Opensolaris.
Post by Bob Friesenhahn
The bash I built (4.3.29) seems to be working fine for my purposes but
I don't use bash as an interactive shell.
You can post a bug on OI for that internationalization issue, it is
always useful to have something like that described in detail in bug report.
Bruce Lilly
2014-11-03 21:39:10 UTC
Permalink
Post by cpforum
cd /usr/bin
mv bash bash-oi_151a9
ln -s /usr/local/bin/bash bash
While that would be reasonable under many operating systems, it *may*
present problems on Solaris-derived systems, especially 64-bit systems.
See http://docs.oracle.com/cd/E18752_01/html/816-5138/index.html (a bit
dated w.r.t. compiler flags, but the principles are still valid, as is most
of the content).
Note in particular that /usr/bin/bash *might* very well be a hard link to
/usr/lib/isaexec and that the real executables *might* live under
/usr/bin/i86pc and /usr/bin/amd64 (on i86 hardware of course).

It would be prudent to check first before moving and/or linking files in
/bin, /usr/bin, /usr/sbin, /usr/lib, ...

Actual conditions depend on whether or not the packager paid any attention
to 32-bit vs. 64-bit issues, and isn't bash-specific.

As of this late date, /usr/bin/bash here is in fact the bash executable,
not a link; but that means that it's 32-bit only and might well present
unexpected issues on 64-bit systems when dealing with large files etc.
(basically anything that involves pointers, long integers, time_t,
ptrdiff_t, clock_t, dev_t, off_t, size_t, or ssize_t in the sources).

If you are building from source on a 64-bit system, I strongly recommend
reading that document.

Note that for ksh, the situation described in the 64-bit Solaris
Developer's Guide applies:
#: isainfo -v
64-bit amd64 applications
cx16 sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu
32-bit i386 applications
ahf cx16 sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu
#: ls -l /bin/ksh* /usr/bin/ksh* /bin/*/ksh* /usr/bin/*/ksh*
/usr/lib/isaexec
-r-xr-xr-x 4 root bin 9712 2013-07-21 10:35 /bin/amd64/ksh
-r-xr-xr-x 4 root bin 9712 2013-07-21 10:35 /bin/amd64/ksh93
-r-xr-xr-x 4 root bin 8064 2013-07-21 10:35 /bin/i86/ksh
-r-xr-xr-x 4 root bin 8064 2013-07-21 10:35 /bin/i86/ksh93
-r-xr-xr-x 87 root bin 8064 2013-07-21 10:35 /bin/ksh
-r-xr-xr-x 87 root bin 8064 2013-07-21 10:35 /bin/ksh93
-r-xr-xr-x 4 root bin 9712 2013-07-21 10:35 /usr/bin/amd64/ksh
-r-xr-xr-x 4 root bin 9712 2013-07-21 10:35 /usr/bin/amd64/ksh93
-r-xr-xr-x 4 root bin 8064 2013-07-21 10:35 /usr/bin/i86/ksh
-r-xr-xr-x 4 root bin 8064 2013-07-21 10:35 /usr/bin/i86/ksh93
-r-xr-xr-x 87 root bin 8064 2013-07-21 10:35 /usr/bin/ksh
-r-xr-xr-x 87 root bin 8064 2013-07-21 10:35 /usr/bin/ksh93
-r-xr-xr-x 87 root bin 8064 2013-07-21 10:35 /usr/lib/isaexec

This topic appears not to be addressed adequately on the OpenIndiana wiki
(certainly no mention under Compiling+software+on+OpenIndiana) or the
illumos site (certainly no mention under Building+illumos+and+OpenIndiana
there). It seems to be something one either knows about or not (I stumbled
upon it while researching why uname -m and uname -p returns the same values
on 32-bit and 64-bit installations (and is therefore useless in determining
whether the installation is 32- or 64-bit), and why all of the executables
in /bin (etc) are 32-bit applications on my 64-bit systems, and why all
executables built on my 64-bit systems are 32-bit executables when built
using default compilation flags -- all of those being unexpected).
Bob Friesenhahn
2014-11-04 03:36:39 UTC
Permalink
Post by Bruce Lilly
As of this late date, /usr/bin/bash here is in fact the bash executable,
not a link; but that means that it's 32-bit only and might well present
unexpected issues on 64-bit systems when dealing with large files etc.
(basically anything that involves pointers, long integers, time_t,
ptrdiff_t, clock_t, dev_t, off_t, size_t, or ssize_t in the sources).
Such problems are highly unlikely. Solaris supports large files (LFS)
in 32-bit applications and Autoconf-configured GNU programs use it by
default. Few shell jobs require over 2GB of data, so ptrdiff_t is not
likely to be a problem, and size_t and ssize_t are unlikely to cause
problems either. Perhaps time_t is still an issue.

While it would be nice if Solaris software was all 64-bit, in actual
practice I notice no difference in day to day use between systems with
32-bit applications and 64-bit. Only certain memory-hungry
applications will significantly benefit.

Regardless, the OpenIndiana project did produce an updated bash
binary. I initially built my own, but switched to the OpenIndiana
version when it became available.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Alan Coopersmith
2014-11-04 03:51:13 UTC
Permalink
Post by Bob Friesenhahn
Perhaps time_t is still an issue.
It is. 32-bit binaries will not be able to handle time_t values past
January 2038, whether in API's to get the current time or to access
timestamps on files.

https://blogs.oracle.com/alanc/entry/lp64_bit_by_bit#lp64-abi-changes
lists some other differences between the 32-bit & 64-bit ABI's on
Solaris/illumos OS'es (though illumos won't see the ASLR or ADI
benefits, since those are post-closing additions to Solaris).
--
-Alan Coopersmith- ***@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
david allan finch
2014-11-04 09:07:54 UTC
Permalink
Post by Bob Friesenhahn
While it would be nice if Solaris software was all 64-bit, in actual
practice I notice no difference in day to day use between systems with
32-bit applications and 64-bit. Only certain memory-hungry
applications will significantly benefit.
We spent some time investigating this 10 years back and found that for
most apps that don't require the 64bit address space that they ran
slower compiled for 64bit. 64bit file access was of some us to us but
the we stuck with 64bit compiles and I expect that until CPU cache sizes
increase a lot more there will be no gain outside the OS (and DBs etc)
for 99% of current apps.
david allan finch
2014-11-04 09:10:57 UTC
Permalink
Post by david allan finch
we stuck with 64bit compiles
sorry 32bit compiles
Bob Friesenhahn
2014-11-04 14:40:48 UTC
Permalink
Post by Bob Friesenhahn
While it would be nice if Solaris software was all 64-bit, in actual
practice I notice no difference in day to day use between systems with
32-bit applications and 64-bit. Only certain memory-hungry
applications will significantly benefit.
We spent some time investigating this 10 years back and found that for most
apps that don't require the 64bit address space that they ran slower compiled
for 64bit. 64bit file access was of some us to us but the we stuck with 64bit
compiles and I expect that until CPU cache sizes increase a lot more there
will be no gain outside the OS (and DBs etc) for 99% of current apps.
The AMD64 ABI provides quite a lot more CPU registers than 32-bits.
The function calling convention has changed to make better use of
registers for passing values. This places less stress on the CPU L1
cache and allows the CPU to juggle more variables at once without
doing loads/stores.

In performance benchmarks, I do usually see a performance gain due to
compiling as 64-bits on x86 hardware. Results are highly compiler
dependent.

Regardless, most OS 'utilities' are not CPU bound and so the
difference may not be measurable for normal use.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Jim Klimov
2014-11-04 07:58:50 UTC
Permalink
Post by Bruce Lilly
Post by Bruce Lilly
As of this late date, /usr/bin/bash here is in fact the bash
executable,
Post by Bruce Lilly
not a link; but that means that it's 32-bit only and might well
present
Post by Bruce Lilly
unexpected issues on 64-bit systems when dealing with large files
etc.
Post by Bruce Lilly
(basically anything that involves pointers, long integers, time_t,
ptrdiff_t, clock_t, dev_t, off_t, size_t, or ssize_t in the sources).
Such problems are highly unlikely. Solaris supports large files (LFS)
in 32-bit applications and Autoconf-configured GNU programs use it by
default. Few shell jobs require over 2GB of data, so ptrdiff_t is not
likely to be a problem, and size_t and ssize_t are unlikely to cause
problems either. Perhaps time_t is still an issue.
While it would be nice if Solaris software was all 64-bit, in actual
practice I notice no difference in day to day use between systems with
32-bit applications and 64-bit. Only certain memory-hungry
applications will significantly benefit.
Regardless, the OpenIndiana project did produce an updated bash
binary. I initially built my own, but switched to the OpenIndiana
version when it became available.
Bob
Also note that 64-bit programs have a larger footprint in memory (bigger pointers). While people might dismiss it today (saying all our boxes are big anyway) - not all environments are big or get many benefits from such over-use of resources. You have laptops, vm's, local zones... even if the hardware box is a big powerhouse, why physically deny yourself an ability to run 70 mixed workloads instead of 50 64-bit ones (numbers made up arbitrarily)?

Another rationale I saw in a Sun blog back when Solaris 10 was new and young (relaying from memory, corruption might collect over the years), was that much of the application worker code sufficed to be 32-bit so why not remain such (benefits above). Most of the access to larger items can be done with the 64-bit OS facilities (via syscalls? ipc? weird omnivore linking? I don't remember exactly now...)
So most of the programs (thousands of binaries supplied with a sol10 distro and extension discs) remained 32-bit only. A minority of the lrograms that were deemed to really need this (under 700? or even 100?) were dual-built and provided with the isaexec hack to pick the right binary at run-time depending on the running kernel (32/64).

So... just in case, here were some old news from the attic ;)
You know where the grain and salt are ;)

//Jim
--
Typos courtesy of K-9 Mail on my Samsung Android
Bruce Lilly
2014-11-04 22:52:34 UTC
Permalink
Post by Jim Klimov
Post by Bruce Lilly
Post by Bruce Lilly
As of this late date, /usr/bin/bash here is in fact the bash
executable,
Post by Bruce Lilly
not a link; but that means that it's 32-bit only and might well
[...]
So most of the programs (thousands of binaries supplied with a sol10
distro and extension discs) remained 32-bit only. A minority of the
lrograms that were deemed to really need this (under 700? or even 100?)
were dual-built and provided with the isaexec hack to pick the right binary
at run-time depending on the running kernel (32/64).
One more note applicable to bash before I start a separate thread regarding
32-bit vs. 64 bit issues that aren't bash-specific:

# ls /bin/amd64/*sh /*/bin/amd64/*sh /*/*/bin/amd64/*sh | egrep -v
"lish|ush|mash|rash|\.sh|ssh"
/bin/amd64/bash
/bin/amd64/ksh
/bin/amd64/rbash
/bin/amd64/rksh
/bin/amd64/tclsh
/bin/amd64/tcsh
/bin/amd64/wish
/bin/amd64/zoomsh
/usr/bin/amd64/bash
/usr/bin/amd64/ksh
/usr/bin/amd64/rbash
/usr/bin/amd64/rksh
/usr/bin/amd64/tclsh
/usr/bin/amd64/tcsh
/usr/bin/amd64/wish
/usr/bin/amd64/zoomsh
/usr/openwin/bin/amd64/bash


/usr/openwin/bin/amd64/ksh


/usr/openwin/bin/amd64/rbash


/usr/openwin/bin/amd64/rksh


/usr/openwin/bin/amd64/tclsh


/usr/openwin/bin/amd64/tcsh


/usr/openwin/bin/amd64/wish


/usr/openwin/bin/amd64/zoomsh


/usr/X/bin/amd64/bash


/usr/X/bin/amd64/ksh


/usr/X/bin/amd64/rbash


/usr/X/bin/amd64/rksh


/usr/X/bin/amd64/tclsh


/usr/X/bin/amd64/tcsh
/usr/X/bin/amd64/wish
/usr/X/bin/amd64/zoomsh
/usr/X11/bin/amd64/bash
/usr/X11/bin/amd64/ksh
/usr/X11/bin/amd64/rbash
/usr/X11/bin/amd64/rksh
/usr/X11/bin/amd64/tclsh
/usr/X11/bin/amd64/tcsh
/usr/X11/bin/amd64/wish
/usr/X11/bin/amd64/zoomsh
/usr/X11R6/bin/amd64/bash
/usr/X11R6/bin/amd64/ksh
/usr/X11R6/bin/amd64/rbash
/usr/X11R6/bin/amd64/rksh
/usr/X11R6/bin/amd64/tclsh
/usr/X11R6/bin/amd64/tcsh
/usr/X11R6/bin/amd64/wish
/usr/X11R6/bin/amd64/zoomsh

Evidently there are quite a few shells -- N.B. including bash -- where the
packagers seem to have decided there were issues warranting building and
packaging 64-bit versions.

I'll let somebody else figure out exactly why the recent updated version of
/usr/bin/bash trampled on the isaexec pointing to separate 32- and 64-bit
versions; I don't really care much about bash per se as I don't use it (for
reasons having to do with familiarity, usability, portability, and
reliability; before "shellshock" added security to that list).

David Brodbeck
2014-10-06 17:21:43 UTC
Permalink
On Thu, Oct 2, 2014 at 8:12 AM, Alan Coopersmith <
Post by Alan Coopersmith
On many (most? all?) Linuxes, /bin/sh *is* /bin/bash.
Many, but not all - the Debian family and some others use a lighter weight,
POSIX compatible shell instead, dash, the Debian Almquist Shell; and many
embedded distros use BusyBox instead.
https://en.wikipedia.org/wiki/Almquist_shell
http://lwn.net/Articles/343924/
A big driver of this was faster boot, since boot scripts run on /bin/sh.
On some systems the startup time for all those bash processes was a
considerable portion of the total boot time.

Note: It's not enough to make sure no CGI scripts are being run with
/bin/bash. You also need to make sure no bash processes are being launched
by other scripts, since many scripting languages launch a shell to run
external commands. Unless the environment is explicitly cleared these are
likely to inherit the environment of the calling process, with all the
nasties in it.
--
D. Brodbeck
System Administrator, Linguistics
University of Washington
GPG key fingerprint: 0DB7 4B50 8910 DBC5 B510 79C4 3970 2BC3 2078 D875
The Outsider
2014-10-06 17:50:40 UTC
Permalink
There are a lot of tools depending on bash. Including virusscanners and
spamfilters.

The openCSW bash installs into another directory then the "real"/old bash.
How can you change the old bash with the openCSW bash?

I saw that solaris 11.2 supports a lot of (old) sparc hardware. And most of
the ever produced X86 servers. Supportcontracts are reasonable priced i
think. Aspecialy in this situation...
Post by David Brodbeck
On Thu, Oct 2, 2014 at 8:12 AM, Alan Coopersmith <
Post by Alan Coopersmith
On many (most? all?) Linuxes, /bin/sh *is* /bin/bash.
Many, but not all - the Debian family and some others use a lighter weight,
POSIX compatible shell instead, dash, the Debian Almquist Shell; and many
embedded distros use BusyBox instead.
https://en.wikipedia.org/wiki/Almquist_shell
http://lwn.net/Articles/343924/
A big driver of this was faster boot, since boot scripts run on /bin/sh.
On some systems the startup time for all those bash processes was a
considerable portion of the total boot time.
Note: It's not enough to make sure no CGI scripts are being run with
/bin/bash. You also need to make sure no bash processes are being launched
by other scripts, since many scripting languages launch a shell to run
external commands. Unless the environment is explicitly cleared these are
likely to inherit the environment of the calling process, with all the
nasties in it.
--
D. Brodbeck
System Administrator, Linguistics
University of Washington
GPG key fingerprint: 0DB7 4B50 8910 DBC5 B510 79C4 3970 2BC3 2078 D875
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
The Outsider
2014-10-06 17:58:11 UTC
Permalink
Search q-nap & shellshock and you see how deep this goes...
Post by David Brodbeck
On Thu, Oct 2, 2014 at 8:12 AM, Alan Coopersmith <
Post by Alan Coopersmith
On many (most? all?) Linuxes, /bin/sh *is* /bin/bash.
Many, but not all - the Debian family and some others use a lighter weight,
POSIX compatible shell instead, dash, the Debian Almquist Shell; and many
embedded distros use BusyBox instead.
https://en.wikipedia.org/wiki/Almquist_shell
http://lwn.net/Articles/343924/
A big driver of this was faster boot, since boot scripts run on /bin/sh.
On some systems the startup time for all those bash processes was a
considerable portion of the total boot time.
Note: It's not enough to make sure no CGI scripts are being run with
/bin/bash. You also need to make sure no bash processes are being launched
by other scripts, since many scripting languages launch a shell to run
external commands. Unless the environment is explicitly cleared these are
likely to inherit the environment of the calling process, with all the
nasties in it.
--
D. Brodbeck
System Administrator, Linguistics
University of Washington
GPG key fingerprint: 0DB7 4B50 8910 DBC5 B510 79C4 3970 2BC3 2078 D875
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Bayard Bell
2014-10-06 18:10:46 UTC
Permalink
These aren't new aspects of the bug. The fact is that default operation of
systems using bash as the shell for interpolation with system or for
scripts interpreted by bash allows remote code execution by taking strings
from untrusted sources (e.g. USER_AGENT in web servers) and passing them
through the environment, which allows remote code execution. What you're
reporting here is instances of the resulting problem in products matching
this description, not fundamental changes to the understanding of the bug.

What's been difficult is that Red Hat's security response team and bash
upstream initially differed on the scope of the issue and thus patching, as
Red Hat believed there were broader problems and that upstream patches were
therefore too limited in scope. Red Hat was subsequently shown to be
correct.

The confusion is that there are a number of CVEs out there, and the patches
went out in batches. There are quite a variety of tests proposed for the
fully documented CVEs, and some of the CVEs remain embargoed, with Red Hat
simply advising that people take patches which bash upstream subsequently
accepted.
Post by The Outsider
Search q-nap & shellshock and you see how deep this goes...
On Thu, Oct 2, 2014 at 8:12 AM, Alan Coopersmith <
Post by Alan Coopersmith
Post by Alan Coopersmith
On many (most? all?) Linuxes, /bin/sh *is* /bin/bash.
Many, but not all - the Debian family and some others use a lighter
weight,
Post by Alan Coopersmith
POSIX compatible shell instead, dash, the Debian Almquist Shell; and
many
Post by Alan Coopersmith
embedded distros use BusyBox instead.
https://en.wikipedia.org/wiki/Almquist_shell
http://lwn.net/Articles/343924/
A big driver of this was faster boot, since boot scripts run on /bin/sh.
On some systems the startup time for all those bash processes was a
considerable portion of the total boot time.
Note: It's not enough to make sure no CGI scripts are being run with
/bin/bash. You also need to make sure no bash processes are being launched
by other scripts, since many scripting languages launch a shell to run
external commands. Unless the environment is explicitly cleared these are
likely to inherit the environment of the calling process, with all the
nasties in it.
--
D. Brodbeck
System Administrator, Linguistics
University of Washington
GPG key fingerprint: 0DB7 4B50 8910 DBC5 B510 79C4 3970 2BC3 2078 D875
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Bob Friesenhahn
2014-10-07 01:35:53 UTC
Permalink
The gift keeps on giving. There is yet another related security patch
for bash. Here is the one for bash 4.3:

http://lists.gnu.org/archive/html/bug-bash/2014-10/msg00040.html

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Richard L. Hamilton
2014-10-07 03:19:49 UTC
Permalink
Which CVE is that, or is it something else?
Post by Bob Friesenhahn
http://lists.gnu.org/archive/html/bug-bash/2014-10/msg00040.html
Bob
--
Bob Friesenhahn
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Bayard Bell
2014-10-07 11:07:13 UTC
Permalink
No new CVE. This looks to be a proper fix for CVE-2014-6278, where the
assessment is that the parser bugs that make this exploitable were already
addressed either by the Red Hat patches or upstream patch 027. That's what
I gather between these sources:

https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00032.html
http://lcamtuf.blogspot.co.uk/2014/09/bash-bug-apply-unofficial-patch-now.html
http://lcamtuf.blogspot.co.uk/2014/09/quick-notes-about-bash-bug-its-impact.html

Note that patch 030 for bash 4.3 is attributed to lcamtuf. I've not found
any security responders who shipped previously available fixes telling
people that they need to ship these further changes as an urgent response
or even that they have to have them. Red Hat explicitly references
lcamtuf's blog post as independent confirmation of their analysis and fixes.

Cheers,
Bayard
Post by Richard L. Hamilton
Which CVE is that, or is it something else?
Post by Bob Friesenhahn
The gift keeps on giving. There is yet another related security patch
http://lists.gnu.org/archive/html/bug-bash/2014-10/msg00040.html
Bob
--
Bob Friesenhahn
http://www.simplesystems.org/users/bfriesen/
Post by Bob Friesenhahn
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Carl Brewer
2014-09-25 11:31:52 UTC
Permalink
Post by Carl Brewer
Post by Alexander Pyhalov
Post by Udo Grabowski (IMK)
Post by Jonathan Adams
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
The bug "works", so we are affected with everything that
is based on bash, as well as all users using bash in their
projects.
This is a bug with high impact and risks, so a fix should be
available for oi dev and hipster as fast as possible.
Hello.
I've seen fix for CVE-2014-6271, which I've already committed, but not
for CVE-2014-7169...
I'm stuck on 151a8 at the moment, is there any chance a fixed bash
binary could be made available somewhere?
Binary is here.
http://buildzone.oi-build.r61.net/bash
It runs on /dev for me, but I have /dev with freshly rebuilt
illumos-gate. You can try if it works for you.
Of course, I don't guarantee that it will not eat your data :)
It's not immediately happy :

$ ./bash --version
ld.so.1: bash: fatal: libc.so.1: version 'ILLUMOS_0.8' not found
(required by file bash)
ld.so.1: bash: fatal: libc.so.1: open failed: No such file or directory
Killed


ldd ./bash
libcurses.so.1 => /lib/libcurses.so.1
libdl.so.1 => /lib/libdl.so.1
libc.so.1 => /lib/libc.so.1
libc.so.1 (ILLUMOS_0.8) => (version not found)
libsocket.so.1 => /lib/libsocket.so.1
libgen.so.1 => /lib/libgen.so.1
libnsl.so.1 => /lib/libnsl.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libm.so.2 => /lib/libm.so.2


I wonder, I've tried in the past to bump this box to 151a9 but had
problems with messy pkg errors that I didn't have the time to sort out -
how stable is hipster these days? Stable enough to run a LAN server
with a couple of Virtualbox VM's on it?
Brian Hechinger
2014-09-25 11:45:34 UTC
Permalink
Don't get too up in a rush to upgrade bash. It's just been verified that
the patch isn't actually effective. :(

-brian
Post by Carl Brewer
Post by Carl Brewer
Post by Alexander Pyhalov
Post by Udo Grabowski (IMK)
Post by Jonathan Adams
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
The bug "works", so we are affected with everything that
is based on bash, as well as all users using bash in their
projects.
This is a bug with high impact and risks, so a fix should be
available for oi dev and hipster as fast as possible.
Hello.
I've seen fix for CVE-2014-6271, which I've already committed, but not
for CVE-2014-7169...
I'm stuck on 151a8 at the moment, is there any chance a fixed bash
binary could be made available somewhere?
Binary is here.
http://buildzone.oi-build.r61.net/bash
It runs on /dev for me, but I have /dev with freshly rebuilt
illumos-gate. You can try if it works for you.
Of course, I don't guarantee that it will not eat your data :)
$ ./bash --version
ld.so.1: bash: fatal: libc.so.1: version 'ILLUMOS_0.8' not found (required
by file bash)
ld.so.1: bash: fatal: libc.so.1: open failed: No such file or directory
Killed
ldd ./bash
libcurses.so.1 => /lib/libcurses.so.1
libdl.so.1 => /lib/libdl.so.1
libc.so.1 => /lib/libc.so.1
libc.so.1 (ILLUMOS_0.8) => (version not found)
libsocket.so.1 => /lib/libsocket.so.1
libgen.so.1 => /lib/libgen.so.1
libnsl.so.1 => /lib/libnsl.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libm.so.2 => /lib/libm.so.2
I wonder, I've tried in the past to bump this box to 151a9 but had problems
with messy pkg errors that I didn't have the time to sort out - how stable
is hipster these days? Stable enough to run a LAN server with a couple of
Virtualbox VM's on it?
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Alexander Pyhalov
2014-09-25 11:45:52 UTC
Permalink
Post by Carl Brewer
I wonder, I've tried in the past to bump this box to 151a9 but had
problems with messy pkg errors that I didn't have the time to sort out -
how stable is hipster these days? Stable enough to run a LAN server
with a couple of Virtualbox VM's on it?
Honestly, I don't know :)
Usually if something is broken, it's desktop-related soft (as it's
harder to test thoroughly). I think that in the nearest future Sun DHCP
server will be removed from illumos-gate (and our users will immediately
see this).
I run several test VMs and VMs which I use in my courses (VirtualBox,
VMware and KVM guests, but no OI host). There was no anything completely
catastrophic. However, sometimes some issues appear (don't know if /dev
has them). I think, you can try. Note, that dev => hipster updates are
not supported now. The best way to install is to use install CDs:
http://dlc.openindiana.org/isos/hipster/.
--
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department
Bob Friesenhahn
2014-09-28 14:40:12 UTC
Permalink
Hopefully some kind person with necessary knowlege and access will
push an updated bash package which works on 151a8/9 so that servers
based on OpenIndiana are no longer a disaster situation. It might be
necessary to do this a few times until an official proper cure is
posted.

One service I found (self-compiled in my case) which seemed to be
riddled with bash is git service and git web since git uses many shell
scripts as part of its implementation and chooses bash.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Udo Grabowski (IMK)
2014-09-29 09:43:02 UTC
Permalink
Post by Jonathan Adams
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
does anyone know if this affects us?
As predicted, there's more bash horror (Score 11....):
<http://lcamtuf.blogspot.de/2014/09/bash-bug-apply-unofficial-patch-now.html>
--
Dr.Udo Grabowski Inst.f.Meteorology & Climate Research IMK-ASF-SAT
http://www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology http://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026
Jason Matthews
2014-09-29 15:46:20 UTC
Permalink
paraphrasing "Joshua" from "WarGames," bash is a strange game where the only winning move is not to play.

J.

Sent from my iPhone
Jim Klimov
2014-09-30 08:40:28 UTC
Permalink
Post by Jason Matthews
paraphrasing "Joshua" from "WarGames," bash is a strange game where the
only winning move is not to play.
J.
Sent from my iPhone
On Sep 29, 2014, at 2:43 AM, "Udo Grabowski (IMK)"
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Maybe a stupid question on my side (sorry i'm overwhelmed with relocation and other life events), but how really is this bug exploitable? Especially on Solaris and illumos systems with sh/ksh by default and assumed no scripted CGI (hosts of native or java sourced web-code though) ?

I mean, from what I gather, the bug allows to execute unexpected code with credentials of the user that executes bash. On a local system someone should already have a login to do that (or a hacked backdoor), so may have other means for doing mischief. Can it be used to elevate? How? Via config files for root-executed initscripts and cronjobs? If these are editable by a random untrustworthy user, the system is already busted without the bug...

I kinda get the point about web-scripts especially where system programs can be called with the default shell of the webserver account (bash for some), although did not really grasp from cursory looks at the articles just how the env-function can be passed via http requests to do the exploit. Let's assume it can be done... as protection/precaution, would it suffice to make sure that apache's and such do not use bash in their /etc/passwd fields (and restart the daemons)?

Also, did anyone (beside Oracle) already build and publish a replacement SUNWbash for legacy Solaris 8-10 systems? ;)

Thanks, Jim
--
Typos courtesy of K-9 Mail on my Samsung Android
Jonathan Adams
2014-09-30 09:23:35 UTC
Permalink
We have tested all our systems, and the only ones that were vulnerable (in
cgi-bin) were ones that we had put in a bash script to test.

if you don't have any bash scripts in your cgi-bin, and your default system
shll is not bash (and on Solaris, and Ubuntu it isn't) then you pretty much
aren't exploitable via a web-server.

there are possible issues if you have restricted users/remote logons ... if
the user has the bash shell as their default it is possible to escape from
the restricted environment.

e.g. http://troy.jdmz.net/rsync/index.html

where you have a "validate-rsync" procedure that checks if you are
connecting with the command rsync ...

(the easiest way to fix the above is to create an rsyncd server and connect
to that, rather than ssh'ing)

also, although it's annoying you probably want to go around and delete all
your "authorized_keys" files so that you cannot ssh in without a password.

I'm not sure, but I've been told that github/heroku use bash for the shells
that they allow remote connections on, I don't know if they are exploitable
remotely, but I don't really want to check that out :)

remember that you can only use this bug to run commands as the user who is
logged on ... if the person knows the username and password already then
they can just run the command straight.

Jon
Post by Jim Klimov
Post by Jason Matthews
paraphrasing "Joshua" from "WarGames," bash is a strange game where the
only winning move is not to play.
J.
Sent from my iPhone
On Sep 29, 2014, at 2:43 AM, "Udo Grabowski (IMK)"
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Maybe a stupid question on my side (sorry i'm overwhelmed with relocation
and other life events), but how really is this bug exploitable? Especially
on Solaris and illumos systems with sh/ksh by default and assumed no
scripted CGI (hosts of native or java sourced web-code though) ?
I mean, from what I gather, the bug allows to execute unexpected code with
credentials of the user that executes bash. On a local system someone
should already have a login to do that (or a hacked backdoor), so may have
other means for doing mischief. Can it be used to elevate? How? Via config
files for root-executed initscripts and cronjobs? If these are editable by
a random untrustworthy user, the system is already busted without the bug...
I kinda get the point about web-scripts especially where system programs
can be called with the default shell of the webserver account (bash for
some), although did not really grasp from cursory looks at the articles
just how the env-function can be passed via http requests to do the
exploit. Let's assume it can be done... as protection/precaution, would it
suffice to make sure that apache's and such do not use bash in their
/etc/passwd fields (and restart the daemons)?
Also, did anyone (beside Oracle) already build and publish a replacement
SUNWbash for legacy Solaris 8-10 systems? ;)
Thanks, Jim
--
Typos courtesy of K-9 Mail on my Samsung Android
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Bob Friesenhahn
2014-09-30 14:02:09 UTC
Permalink
Post by Jim Klimov
Maybe a stupid question on my side (sorry i'm overwhelmed with
relocation and other life events), but how really is this bug
exploitable? Especially on Solaris and illumos systems with sh/ksh
by default and assumed no scripted CGI (hosts of native or java
sourced web-code though) ?
It is readily exploitable for web CGI scripts which provide/export
values provided by the web server and remote client as environment
variables. The "CGI" paradigm has thoroughly permiated web
application infrastructures. The exploit requires that bash be
executed with the problematic environment variables already set.
Service applications obtained from Linux often require bash in order
to run.

On my own systems, the only service I found which was suspect was
'git' and 'gitweb.cgi' since the 'git' implementation depends on many
shell scripts, which specifically depend on bash.

For example, this is output from the test-cgi script provided with
Apache:

CGI/1.0 test script report:

argc is 0. argv is .

SERVER_SOFTWARE = Apache/2.0.63 (Unix) DAV/2
SERVER_NAME = www.simplesystems.org
GATEWAY_INTERFACE = CGI/1.1
SERVER_PROTOCOL = HTTP/1.1
SERVER_PORT = 80
REQUEST_METHOD = GET
HTTP_ACCEPT = text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
PATH_INFO =
PATH_TRANSLATED =
SCRIPT_NAME = /cgi-bin/test-cgi
QUERY_STRING =
REMOTE_HOST =
REMOTE_ADDR = 65.66.245.66
REMOTE_USER =
AUTH_TYPE =
CONTENT_TYPE =
CONTENT_LENGTH =

and this is output from a Perl script called 'printenv' which prints
everything made available:

DOCUMENT_ROOT="/html"
GATEWAY_INTERFACE="CGI/1.1"
HTTP_ACCEPT="text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
HTTP_ACCEPT_ENCODING="gzip, deflate"
HTTP_ACCEPT_LANGUAGE="en-US,en;q=0.5"
HTTP_CONNECTION="keep-alive"
HTTP_HOST="www.simplesystems.org"
HTTP_USER_AGENT="Mozilla/5.0 (X11; SunOS i86pc; rv:30.0)
Gecko/20100101 Firefox/30.0"
PATH="/usr/sbin:/usr/bin"
QUERY_STRING=""
REMOTE_ADDR="65.66.245.66"
REMOTE_PORT="53877"
REQUEST_METHOD="GET"
REQUEST_URI="/cgi-bin/printenv"
SCRIPT_FILENAME="/var/apache2/cgi-bin/printenv"
SCRIPT_NAME="/cgi-bin/printenv"
SERVER_ADDR="65.66.246.89"
SERVER_ADMIN="***@simplesystems.org"
SERVER_NAME="www.simplesystems.org"
SERVER_PORT="80"
SERVER_PROTOCOL="HTTP/1.1"
SERVER_SIGNATURE="<address>Apache/2.0.63 (Unix) DAV/2 Server at www.simplesystems.org Port 80</address>\n"
SERVER_SOFTWARE="Apache/2.0.63 (Unix) DAV/2"
TZ="US/Central"
UNIQUE_ID="rExdoEFC9koAAEJpoxgAAAAJ"
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Bruce Lilly
2014-10-01 20:38:47 UTC
Permalink
Post by Harry Putnam
So, do you mean that ksh93 does not have the vulnerability?
http://lists.research.att.com/pipermail/ast-developers/2014q3/003964.html

On Tue, Sep 30, 2014 at 10:02 AM, Bob Friesenhahn <
Post by Harry Putnam
Post by Jim Klimov
Maybe a stupid question on my side (sorry i'm overwhelmed with relocation
and other life events), but how really is this bug exploitable? Especially
on Solaris and illumos systems with sh/ksh by default and assumed no
scripted CGI (hosts of native or java sourced web-code though) ?
It is readily exploitable for web CGI scripts which provide/export values
provided by the web server and remote client as environment variables. The
"CGI" paradigm has thoroughly permiated web application infrastructures.
The exploit requires that bash be executed with the problematic environment
variables already set. Service applications obtained from Linux often
require bash in order to run.
On my own systems, the only service I found which was suspect was 'git'
and 'gitweb.cgi' since the 'git' implementation depends on many shell
scripts, which specifically depend on bash.
argc is 0. argv is .
SERVER_SOFTWARE = Apache/2.0.63 (Unix) DAV/2
SERVER_NAME = www.simplesystems.org
GATEWAY_INTERFACE = CGI/1.1
SERVER_PROTOCOL = HTTP/1.1
SERVER_PORT = 80
REQUEST_METHOD = GET
HTTP_ACCEPT = text/html,application/xhtml+xml,application/xml;q=0.9,*/*;
q=0.8
PATH_INFO =
PATH_TRANSLATED =
SCRIPT_NAME = /cgi-bin/test-cgi
QUERY_STRING =
REMOTE_HOST =
REMOTE_ADDR = 65.66.245.66
REMOTE_USER =
AUTH_TYPE =
CONTENT_TYPE =
CONTENT_LENGTH =
and this is output from a Perl script called 'printenv' which prints
DOCUMENT_ROOT="/html"
GATEWAY_INTERFACE="CGI/1.1"
HTTP_ACCEPT="text/html,application/xhtml+xml,
application/xml;q=0.9,*/*;q=0.8"
HTTP_ACCEPT_ENCODING="gzip, deflate"
HTTP_ACCEPT_LANGUAGE="en-US,en;q=0.5"
HTTP_CONNECTION="keep-alive"
HTTP_HOST="www.simplesystems.org"
HTTP_USER_AGENT="Mozilla/5.0 (X11; SunOS i86pc; rv:30.0) Gecko/20100101
Firefox/30.0"
PATH="/usr/sbin:/usr/bin"
QUERY_STRING=""
REMOTE_ADDR="65.66.245.66"
REMOTE_PORT="53877"
REQUEST_METHOD="GET"
REQUEST_URI="/cgi-bin/printenv"
SCRIPT_FILENAME="/var/apache2/cgi-bin/printenv"
SCRIPT_NAME="/cgi-bin/printenv"
SERVER_ADDR="65.66.246.89"
SERVER_NAME="www.simplesystems.org"
SERVER_PORT="80"
SERVER_PROTOCOL="HTTP/1.1"
SERVER_SIGNATURE="<address>Apache/2.0.63 (Unix) DAV/2 Server at
www.simplesystems.org Port 80</address>\n"
SERVER_SOFTWARE="Apache/2.0.63 (Unix) DAV/2"
TZ="US/Central"
UNIQUE_ID="rExdoEFC9koAAEJpoxgAAAAJ"
--
Bob Friesenhahn
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Bob Friesenhahn
2014-10-01 23:06:04 UTC
Permalink
I am not sure who has the ability to build and update OpenIndiana
packages, but it will be really really bad for the future of
OpenIndiana if it fails to supply a fixed version of its bash package.

This article (including many example exploits) was posted on another
list:

http://www.fireeye.com/blog/technical/2014/09/shellshock-in-the-wild.html

Known exploits include Web CGI, DHCP client, OpenVPN, ssh, gitweb, and
(possibly) git service. Even if the service is implemented in Perl,
Python, Java, or C, it may still be exploitable if it exports
externally-provided data as environment variables some program it
invokes eventually happens to execute bash.

While bash is not a "native" shell for OpenIndiana, it is quite
heavily used. It is unfortunate that it is often used as a user login
shell so it is painful to simply move the existing binary to the side.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Richard L. Hamilton
2014-10-02 03:12:20 UTC
Permalink
I’m in a similar situation: Solaris 11 at home, without support contract. My solution was to install OpenCSW’s updated bash (I had OpenCSW in place anyway), move /usr/bin/bash out of the way, and symlink /opt/csw/bin/bash to /usr/bin/bash.

Use a copy instead of a symlink if /opt is a separate filesystem! And remember to undo those changes to /usr/bin _before_ installing a properly packaged update.

Until Apple released their fix, I did something similar on my Macs using MacPorts.

It’s temporary, and all my publicly accessible web servers etc have access controls anyway; but until a legitimate update comes along, it’s a lot better than nothing. For Solaris 11, I’ll just have to wait for 11.3 to have an official fix without support contract (probably six months or so?).
I am not sure who has the ability to build and update OpenIndiana packages, but it will be really really bad for the future of OpenIndiana if it fails to supply a fixed version of its bash package.
http://www.fireeye.com/blog/technical/2014/09/shellshock-in-the-wild.html
Known exploits include Web CGI, DHCP client, OpenVPN, ssh, gitweb, and (possibly) git service. Even if the service is implemented in Perl, Python, Java, or C, it may still be exploitable if it exports externally-provided data as environment variables some program it invokes eventually happens to execute bash.
While bash is not a "native" shell for OpenIndiana, it is quite heavily used. It is unfortunate that it is often used as a user login shell so it is painful to simply move the existing binary to the side.
Bob
--
Bob Friesenhahn
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Richard L. Hamilton
2014-10-02 03:14:24 UTC
Permalink
I am not sure who has the ability to build and update OpenIndiana packages, but it will be really really bad for the future of OpenIndiana if it fails to supply a fixed version of its bash package.
http://www.fireeye.com/blog/technical/2014/09/shellshock-in-the-wild.html
Known exploits include Web CGI, DHCP client, OpenVPN, ssh, gitweb, and (possibly) git service. Even if the service is implemented in Perl, Python, Java, or C, it may still be exploitable if it exports externally-provided data as environment variables some program it invokes eventually happens to execute bash.
While bash is not a "native" shell for OpenIndiana, it is quite heavily used. It is unfortunate that it is often used as a user login shell so it is painful to simply move the existing binary to the side.
Bob
--
Bob Friesenhahn
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Frank Van Damme
2014-10-03 09:49:06 UTC
Permalink
Post by Bob Friesenhahn
I am not sure who has the ability to build and update OpenIndiana
packages, but it will be really really bad for the future of OpenIndiana if
it fails to supply a fixed version of its bash package.
I have only one system running OpenIndiana, not a webserver. This little
bug indeed makes one wonder if OpenIndiana ever pays any attention to
security at all. Looks like there's no one home at
http://openindiana.org/support/security-advisories/ ...

Note taken.
--
Frank Van Damme
Make everything as simple as possible, but not simpler. - Albert Einstein
Andreas Wacknitz
2014-10-03 09:55:58 UTC
Permalink
Post by Frank Van Damme
Post by Bob Friesenhahn
I am not sure who has the ability to build and update OpenIndiana
packages, but it will be really really bad for the future of OpenIndiana if
it fails to supply a fixed version of its bash package.
I have only one system running OpenIndiana, not a webserver. This little
bug indeed makes one wonder if OpenIndiana ever pays any attention to
security at all. Looks like there's no one home at
http://openindiana.org/support/security-advisories/ ...
Note taken.
What most people don’t understand is that OpenIndiana is YOURS.
OpenIndiana is just a name with no company behind.
If you want something and nobody else is doing it then do it by yourself.
So instead of taking notes you should start acting.

Andreas
Frank Van Damme
2014-10-06 07:31:37 UTC
Permalink
Post by Andreas Wacknitz
What most people don’t understand is that OpenIndiana is YOURS.
OpenIndiana is just a name with no company behind.
If you want something and nobody else is doing it then do it by yourself.
So instead of taking notes you should start acting.
I know. But it looks like openindiana at the moment hasn't got the
community momentum necessary to keep up with security issues. No blame to
anyone, but one has to keep it into account if using in a production
environment.
--
Frank Van Damme
Make everything as simple as possible, but not simpler. - Albert Einstein
Frank Van Damme
2014-10-06 09:56:05 UTC
Permalink
Post by Frank Van Damme
Post by Andreas Wacknitz
What most people don’t understand is that OpenIndiana is YOURS.
OpenIndiana is just a name with no company behind.
If you want something and nobody else is doing it then do it by yourself.
So instead of taking notes you should start acting.
I know. But it looks like openindiana at the moment hasn't got the
community momentum necessary to keep up with security issues. No blame to
anyone, but one has to keep it into account if using in a production
environment.
FYI, OpenCSW seems to have a more current Bash version on board:
http://www.opencsw.org/package/bash/
--
Frank Van Damme
Make everything as simple as possible, but not simpler. - Albert Einstein
Harry Putnam
2014-10-02 03:21:34 UTC
Permalink
Post by Bruce Lilly
http://lists.research.att.com/pipermail/ast-developers/2014q3/003964.html
Thanks for that... that is encouraging.
outsider
2014-10-02 10:03:42 UTC
Permalink
Has anyone tried to install the patched BASH version of
https://unixpackages.com [1] ?

It installs to a different location then the OI Bash and gives an error
:

bash --version

ld.so.1: bash: fatal: libintl.so.8: open failed: No such file or
directory Killed

does anyone have a solution for a manual update of bash?


Links:
------
[1] https://unixpackages.com
Cal Sawyer
2014-10-06 12:54:57 UTC
Permalink
Per openindiana.org:

"OpenIndiana is a robust enterprise operating system"

If the only solutions being offered after nearly 2 weeks are a) use ksh because bash is somehow inferior (shades of "csh-is-deterimental") or 2. rebuild bash youself from source, i'd have to say that imho it's the polar opposite and this appears to be confirmed in Andreas's post.

OmniOS had, as did virtually world+dog, a patch out the day after the bug was announced - which is consistent with a/proper/ distribution, and it's where i'm going now

- cal sawyer (on oi_151a8)
What most people don?t understand is that OpenIndiana is YOURS.
OpenIndiana is just a name with no company behind.
If you want something and nobody else is doing it then do it by yourself.
So instead of taking notes you should start acting.
I know. But it looks like openindiana at the moment hasn't got the
community momentum necessary to keep up with security issues. No blame to
anyone, but one has to keep it into account if using in a production
environment.


-- Frank Van Damme Make everything as simple as possible, but not
simpler. - Albert Einstein
Udo Grabowski (IMK)
2014-10-06 13:30:48 UTC
Permalink
Post by Cal Sawyer
...
If the only solutions being offered after nearly 2 weeks are a) use ksh because bash is somehow inferior (shades of "csh-is-deterimental") or 2. rebuild bash youself from source, i'd have to say that imho it's the polar opposite and this appears to be confirmed in Andreas's post.
The simple fact is: The /dev maintainer(s?) seem to have silently
resigned without handing over the keys....
So no one is left who actually can apply and distribute the
patch (which shouldn't be that difficult, as it's only one package);
the /hipster community up to now has served only itself for the
purpose of porting the complete OI userland to gcc, and now, as
the pressure is rising, is trying to reorganise to take over /dev
to actually make stable and useable production releases.
This will take time, but I'm completely with you that a patch
for /dev/ should be made available as fast as possible, so the very
first task is to actually get access to the /dev/ infrastructure
to get at least something started.
--
Dr.Udo Grabowski Inst.f.Meteorology & Climate Research IMK-ASF-SAT
http://www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology http://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026
Cal Sawyer
2014-10-09 12:18:35 UTC
Permalink
Thanks very much for the reply and the succinct description of what's
happened to OI development, Udo

Good luck to everyone who's using OI in actual production! Me and my
65TB need to leave the building :)

best regards,

- cal sawyer
Post by Udo Grabowski (IMK)
Post by Cal Sawyer
...
If the only solutions being offered after nearly 2 weeks are a) use
ksh because bash is somehow inferior (shades of
"csh-is-deterimental") or 2. rebuild bash youself from source, i'd
have to say that imho it's the polar opposite and this appears to be
confirmed in Andreas's post.
The simple fact is: The /dev maintainer(s?) seem to have silently
resigned without handing over the keys....
So no one is left who actually can apply and distribute the
patch (which shouldn't be that difficult, as it's only one package);
the /hipster community up to now has served only itself for the
purpose of porting the complete OI userland to gcc, and now, as
the pressure is rising, is trying to reorganise to take over /dev
to actually make stable and useable production releases.
This will take time, but I'm completely with you that a patch
for /dev/ should be made available as fast as possible, so the very
first task is to actually get access to the /dev/ infrastructure
to get at least something started.
Udo Grabowski (IMK)
2014-10-09 13:41:35 UTC
Permalink
Post by Cal Sawyer
Thanks very much for the reply and the succinct description of what's
happened to OI development, Udo
Good luck to everyone who's using OI in actual production! Me and my
65TB need to leave the building :)
We have 400 TB and are still in...
--
Dr.Udo Grabowski Inst.f.Meteorology & Climate Research IMK-ASF-SAT
http://www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology http://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026
Alexander Pyhalov
2014-10-09 13:56:10 UTC
Permalink
Post by Udo Grabowski (IMK)
We have 400 TB and are still in...
Hi.

Could you share some specifications of this installation? I'm interested
in hardware specs, zfs pools organization, what do you use for HA,
backup, any other interesting details, how do you share volumes
(iSCSI/FC), etc..
--
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department
Udo Grabowski (IMK)
2014-10-09 14:45:19 UTC
Permalink
Post by Alexander Pyhalov
Post by Udo Grabowski (IMK)
We have 400 TB and are still in...
Hi.
Could you share some specifications of this installation? I'm interested
in hardware specs, zfs pools organization, what do you use for HA,
backup, any other interesting details, how do you share volumes
(iSCSI/FC), etc..
See attached pdf for our current setup. No HA, we rely on NFSv4,
therefore all pools have SSD or Sun F20 flash log devices for
fast sync write. SGE gridengine for the compute jobs, which are
about 150.000 per 3 days. /home and some rpools are backed up
via IBM Tivoli to our local computing center (very large
StorageTek band roboter), results are backed up to a very large
11 PB DDN/SONAS storage park.

All old, but extremely reliable Sun storage Thumper X4540 + Sun
Constellation type cluster based on C48 with fast X6275 blades
(768 cores), a X4275 as fast compute server with a 12 TB online
pool, and a Fujitsu RX 900 S2 with 80 cores and 2.1 TB RAM for
larger databases and parallel SMP optimized programs. All connected
with broadband 10Gb/s and 1Gb/s stacked Cisco and BlackDiamond
network switches and a separate local management network for the
service processors.

The larger Work_Pools are 48 and 96 TB in RAIDZ1 config with
7-8 vdevs/5-7 1 or 2TB disks, one RAIDZ2 with three (ten 1 TB disk) vdevs
for the precious stuff, all running on oi151a7/a9, and 21 workstations
Sun M27, Dell Precision T3500/T3600, and Fujitsu Celsius M720 also
running OI 151 a7/a9. All of these nodes are based on a single,
well crafted rpool that we multiply regardless of hardware with
a procedure I described earlier in this list.
And right to the picture the blue arrows point to the aforemantioned
DDN/SONAS storage based on IBM GPFS in our local computing center
for the stuff we don't work on everday. Wich means that most of the
data in our local cellar is indeed used everyday in computations,
the current workload produces 3.7 TB new data every week on average
(we do this for 15 years now, of course we started with a smaller,
but unbelievably expensive 6 TB FC storage RAID based on DEC Alpha
OSF/1 AdvFS and a 32 core 8x Alpha ES40 cluster).

Pools are a bit too large for conventional disks, we are often hurt
by 24 days resilverung times for a 2 TB disk due to high fragmentation,
where all resilver optimizations in kernel variables will not help
anymore. Therefore, our current plan is to buy or build a 50 TB
SSD storage machine for the compute cluster workload which will
eradicate that bottleneck (and others too...).

What for? It's 10 years of ENVISAT/MIPAS satellite data (infrared
spectra) which we invert to get atmospheric trace gas constituents,
to finally understand the atmospheric chemistry (e.g., ozone
destruction, atmospheric ciculation, etc.pp.). Additionally,
about 100 TB of our own balloon data, and data of about 40 other
satellites and ground stations to compare our data with.
So mostly we are doing heavy data movement and have large RAM
requirements (~3-25 GB/core) for our compute jobs.

Hope that gives you enough details.
--
Dr.Udo Grabowski Inst.f.Meteorology & Climate Research IMK-ASF-SAT
http://www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology http://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026
Udo Grabowski (IMK)
2014-10-09 14:59:24 UTC
Permalink
Here are some photos of our installation in its early
stages, the empty spaces therein are now all filled:
<http://www.imk-asf.kit.edu/english/763.php>
Post by Alexander Pyhalov
Post by Udo Grabowski (IMK)
We have 400 TB and are still in...
Hi.
Could you share some specifications of this installation? I'm interested
in hardware specs, zfs pools organization, what do you use for HA,
backup, any other interesting details, how do you share volumes
(iSCSI/FC), etc..
......
--
Dr.Udo Grabowski Inst.f.Meteorology & Climate Research IMK-ASF-SAT
http://www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology http://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026
Udo Grabowski (IMK)
2014-10-09 15:06:41 UTC
Permalink
And some interesting statistics here:
<http://www.imk-asf.kit.edu/english/1468.php>
Post by Udo Grabowski (IMK)
Here are some photos of our installation in its early
<http://www.imk-asf.kit.edu/english/763.php>
Post by Alexander Pyhalov
Post by Udo Grabowski (IMK)
We have 400 TB and are still in...
Hi.
Could you share some specifications of this installation? I'm interested
in hardware specs, zfs pools organization, what do you use for HA,
backup, any other interesting details, how do you share volumes
(iSCSI/FC), etc..
......
--
Dr.Udo Grabowski Inst.f.Meteorology & Climate Research IMK-ASF-SAT
http://www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology http://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026
Alexander Pyhalov
2014-10-09 15:08:16 UTC
Permalink
Post by Udo Grabowski (IMK)
Post by Alexander Pyhalov
Post by Udo Grabowski (IMK)
We have 400 TB and are still in...
Hi.
Could you share some specifications of this installation? I'm interested
in hardware specs, zfs pools organization, what do you use for HA,
backup, any other interesting details, how do you share volumes
(iSCSI/FC), etc..
See attached pdf for our current setup. No HA, we rely on NFSv4,
...
Post by Udo Grabowski (IMK)
Hope that gives you enough details.
Thanks for information. Sounds great :) I've just returned from IBM
seminar on Storwize V7000 and thought several times: "This great, but
perhaps I could do it 5-10 times cheaper on OI and something like
http://www.supermicro.nl/products/nfo/CiB.cfm".
We have two Storwizes, and they are great, but for now we lack cheap
storage which we could provide to our clients.
--
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department
Alexander Pyhalov
2014-10-13 13:19:00 UTC
Permalink
Hello.
Jon Tibble has just pushed updated bash package with recent security
fixes to OI /dev a9. Just update your bash to
shell/***@4.0.28,5.11-0.151.1.9:20140117T202904Z .
--
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department
Alexander Pyhalov
2014-10-13 13:20:27 UTC
Permalink
Post by Alexander Pyhalov
Hello.
Jon Tibble has just pushed updated bash package with recent security
fixes to OI /dev a9. Just update your bash to
Sorry, you want more fresh version -
shell/***@4.0.28,5.11-0.151.1.9:20141013T104806Z
--
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department
Ron Dawson
2014-10-13 17:03:27 UTC
Permalink
Thanks for this!
Post by Alexander Pyhalov
Hello.
Jon Tibble has just pushed updated bash package with recent security fixes
.
--
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department
_______________________________________________
openindiana-discuss mailing list
http://openindiana.org/mailman/listinfo/openindiana-discuss
Carl Brewer
2014-10-14 02:33:34 UTC
Permalink
Post by Alexander Pyhalov
Hello.
Jon Tibble has just pushed updated bash package with recent security
fixes to OI /dev a9. Just update your bash to
Any chance that the same could be done for a8? I can't get to a9 - it
always fails to upgrade for me.
Dmitry Kozhinov
2014-10-14 15:51:32 UTC
Permalink
Thanks, Jon!
This makes me really happy with OI.
Actually this small advancement in OI /dev a9 makes me happier than all
great advancements in /hipster.

Regards,
Dmitry.
Post by Alexander Pyhalov
Jon Tibble has just pushed updated bash package with recent security
fixes to OI /dev a9.
o***@out-side.nl
2014-10-14 19:14:00 UTC
Permalink
Thanks from me too!

Thanks to all who keep OI alive!

-----Oorspronkelijk bericht-----
Van: Dmitry Kozhinov [mailto:***@desktopfay.com]
Verzonden: dinsdag 14 oktober 2014 17:52
Aan: openindiana-***@openindiana.org
Onderwerp: Re: [OpenIndiana-discuss] Bash bug issue

Thanks, Jon!
This makes me really happy with OI.
Actually this small advancement in OI /dev a9 makes me happier than all great advancements in /hipster.

Regards,
Dmitry.
Post by Alexander Pyhalov
Jon Tibble has just pushed updated bash package with recent security
fixes to OI /dev a9.
Continue reading on narkive:
Loading...