Re: [RFC] Logically composable variant of errexit
I would still propose that a simple and powerful way to extend Bash with exception handling would be to extend the ERR trap by passing it some metadata about the type and location of the exception incurred so that it can be handled by user code. This proposal allows us to largely avoid having to answer the question of when and where does it make sense for this to get triggered? for the user. It might require a new type of trap that just fires on anything that returns false or fails so that the user handler can choose what to do about it in various contexts. A more ambitious proposal might be to try cloning zsh's try/catch. It would be familiar to programmers and of course having a pre-existing implementation is a plus. try/catch is probably more intrusive than my first proposal due to the additional keywords and control flow changes. -- Dan Douglas
Re: umask --help
On 10 Oct 2014 01:25, Chet Ramey chet.ra...@case.edu wrote: On 10/9/14, 3:05 PM, Notes Jonny wrote: If and when it happens, it will show up in the devel git branch on savannah. Chet Thank you for your reply. I understand that requests can't be implemented immediately. Is there anything I could do to get this implemented? Eg. I would offer to pay £100 for an engineer to complete the updates. Did you check the devel git branch on savannah? :-) The changes went in in early September. Fantastic. Thanks :-) Jonny
Re: [RFC] Logically composable variant of errexit
2014-10-10 3:29 GMT+02:00 Chet Ramey chet.ra...@case.edu:
What does logically composable mean in this context?
I would like the hypothetical errfail option to:
* Behave like errexit at the top level (outside of functions).
* Be inherited by functions, subshells, and command substitution.
* Inside functions, it should trigger like errexit would outside of
functions, no matter how the function is called.
It should return instead of exiting, though.
With errexit, you get vastly different results from functions depending
on how the functions are called, for example,
foo() {
echo foo: top
false
echo foo: bottom
}
set -o errexit
# bottom of foo reached:
if foo; then
echo success # reached
fi
# bottom of foo not reached:
foo
With errfail, foo:bottom and success would not be reached.
Command substitutions would continue to behave as basic commands
do with respect to control flow: inside functions, a failure would cause
the function to return; outside of functions, the script would exit.
Thanks,
Andreas
Re: [RFC] Logically composable variant of errexit
2014-10-10 8:38 GMT+02:00 Dan Douglas orm...@gmail.com: I would still propose that a simple and powerful way to extend Bash with exception handling would be to extend the ERR trap by passing it some metadata about the type and location of the exception incurred so that it can be handled by user code. This proposal allows us to largely avoid having to answer the question of when and where does it make sense for this to get triggered? for the user. It might require a new type of trap that just fires on anything that returns false or fails so that the user handler can choose what to do about it in various contexts. Well, currently, the ERR trap only triggers when errexit would trigger, so another type of trap would certainly be needed. I don't think it's reasonable to expect from users to use trigger tricks to get basic error handling working in a sane way, though; this should be built in and trivial to activate. Thanks, Andreas
Re: Testing for Shellshock ... combinatorics and latest(Shellshock) Bash Vulnerability...(attn: Chet Ramey)
2014-10-09 21:35:09 -0400, Chet Ramey: On 10/9/14, 6:06 PM, Pádraig Brady wrote: On 10/09/2014 08:46 PM, Rick Karcich (rkarcich) wrote: Hello Chet, Re: testing for Shellshock... would like your feedback... specifically, regarding the possibility of human-directed combinatorial testing to find this Bash vulnerability... Sounds like how Michal Zalewski found the related CVE-2014-6278 http://lcamtuf.blogspot.ie/2014/10/bash-bug-how-we-finally-cracked.html That's a promising approach. I asked Michal to continue running the fuzzer against the patched, but he did not respond to that yet. [...] What's the point? That would be wasted effort IMO. Who cares if bash does something unexpected on incorrect input as long as it's not exploitable? The problem here was bash interpreting untrusted input. That has been fixed by stopping the parser from being exposed to untrusted input. Now bugs in the parser are only relevant if they affect functionality, that is, bash behaving the wrong way on valid input (code) and fuzzers are not likely to help much there. From that point of view, all the CVEs related to shellshock are non-bugs or very insignificant ones once the parser is no longer exposed. From a security point of view, there are things in bash and other shells that are far more inportant to look at than what it does on incorrect code: when it deals with other forms of untrusted input. One thing for instance and that also affects some other shells are like: bash -c '(( XDG_VTNR 7 )) That allows arbitrary code execution (and can't easily be fixed without breaking backward compatibility). Try with export XDG_VTNR='a[$(echo2 vulnerable)]'. How do you fuzz-test for that? You can't really until you've identified the problem already (that the arithmetic parsing has side effects (here expands cmdsubst inside arrays, but XFG_VTNR='PATH=1' could be as much of a problem). Without breaking backward compatibility, the best way to address it is document it: always sanitize external input before using them in arithmetic context. -- Stephane
CVE-2014-7187
Hi,
Bash 4.3 after patch 30 is still vulnerable for shellshock CVE-2014-7187.
(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
Probably you know that, but better to have more than less information.
Thanks, Wojtek
Re: Random loss of bash history
On Fri, Oct 10, 2014 at 11:40 AM, Linda Walsh b...@tlinx.org wrote: You DID read the release notes and changes from 4.2-4.3. Someone had the bright idea that .. in 4.2, '0' meant no limit in history (in bash and readline)... but in 4.3, '0' means 0 and throw away history while negative values mean keep it all. Perhaps you were hit by this brilliant new feature -- no doubt a new POSIX blessing. Your ironic stance won't help your case. Especially when what you describe is not true, 0 in 4.2 means 0. $ HISTSIZE=10 $ echo $BASH_VERSION 4.2.53(1)-release $ history 999 PS1=\$\ 1000 HIST_SIZE=10 1001 echo $BASH_VERSION 1002 history $ HISTSIZE=0 $ history $
Re: CVE-2014-7187
On 10/10/14, 4:03 AM, Nabiałek, Wojciech wrote:
Hi,
Bash 4.3 after patch 30 is still vulnerable for shellshock CVE-2014-7187.
No, it's not.
(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
I'm curious about what you think this demonstrates, but in the meantime:
$ ./bash --version
GNU bash, version 4.3.30(2)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ (for x in {1..200} ; do echo for x$x in ; do :; done; for x in {1..200}
; do echo done ; done) | ./bash
$ echo $?
0
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: CVE-2014-7187
Thanks for quick reply
Difference is in version number, mine is 4.3.30(3), your 4.3.30(2)
[root@e-mail wojtek]# bash --version
GNU bash, version 4.3.30(3)-release (i686-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
[root@e-mail wojtek]# (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
bash: line 2: `x{1..200}': not a valid identifier
CVE-2014-7187 vulnerable, word_lineno
This code is not mine, refer to:
http://stevejenkins.com/blog/2014/09/how-to-manually-update-bash-to-patch-shellshock-bug-on-older-fedora-based-systems/
Exploit 5.
The standard version of shellshock was ignored by me as hard to use for real
remote attack. It was very short time to see I was wrong, so this time I want
to be sure :)
Regards, Wojtek
-Original Message-
From: Chet Ramey [mailto:chet.ra...@case.edu]
Sent: Friday, October 10, 2014 3:37 PM
To: Nabiałek, Wojciech; bug-bash@gnu.org
Cc: chet.ra...@case.edu
Subject: Re: CVE-2014-7187
On 10/10/14, 4:03 AM, Nabiałek, Wojciech wrote:
Hi,
Bash 4.3 after patch 30 is still vulnerable for shellshock CVE-2014-7187.
No, it's not.
(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
I'm curious about what you think this demonstrates, but in the meantime:
$ ./bash --version
GNU bash, version 4.3.30(2)-release (x86_64-unknown-linux-gnu) Copyright (C)
2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ (for x in {1..200} ; do echo for x$x in ; do :; done; for x in {1..200} ;
do echo done ; done) | ./bash $ echo $?
0
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: CVE-2014-7187
On Fri, Oct 10, 2014 at 02:00:41PM +, Nabia??ek, Wojciech wrote:
Difference is in version number, mine is 4.3.30(3), your 4.3.30(2)
The number in parentheses is simply how many times Bash has been compiled
in the current source tree. If you apply a new patch and run make
again, the number goes up. It's not actually a different version.
[root@e-mail wojtek]# (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
bash: line 2: `x{1..200}': not a valid identifier
CVE-2014-7187 vulnerable, word_lineno
Your interactive shell is not Bash (or it's a very OLD Bash), so the
{1..200} was not expanded. That's why this test failed.
Run it again from within Bash.
And for god's sake, don't do vulnerability testing as root.
Re: Testing for Shellshock ... combinatorics and latest(Shellshock) Bash Vulnerability...(attn: Chet Ramey)
On 10/10/14, 5:40 AM, Stephane Chazelas wrote: 2014-10-09 21:35:09 -0400, Chet Ramey: On 10/9/14, 6:06 PM, Pádraig Brady wrote: On 10/09/2014 08:46 PM, Rick Karcich (rkarcich) wrote: Hello Chet, Re: testing for Shellshock... would like your feedback... specifically, regarding the possibility of human-directed combinatorial testing to find this Bash vulnerability... Sounds like how Michal Zalewski found the related CVE-2014-6278 http://lcamtuf.blogspot.ie/2014/10/bash-bug-how-we-finally-cracked.html That's a promising approach. I asked Michal to continue running the fuzzer against the patched, but he did not respond to that yet. [...] What's the point? That would be wasted effort IMO. It depends on your goals. Who cares if bash does something unexpected on incorrect input as long as it's not exploitable? I do, if it can cause a crash. The problem here was bash interpreting untrusted input. That has been fixed by stopping the parser from being exposed to untrusted input. Now bugs in the parser are only relevant if they affect functionality, that is, bash behaving the wrong way on valid input (code) and fuzzers are not likely to help much there. From that point of view, all the CVEs related to shellshock are non-bugs or very insignificant ones once the parser is no longer exposed. I agree that the important thing is that the parser isn't exposed in the way it was, and that the reports post-patch 27 are simple shell bugs. However, I'm interested in shell bugs. From a security point of view, there are things in bash and other shells that are far more inportant to look at than what it does on incorrect code: when it deals with other forms of untrusted input. One thing for instance and that also affects some other shells are like: bash -c '(( XDG_VTNR 7 )) That allows arbitrary code execution (and can't easily be fixed without breaking backward compatibility). Try with export XDG_VTNR='a[$(echo2 vulnerable)]'. Sure, and that's documented, intended, and not unique. 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: CVE-2014-7187
On 10/10/14, 10:00 AM, Nabiałek, Wojciech wrote:
[root@e-mail wojtek]# (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
bash: line 2: `x{1..200}': not a valid identifier
CVE-2014-7187 vulnerable, word_lineno
Yeah, that's a flawed test. I'm sure the author never thought that the
test would be run by a shell that didn't implement brace expansion, but
you managed 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: CVE-2014-7187
On 10/10/2014 08:00 AM, Nabiałek, Wojciech wrote:
This code is not mine, refer to:
http://stevejenkins.com/blog/2014/09/how-to-manually-update-bash-to-patch-shellshock-bug-on-older-fedora-based-systems/
Exploit 5.
That blog is wrong. Here's how you test if your shell is vulnerable:
probe='() { echo vulnerable; }' bash -c probe
If that outputs:
bash: probe: command not found
your shell is secure (and bash 4.3.30 has this behavior). If it outputs:
vulnerable
then your shell still needs a patch. Remember, bash 4.3.27 was THE
patch that matters. There were six patches in a row, five of them (25,
26, 28, 29, and 30) addressed 6 different parser bugs (all 6 of which
were assigned a CVE number), but none of those five solve the
vulnerability. ONLY patch 27 (the one with no corresponding CVE)
actually solves the vulnerability. The vulnerability was that attackers
could abuse the contents of environment variables to cause the parser to
be executed when it should not be.
Some of the sites purporting to have tests for the various
vulnerabilities are confusing the two issues - there's a difference
between a parser bug (and we've patched 6 of them so far) and an
exploitable vulnerability (a single patch solved that, AND prevents even
yet-to-be-discovered parser bugs from also being vulnerabilities). In
particular, the code you quoted did not have ANY mention of an
environment variable; therefore, it CANNOT be testing the vulnerability,
only whether a parser bug is present.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Testing for Shellshock ... combinatorics and latest(Shellshock) Bash Vulnerability...(attn: Chet Ramey)
2014-10-10 10:17:40 -0400, Chet Ramey: [...] bash -c '(( XDG_VTNR 7 )) That allows arbitrary code execution (and can't easily be fixed without breaking backward compatibility). Try with export XDG_VTNR='a[$(echo2 vulnerable)]'. Sure, and that's documented, intended, and not unique. [...] Is it really intended and documented that cmdsubst be performed there? AFAICT, it's not useful and not consistent. a='$(echo 1+1)' bash -c 'echo $((a))' Doesn't work. So why would these work a='b[$(echo 1+1)]' bash -c 'echo $((a)) Or a='$(echo 1+1)' bash -c 'echo $((b[a]))' then? Where is it documented that variable, arithmetic, command, tilde and process substitution are performed in array subscripts in indirectly evaluated arithmetic expressions? I can accept: echo $((a[$(echo 1+1)])) or: a[$(echo 1+1)]=2 being accepted intentionaly. But I can't see why the content of a variable should be interpreted as anything else than an arithmetic expression just because it's in an array subscript. -- Stephane
Re: [RFC] Logically composable variant of errexit
On Andreas Grünbacher wrote:
With errexit, you get vastly different results from functions depending
on how the functions are called, for example,
foo() {
echo foo: top
false
echo foo: bottom
}
set -o errexit
# bottom of foo reached:
if foo; then
echo success # reached
fi
# bottom of foo not reached:
foo
With errfail, foo:bottom and success would not be reached.
I disagree. IMHO the function should have the errfail value of its
parent scope at the time of its definition.
Otherwise, a function expecting to ignore errors would mysteriously fail
in a script that set -o errexit, unaware that one of the commands it
calls is [shadowed by] a function.
Thus, you would have to put the set at the top for the behavior you expected.
Command substitutions would continue to behave as basic commands
do with respect to control flow: inside functions, a failure would cause
the function to return; outside of functions, the script would exit.
+1
Re: Cannot build bash-4.2 with Patch 53
You're right. The y.tab.[ch] files never got rebuilt. They still had the same timestamps from the base archive of 4.2. Renaming them forced a rebuild, which had significant diffs. Is there a flag that can be sent to configure or make to force a rebuild? BTW, bison was already installed. On Thu, Oct 9, 2014 at 11:47 PM, Steve Simmons s...@umich.edu wrote: On Oct 9, 2014, at 9:34 PM, TODD TRIMMER todd.trim...@gmail.com wrote: If I compile from bash-4.2 from source, cumulatively applying patches through 52, things work fine. If I start from scratch and apply through 53, it errors out: gcc -L.. . . ./builtins/libbuiltins.a(evalstring.o): In function `parse_and_execute': /home/ttrimmer/depot/ext/bash/patch/src/builtins/evalstring.c:274: undefined reference to `parser_remaining_input' collect2: ld returned 1 exit status make: *** [bash] Error 1 I can see parser_remaining_input patched in parse.y and builtins/evalstring.c. However, it will not compile. Sounds like y.tab.[ch] never got (re)built from parse.y. Try renaming them to -old and give the 'make' command again. If you don't have yacc or bison, that'll fail. Get and install bison and try again.
Re: Random loss of bash history
I stand corrected... this isn't new. Still when such numbers often mean unlimited and negative ones are invalid, I see little or no utility in truncating someone's histfile to 0. If someone wanted to delete it, they would. Defaulting to truncation behavior on changing those controls to '0', serves little purpose other than to potentially wipe someone's history and keep it disabled -- when if that's really what they wanted, the'd just turn the option off. So, it's not a brilliant NEW feature. It's a brilliant design. Period. Happier? (Sitting corrected...;-) ) Pierre Gaston wrote: On Fri, Oct 10, 2014 at 11:40 AM, Linda Walsh b...@tlinx.org mailto:b...@tlinx.org wrote: You DID read the release notes and changes from 4.2-4.3. Someone had the bright idea that .. in 4.2, '0' meant no limit in history (in bash and readline)... but in 4.3, '0' means 0 and throw away history while negative values mean keep it all. Perhaps you were hit by this brilliant new feature -- no doubt a new POSIX blessing. Your ironic stance won't help your case. Especially when what you describe is not true, 0 in 4.2 means 0. $ HISTSIZE=10 $ echo $BASH_VERSION 4.2.53(1)-release $ history 999 PS1=\$\ 1000 HIST_SIZE=10 1001 echo $BASH_VERSION 1002 history $ HISTSIZE=0 $ history $
Re: Random loss of bash history
Your ironic stance won't help your case. Especially when what you describe is not true, 0 in 4.2 means 0. FWIW, in the 4.3 README, under differences from 4.2: n. Setting HISTSIZE to a value less than zero causes the history list to be unlimited (setting it 0 zero disables the history list). o. Setting HISTFILESIZE to a value less than zero causes the history file size to be unlimited (setting it to 0 causes the history file to be truncated to zero size). --- and that's why user's should be wary of reading release notes! ;-)
when was shellshock introduced
2014-09-12 15:56:44 -0400, Chet Ramey: [...] Importing exported function definitions was introduced in bash-1.13. [...] (bug-bash CCed). Hi Chet, I know that in the early day of the discovery, you came to the conclusion that shellshock was introduced in 1.13, mostly my fault for saying earlier that it was not in 1.05 or in the ChangeLog while it plainly was. When asked, you and I ended up spreading the word that it was introduced in 1.13 and there's now a lot of confusion in the news and FOSS and security communities around the actual date the bug was introduced (I've seen 1.03, 1.05, 1.13, 1.14, from the beginning... Mentioned). It was then discovered that the feature and vulnerability were indeed in 1.05 and the ChangeLog in there makes it clear when it was introduced: http://www.oldlinux.org/Linux.old/bin/old/bash-1.05/ChangeLog Fri Sep 1 18:52:08 1989 Brian Fox (bfox at aurel) * readline.c: rl_insert (). Optimized for large amounts of typeahead. Insert all insertable characters at once. * I update this too irregularly. Released 1.03. [...] Sat Aug 5 08:32:05 1989 Brian Fox (bfox at aurel) * variables.c: make_var_array (), initialize_shell_variables () Added exporting of functions. (I don't have access to the 1.03 source, but I've no reason to beleive it was any different than 1,05). Some discussions in gnu.bash.bug and comp.unix.questions (that one by you) around that time also mention the new feature. https://groups.google.com/d/msg/gnu.bash.bug/72jXoIWYsfE/jJqC-fjSh0wJ https://groups.google.com/d/msg/comp.unix.questions/LwsdchovzFY/qokUr2mfCboJ More at: http://thread.gmane.org/gmane.comp.security.oss.general/14177/focus=14181 http://www.dwheeler.com/essays/shellshock.html#timeline http://thread.gmane.org/gmane.comp.security.oss.general/14177/focus=14190 http://unix.stackexchange.com/questions/157381/when-was-the-shellshock-cve-2014-6271-7169-bug-introduced-and-what-is-the-pat/157495#157495 https://twitter.com/SChazelas/status/518316463225315328 The WikiPedia entry http://en.wikipedia.org/wiki/Shellshock_%28software_bug%29 got corrected at some point but then reverted for lack of authoritative information (not http://en.wikipedia.org/wiki/Bash_%28Unix_shell%29 though). For the sake of correctness, would you mind confirming here that the bug and feature were indeed introduced in August 1989 and first released in 1.03 in September that same year, so WikiPedia can have an authoritative source of information? Thanks, Stephane
