Re: bash-2.05b-013 appears to not work
I guess that would help. I meant to include that in the initial mail,
but alas, running in 50K directions.
Locally we are using:
(for x in {1..200} ; do echo for x$x in ; do :; done; for x in
{1..200} ; do echo done ; done) | bash ||
echo CVE-2014-7187 vulnerable, word_lineno
If we run the test via ssh, it is showing patched, however locally is
still showing vulnerable.
Thanks Eric,
Dave
On 10/16/14, Chet Ramey chet.ra...@case.edu wrote:
On 10/16/14, 5:02 PM, Dave Kalaluhi wrote:
We have been compiling some of the older versions of bash to fix
vulnerabilities, and for the most, has been working.
However, when we patch the 013 patch for CVE-2014-7187, and run the
nested loop, it's still showing as vulnerable.
Has anyone else had a similiar experience?
Since the code that had the off-by-one error was not even in bash-2.05b,
I'm skeptical that it's vulnerable.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash-2.05b-013 appears to not work
On Fri, Oct 17, 2014 at 10:10:36AM -0400, Dave Kalaluhi wrote:
Locally we are using:
(for x in {1..200} ; do echo for x$x in ; do :; done; for x in
{1..200} ; do echo done ; done) | bash ||
echo CVE-2014-7187 vulnerable, word_lineno
As mentioned in previous emails on this topic, that test is NOT
correct for bash 2.05b because it uses the {1..200} syntax which
was not introduced until bash 3. Replace it with a C-style for
loop.
Re: bash-2.05b-013 appears to not work
Eric Blake ebl...@redhat.com writes:
The following is a better test for whether CVE-2014-7187 can be
exploited to remotely attack your system:
f='() { echo vulnerable; } bash -c f
Missing quote character.
f='() { echo vulnerable; }' bash -c f
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: Issue with Bash-4.3 Official Patch 27
No, I can't. $ foo%%=bar foo%%=bar: command not found Or better said not in the normal way $ set foo%%=bar -- Mit freundlichen Grüßen Lorenz Bucher TechConnect GmbH Im Auftrag der/on behalf of Rohde Schwarz GmbH Co. KG Postfach 80 14 69 • 81614 München Mühldorfstraße 15 • 81671 München Telefon:(089) 4129-15684 Mail: lorenz.bucher@rohde-schwarz.com Internet: www.rohde-schwarz.com Von:Chet Ramey chet.ra...@case.edu An: lorenz.bucher@rohde-schwarz.com, wool...@eeg.ccf.org, Kopie: bug-bash@gnu.org, Eduardo A. Bustamante López dual...@gmail.com, chet.ra...@case.edu Datum: 10/16/2014 03:09 PM Betreff:Re: Issue with Bash-4.3 Official Patch 27 Gesendet von: bug-bash-bounces+lorenz.bucher.ext=rohde-schwarz@gnu.org On 10/15/14, 1:49 PM, lorenz.bucher@rohde-schwarz.com wrote: But anyway. In my opinion I should trust a shell not violating their own rules and be able to import their own variables. That's not the issue. The shell can import variables like that just fine, as evidenced by exported functions actually working. The question is whether or not `export' lets you set and export non-identifiers. It does and should not. So the % character should be allowed to be used in variable names. No, shell variable names should continue to be shell identifiers. You can already use `%' (any character, really) in environment variable names. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/
Re: bash-2.05b-013 appears to not work
Awesome - Thanks everyone for the help! I will forward these responses
on to the security group. But again, Thank you everyone!!!
-Dave
On 10/17/14, Andreas Schwab sch...@linux-m68k.org wrote:
Eric Blake ebl...@redhat.com writes:
The following is a better test for whether CVE-2014-7187 can be
exploited to remotely attack your system:
f='() { echo vulnerable; } bash -c f
Missing quote character.
f='() { echo vulnerable; }' bash -c f
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: commands do not ignore TSTP if TSTP ignored already
On 10/16/14, 12:38 AM, idal...@idallen.ca wrote: Bash Version: 4.2 Patch Level: 25 Release Status: release Description: If a bash shell script starts up with TSTP ignored, commands run by that script will not ignore TSTP, even if you set a trap in the script to ignore TSTP. If the script starts up with TSTP not ignored, then the trap to ignore TSTP works fine. Thanks for the report. This will be fixed in the next release of bash. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Issue with Bash-4.3 Official Patch 27
On 10/16/14, 4:37 PM, Geir Hauge wrote: Regardless though, shouldn't source (declare -xp) work whether or not the environment contains invalid identifiers? It doesn't at present: $ env %=% bash -c 'echo $BASH_VERSION; source (declare -xp)' 4.3.30(1)-release /dev/fd/63: line 1: declare: `%': not a valid identifier Isn't declare -p output meant to be reusable as shell input? Yeah. Names that get imported from the environment, but which are not valid shell identifiers, should not leak into declare -p output. I made that change about ten days ago, and it will be in the next release of bash. The current warning is an annoyance but otherwise doesn't impact anything. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Issue with Bash-4.3 Official Patch 27
On 10/17/14, 11:22 AM, lorenz.bucher@rohde-schwarz.com wrote: No, I can't. $ foo%%=bar foo%%=bar: command not found You just demonstrated what I wrote: No, shell variable names should continue to be shell identifiers. You can already use `%' (any character, really) in environment variable names. You attempted to create a shell variable with a name that isn't a valid shell identifier, and it didn't work. You can use `env' or equivalent to place arbitrary strings into the environment, but you can't use the shell to do it. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Issue with Bash-4.3 Official Patch 27
On 10/17/14, 11:34 AM, Greg Wooledge wrote: 3) Everything else. These are ignored. Not quite. Bash saves them and adds them to the environment it passes to the external commands it invokes. Bash is transparent with respect to environment variables it doesn't handle. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
