Re: 4.4 change in behavior from 4.3: how to catch unset when using ${#length}
On Fri, Oct 21, 2016 at 09:19:08PM -0700, L. A. Walsh wrote:
> Eduardo Bustamante wrote:
> >what's wrong with?:
> >echo ${#array[@]}
> Not when "-u" is set, which I often have on to help catch misspellings.
>
> set -u
> echo ${#array[@]}
> bash: array: unbound variable
See http://mywiki.wooledge.org/BashFAQ/112
set -u is almost as bad as set -e. It's a poorly implemented crutch
which breaks scripts that would otherwise work.
If you're going to file bug reports about your scripts breaking when
you use set -u, you should at least mention that in the initial bug
report.
Re: 4.4 change in behavior from 4.3: how to catch unset when using ${#length}
On 10/21/16 5:41 PM, L. A. Walsh wrote:
> On 4.3 and earlier, at least on arrays, one could have
> the illusion of this working w/o complaint -- and returning
> 0 when the array was 0-len or unset, or the array length,
> otherwise:
>
>
> echo ${#array[@]:-0}
>
> But I note it only seemed to work in arrays, and in 4.4 gets a
> syntax error:
>
> echo ${#array[@]:-0} bash: ${#array[@]:-0}: bad substitution
Because it is a syntax error, and if it were not it would be ambiguous.
The ${param:-word} word expansion takes a parameter, not another word
expansion, as the object to be expanded.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
for Chet Ramney in Born Againe
Hello developers. Few mounth ago microsoft released sources of Power Shell. Can u re:coded BASH for Power Shell features to fully intagrated with Linux enviroments for more dinamicly DE objects stuff usefull without terminal. Now i seen intagrated of thats kind on GTK tools and others,done any of this in interpreterr(BASH new version). go hard my friends.
Correction of CVE-2016-7543 is incomplete
Version: all (see note below) Hardware: all Operating system: Debian GNU Linux (but all should be affected) Compiler: gcc Hi In CVE-2016-7543 a problem was reported that it is possible to privilege escalate to root. The correction as seen here http://lists.gnu.org/archive/html/bug-bash/2016-10/msg9.html is not complete. Well it do prevent privilege escalation to root, but it is possible to escalate to any other user and that may be bad too. The problem has also been reported (by me) in Debian as you can see here: http://bugs.debian.org/841856 I have attached a tar file with exploit code. The exploit code is used like this: make sudo make root make test Test 1 is the exploit for CVE-2016-7543 Test 2 is the exploit for this problem Test 3 is just a reference test. The proposed patch essentially disable the whole PS4 variable support for all users (not only root as the patch was for CVE-2016-7543. Please let me know if you have a better idea on how to handle this. Version note: The attached correction is made on a 4.2 system with a patch for CVE-2016-7543. However it should apply on 4.4 as well. Let me know if you need any further details. Best regards // Ola -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comFolkebogatan 26\ | o...@debian.org 654 68 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- exploit.tar.gz Description: GNU Zip compressed data CVE-2016-7543-bug-841856-20161023.patch Description: Binary data
Re: bash history / ssh+sudo+reverse-i-search will execute the command found if the ssh process is killed
On 10/19/16 1:46 PM, Stein Arne Storslett wrote: > Bash Version: 4.2 > Patch Level: 46 > Release Status: release > > Description: > Bash history / reverse-i-search will execute the command found > if the ssh process is killed. > This happens with the combination of: > - ssh into server > - sudo su - > - reverse-i-search # +R > > I.e. a user in the middle of a bash reverse-i-search, and the > ssh process is killed > i.e. due to a network outage. > > This can be critical if the command in the search history is > something harmful or potentially unwanted, like a server shutdown > > The chain of events during the kill, and how the sub processes > are killed might be the cause here, but nevertheless no signal > should cause the bash history command to run. Part of this was fixed in bash-4.3, and the issue has been completely resolved in bash-4.4. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Correction of CVE-2016-7543 is incomplete
Quoting "Ola Lundqvist" : This is known. I "complained" at the time, as it can be seen here: https://lists.gnu.org/archive/html/bug-bash/2015-12/msg00112.html Version: all (see note below) Hardware: all Operating system: Debian GNU Linux (but all should be affected) Compiler: gcc Hi In CVE-2016-7543 a problem was reported that it is possible to privilege escalate to root. The correction as seen here http://lists.gnu.org/archive/html/bug-bash/2016-10/msg9.html is not complete. Well it do prevent privilege escalation to root, but it is possible to escalate to any other user and that may be bad too. The problem has also been reported (by me) in Debian as you can see here: http://bugs.debian.org/841856 I have attached a tar file with exploit code. The exploit code is used like this: make sudo make root make test Test 1 is the exploit for CVE-2016-7543 Test 2 is the exploit for this problem Test 3 is just a reference test. The proposed patch essentially disable the whole PS4 variable support for all users (not only root as the patch was for CVE-2016-7543. Please let me know if you have a better idea on how to handle this. Version note: The attached correction is made on a 4.2 system with a patch for CVE-2016-7543. However it should apply on 4.4 as well. Let me know if you need any further details. Best regards // Ola -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comFolkebogatan 26\ | o...@debian.org 654 68 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- This message was sent using IMP, the Internet Messaging Program.
[PATCH] multiline syslog patch
hi, attached a patch that builds on the existing "log interactive commands to syslog" bash feature (SYSLOG_HISTORY). This capability is used in some of our devices to be able to track which management operations were executed on them using bash (with appropriate legal information at login). This helps in troubleshooting. Due to privacy and security issues, as a general-purpose functionality on a generic multi-user system this is probably not something administrators want to enable. That's probably also the reason why in many Linux distros the capability is compiled out. Quickly googling the issues suggests an alternative solution defining an explicit bash DEBUG trap function that uses the "fc" command to query the last command and then log that. This is certainly one solution, but it seemed overly complex to invoke fc and a subsequent logging command to achieve this. Also traps can be easily overwritten by operators. Also there seem to be issues with the fc-in-DEBUG-trap approach creating repeating log entries if users press CTRL-C in the middle of entering a command. So building on the existing SYSLOG_HISTORY seemed a more reasonable approach. Anyway the attached patch builds on the existing logging-to-syslog capability (re-using the existing SYSLOG_HISTORY define) and is only compiled if this define is explicitly given, e.g., via "make CPPFLAGS=-DSYSLOG_HISTORY". It hooks into the DEBUG trap and only logs the complete command if the DEBUG trap code in bash is hit. This also means that multi-line commands are only logged in full when they are actually executed and not one-by-one for each line. The line-by-line logging had the issue that logs were generated even if the user did not finish the multi-line command and pressed CTRL-C, for example. Also the behavior is now to log the command again if the same command is executed again. Previously invoking the same command again was not logged. Also note that users can disable the logging, for example, by disabling history logging via "set +o history". So additional work is needed if someone would want to evolve this into fully-forced syslog logging. What do you think? Cheers, Thoralf syslog_multiline_4_4.patch Description: syslog_multiline_4_4.patch
Re: for Chet Ramney in Born Againe
On Mon, Oct 24, 2016 at 8:33 AM, Корень Зла wrote: > Can u re:coded BASH for Power Shell features to fully intagrated with Linux > enviroments Directly supporting features in a compatible way would not be easy. Powershell is a completely different language, and bash isn't yet implemented on the CLR. I'm working on the latter, but my compiler won't be ready for a while, and the focus is on bash compatibility, not powershell. If you're only interested in interoperating with powershell from bash without changing bash directly, you could write a bash plugin to have it host the CLR with libmono http://www.mono-project.com/docs/advanced/embedding/. That isn't usually very hard, though I haven't actually tried it with a bash loadable. Hope I understood your question.
Re: Correction of CVE-2016-7543 is incomplete
Hi Thank you for the information. Good to know that I'm not the only one that have seen this problem. One can of course argue that the attack vector is a little odd. That is a setuid binary making system. I thought system was safe enough, but now I have learnt otherwise. Anyway I do not think disabling PS4 variable would hurt much. Or do anyone see that it is useful to set to something else than +? Maybe we can allow PS4 to be expanded to some extent, but not allow it to be expanded to execute commands? // Ola On 24 October 2016 at 18:37, wrote: > Quoting "Ola Lundqvist" : > > This is known. > > I "complained" at the time, as it can be seen here: > https://lists.gnu.org/archive/html/bug-bash/2015-12/msg00112.html > > > > Version: all (see note below) >> Hardware: all >> Operating system: Debian GNU Linux (but all should be affected) >> Compiler: gcc >> >> Hi >> >> In CVE-2016-7543 a problem was reported that it is possible to privilege >> escalate to root. >> The correction as seen here >> http://lists.gnu.org/archive/html/bug-bash/2016-10/msg9.html >> is not complete. Well it do prevent privilege escalation to root, but it >> is >> possible to escalate to any other user and that may be bad too. >> >> The problem has also been reported (by me) in Debian as you can see here: >> http://bugs.debian.org/841856 >> >> I have attached a tar file with exploit code. The exploit code is used >> like >> this: >> make >> sudo make root >> make test >> >> Test 1 is the exploit for CVE-2016-7543 >> Test 2 is the exploit for this problem >> Test 3 is just a reference test. >> >> The proposed patch essentially disable the whole PS4 variable support for >> all users (not only root as the patch was for CVE-2016-7543. Please let me >> know if you have a better idea on how to handle this. >> >> Version note: The attached correction is made on a 4.2 system with a patch >> for CVE-2016-7543. >> However it should apply on 4.4 as well. >> >> Let me know if you need any further details. >> >> Best regards >> >> // Ola >> >> -- >> --- Inguza Technology AB --- MSc in Information Technology >> / o...@inguza.comFolkebogatan 26\ >> | o...@debian.org 654 68 KARLSTAD| >> | http://inguza.com/Mobile: +46 (0)70-332 1551 | >> \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / >> --- >> >> > > > > This message was sent using IMP, the Internet Messaging Program. > > -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comFolkebogatan 26\ | o...@debian.org 654 68 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: 4.4 change in behavior from 4.3: how to catch unset when using ${#length}
Chet Ramey wrote:
On 10/21/16 5:41 PM, L. A. Walsh wrote:
[previously] one could have the illusion of this working
w/o complaint -- and returning 0 when the array was 0-len
or unset, or the array length, otherwise:
echo ${#array[@]:-0}
But I note it only seemed to work in arrays, and in 4.4 gets a
syntax error:
echo ${#array[@]:-0} bash: ${#array[@]:-0}: bad substitution
Because it is a syntax error, and if it were not it would be ambiguous.
The ${param:-word} word expansion takes a parameter, not another word
expansion, as the object to be expanded.
I don't understand the ambiguity. If param= "#obj[@]", then it
is clear to me that the user wants the length of an array named "obj".
If it doesn't have the [@|*], then the user wants the # of characters
in "obj". It seems both cases have clearly defined meanings.
In either case, if the variable isn't set, or if array is unset, then
the length cannot be set. If the length is not set, the the text to the
right of the ':-' is substituted.
Alternatively, neither ${#unset} nor ${#unset[@]} should generate
errors (i.e. if the length operator is defined on "unset" variables, then
no error would be generated). However, if one has "undefined-warnings"
turned on, both of those trigger an undefined warning.
If one doesn't have the "undefined-warnings" turned on, then the
"#" operator says that the length of an undefined variable or array
is '0': a dubious result, unless one claims that the '#' "handles" an
undefined(unset) variable and returns its length as '0'.
If you want '#' to return '0' for undefined/unset objects (vars or
arrays),
then it shouldn't trigger the "-u: unset variable" exception -- in the same
way one can safely test those names with ${object:-} and not trigger
the "unset-variable exception".
Either way would work for me -- returning 0 and not triggering the
error,
or having "#" return "undef/unset" if used with an unset object which could
then be tested as part of a ${object:-} type expansion.
It seems the ambiguity results from the length operator not returning
results consistent with triggered "unset" errors, no?
Race in bash-4.3 'typeset'?
I have some code which evals a configuration file - but before doing so
attempts to validate the content. It does this by taking each potential
keyword from the file and then doing:
if typeset -p | grep -q "^declare -. ${var}$”; then
… to determine whether the keyword in question exists as a declared but unset
variable in the script.
However, I am seeing cases where the above incorrectly fails, or where
executing this line twice in immediate succession will fail on the first
invocation and then succeed on the second. This doesn’t happen every time, and
appears to be non-deterministic: running the entire script multiple times
sometimes results in an earlier failure, sometimes it continues succeeding for
many iterations more. Turning on xtrace or adding additional debug logging
does appear to prevent the problem from occurring, unfortunately.
Sometimes, with much less regularity, the above line actually fails with:
Re: Race in bash-4.3 'typeset'?
Op 25-10-16 om 00:42 schreef Stuart Shelton:
> Failing this, is there any alternative to ‘typeset’ to list a
> variable declared as local to a function but which has not yet been
> assigned a value?
Try simply testing the exit status of 'typeset -p' or 'declare -p'. If
the variable is not declared, it exits unsuccessfully.
if typeset -p "$var" >/dev/null 2>&1 && [[ ! -v $var ]]
then ...
As far as I can tell, this is not documented in 'help' or in the info
page, by the way. Perhaps it should be.
Also note that, while zsh and yash share this behaviour, ksh93 and
mksh/pdksh do not. If you want to be compatible with all the shells that
support 'typeset', you could do:
if [ -n "$(typeset -p "$var" 2>/dev/null)" ] &&
eval "[ -z \"\${var+s}\" ]"
then ...
which is slower because it uses a subshell.
HTH,
- M.
