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 earli

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 histor

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'

Re: Cannot build bash-4.2 with Patch 53

On 10/10/14, 2:02 PM, TODD TRIMMER wrote: > 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 rebu

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, Oc

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: >

Re: Testing for Shellshock ... combinatorics and latest(Shellshock) Bash Vulnerability...(attn: Chet Ramey)

2014-10-10 09:04:10 -0600, Eric Blake: > On 10/10/2014 08:55 AM, Stephane Chazelas wrote: > > > 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. > > For the record, there are vulnera

Re: Testing for Shellshock ... combinatorics and latest(Shellshock) Bash Vulnerability...(attn: Chet Ramey)

On 10/10/2014 08:55 AM, Stephane Chazelas wrote: > 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. For the record, there are vulnerable shell scripts in the wild that fail to sanitize t

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[$(echo>&2 vulnerable)]'". > > Sure, and that's documented, inten

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:

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

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, r

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

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

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_l

Re: Random loss of bash history

On Fri, Oct 10, 2014 at 11:40 AM, Linda Walsh 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 ke

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 informa

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 combina

Re: [RFC] Logically composable variant of errexit

2014-10-10 8:38 GMT+02:00 Dan Douglas : > 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. Th

Re: [RFC] Logically composable variant of errexit

2014-10-10 3:29 GMT+02:00 Chet Ramey : > 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,

Re: umask --help

On 10 Oct 2014 01:25, "Chet Ramey" 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. > > > >

Re: Random loss of bash history

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