Re: Possibly Bash explot
hi, I cannot replicate this in anyway, I just created 1024 functions and then ran unset -f in a while [ 1 ]; do done; loop on the very same bash version but on earlier version of darwin, and everything seems fine. Could you please provide the exact code that triggers the problem, together with a description of how you are running it? cheers, pg On 22 Apr 2016, at 01:12, Nikolay Kolev wrote: > Basically, after doing a bunch of unset -f, I can crash Bash, version GNU > bash, version 4.3.42(1)-release (x86_64-apple-darwin15.0.0), which could > possibly be an attack vector. Here's the info from /var/log/system.log > > Apr 21 15:45:00 NikolayKolev-mac iTerm2[87962]: > ReceiveMessageAndFileDescriptor > Apr 21 15:45:00 NikolayKolev-mac iTerm2[87962]: calling recvmsg... > Apr 21 15:45:00 NikolayKolev-mac iTerm2-Server[87965]: Installing SIGHUP > handler. > Apr 21 15:45:00 NikolayKolev-mac iTerm2-Server[87965]: Installing SIGCHLD > handler. > Apr 21 15:45:00 NikolayKolev-mac iTerm2-Server[87965]: Unblocking SIGCHLD. > Apr 21 15:45:00 NikolayKolev-mac iTerm2-Server[87965]: Sending file > descriptor and waiting on initial connection > Apr 21 15:45:00 NikolayKolev-mac iTerm2-Server[87965]: send master fd and > child pid 87966 > Apr 21 15:45:00 NikolayKolev-mac iTerm2-Server[87965]: All done. Waiting for > client to disconnect or child to die. > Apr 21 15:45:00 NikolayKolev-mac iTerm2-Server[87965]: Calling select... > Apr 21 15:45:00 NikolayKolev-mac iTerm2[87962]: recvmsg returned 4, errno=n/a > Apr 21 15:45:00 NikolayKolev-mac iTerm2[87962]: recvmsg returned 4 > Apr 21 15:45:00 NikolayKolev-mac iTerm2[87962]: Got a fd > Apr 21 15:45:00 NikolayKolev-mac iTerm2[87962]: Return 4 > Apr 21 15:45:00 NikolayKolev-mac login[87966]: USER_PROCESS: 87966 ttys000 > Apr 21 15:45:07 NikolayKolev-mac -bash[87967]: -bash(87967,0x7fff79c34000) > malloc: *** error for object 0x7: pointer being freed was not allocated > *** set a breakpoint in malloc_error_break to debug > Apr 21 15:45:07 NikolayKolev-mac diagnosticd[71728]: error evaluating process > info - pid: 87967, punique: 187665 > Apr 21 15:45:07 NikolayKolev-mac login[87966]: DEAD_PROCESS: 87966 ttys000 > Apr 21 15:45:07 NikolayKolev-mac iTerm2-Server[87965]: select returned -1, > error = Interrupted system call > Apr 21 15:45:07 NikolayKolev-mac iTerm2-Server[87965]: Calling select... > Apr 21 15:45:07 NikolayKolev-mac iTerm2-Server[87965]: select returned 1, > error = Interrupted system call > Apr 21 15:45:07 NikolayKolev-mac iTerm2-Server[87965]: select returned. child > dead=2, connection closed=0 > Apr 21 15:45:07 NikolayKolev-mac iTerm2-Server[87965]: Connection closed. > Apr 21 15:45:07 NikolayKolev-mac iTerm2-Server[87965]: Unlink > /var/tmp/iTerm2.socket.87965 > Apr 21 15:45:07 NikolayKolev-mac iTerm2[87962]: File descriptor server exited > with status 0 > Apr 21 15:45:07 NikolayKolev-mac ReportCrash[87670]: Saved crash report for > bash[87967] version 0 to > /Users/NikolayKolev/Library/Logs/DiagnosticReports/bash_2016-04-21-154507_NikolayKolev-mac.crash
Re: history separates >| and 2>&1 tokens when recalled with !*
hi, yes, this happens here: lib/readline/histexpand.c:1406 result[offset++] = ' '; pg On 22 Apr 2016, at 01:28, idal...@home.idallen.ca wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL > -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2 > -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall > uname output: Linux idallen-oak 4.2.0-35-generic #40-Ubuntu SMP Tue Mar 15 > 22:15:45 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 4.3 > Patch Level: 42 > Release Status: release > > Description: > The history recall !* incorrectly pulls apart the >| and 2>&1 > words, making them useless. > > Repeat-By: > bash-4.3$ date >| /tmp/i > bash-4.3$ who !* > who > | /tmp/i > bash: syntax error near unexpected token `|' > > bash-4.3$ date 2>&1 > Thu Apr 21 19:24:46 EDT 2016 > bash-4.3$ echo !* > echo 2 >& 1 > 2 >
Re: history separates >| and 2>&1 tokens when recalled with !*
Hi,
It is a history_tokenize_word problem, please consider the following:
diff --git a/lib/readline/histexpand.c b/lib/readline/histexpand.c
index fdecebc..ca4b4c8 100644
--- a/lib/readline/histexpand.c
+++ b/lib/readline/histexpand.c
@@ -1447,7 +1447,8 @@ history_tokenize_word (string, ind)
return i;
}
else if ((peek == '&' && (string[i] == '>' || string[i] == '<')) ||
- (peek == '>' && string[i] == '&'))
+ (peek == '>' && string[i] == '&') ||
+ (peek == '|' && string[i] == '>'))
{
i += 2;
return i;
cheers,
pg
On 22 Apr 2016, at 01:28, idal...@home.idallen.ca wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
> -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2
> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall
> uname output: Linux idallen-oak 4.2.0-35-generic #40-Ubuntu SMP Tue Mar 15
> 22:15:45 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 4.3
> Patch Level: 42
> Release Status: release
>
> Description:
> The history recall !* incorrectly pulls apart the >| and 2>&1
> words, making them useless.
>
> Repeat-By:
> bash-4.3$ date >| /tmp/i
> bash-4.3$ who !*
> who > | /tmp/i
> bash: syntax error near unexpected token `|'
>
> bash-4.3$ date 2>&1
> Thu Apr 21 19:24:46 EDT 2016
> bash-4.3$ echo !*
> echo 2 >& 1
> 2
>
Re: compgen -A arrayvar does not include associative arrays
On 4/21/16 3:21 PM, Grisha Levit wrote:
> $ echo ${BASH_CMDS@a}; compgen -A arrayvar BASH_CMDS; echo $?
> A
> 1
>
> The description doesn't specify that the output is limited to indexed
> arrays only and it would be nice to have associative array variables
> included as well.
I will add something for associative arrays in a future bash version.
I'm going to spend time wrapping up bash-4.4/readline-7.0.
--
``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: Possibly Bash explot
On 4/21/16 7:12 PM, Nikolay Kolev wrote: > Basically, after doing a bunch of unset -f, I can crash Bash, version GNU > bash, version 4.3.42(1)-release (x86_64-apple-darwin15.0.0), which could > possibly be an attack vector. Here's the info from /var/log/system.log It's unlikely that this is an exploit, but if you can reproduce it, it would good to fix. 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: Possibly Bash explot
Well, you never know. It crashes consistently - I will try to create a reproducible code snippet for you. On Fri, Apr 22, 2016 at 8:06 AM, Chet Ramey wrote: > On 4/21/16 7:12 PM, Nikolay Kolev wrote: > > Basically, after doing a bunch of unset -f, I can crash Bash, version GNU > > bash, version 4.3.42(1)-release (x86_64-apple-darwin15.0.0), which could > > possibly be an attack vector. Here's the info from /var/log/system.log > > It's unlikely that this is an exploit, but if you can reproduce it, it > would good to fix. > > Chet > > -- > ``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: Bug in syntax checking causes unintended running of a function
On 4/21/16 3:40 AM, dnade@orange.com wrote: > I think the shellshock mitigations have blocked the injection from happening. > > Do you think these should/could be applied to all function definitions? That's what the posix-mode behavior of abandoning the entire script does. -- ``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: completion-prefix-display-length doesn't check for common prefix
On 4/21/16 2:42 PM, Grisha Levit wrote:
> f() { COMPREPLY=(aa bb cc); }
> complete -F f f
> bind 'set completion-prefix-display-length 2'
>
> $ f [TAB][TAB]
> ...aa ...bb ...cc
>
> None of the completion entries share a common prefix, though the docs
> suggest that only common prefixes are removed:
Bash-4.4 doesn't do this.
> On a related note, colored-completion-prefix has no effect if
> completion-prefix-display-length is greater than 0.
Yes, the current implementation prioritizes completion-prefix-display-length
over colored-completion-prefix
--
``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: Scripts passed into "-c" with an embedded newline won't execute trap if last command fails
On 4/21/16 12:48 PM, Brian Vandenberg wrote:
> Description:
>
> I ran into this issue while experimenting with gnu make and .ONESHELL.
> I've boiled the issue down to the following simple example:
>
> $ newline=$'\n'
> $ bash -e -c "trap 'echo handler' INT ERR;/bin/true; sleep 2;
> ${newline}/bin/false"
>
> It will successfully trap if I do the following:
>
> * hit ^C during the sleep
> * use "false" instead of "/bin/false" because that'll use a builtin
> * trap on EXIT instead
> * remove the newline
> * add another command after "/bin/false"
> * add another command before "/bin/false" without a newline after it
>
> If I replace "/bin/false" with a sleep then hit ^C then the INT trap also
> won't execute.
Thanks for the report. A variant of your suggestion will be in the next
release of bash.
(As an aside, many shells optimize the fork out to the extent they won't
execute the trap if you use sleep as the last command and send the shell
a SIGINT.)
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: history separates >| and 2>&1 tokens when recalled with !*
On 4/22/16 5:24 AM, Piotr Grzybowski wrote: > Hi, > > It is a history_tokenize_word problem, please consider the following: Yes, that's a good fix. There's an uncomfortable amount of knowledge of shell syntax in that function. 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/
