Re: Race in bash-4.3 'typeset'?

[Martijn Dekker]

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.

Race in bash-4.3 'typeset'?

[Stuart Shelton]

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: 4.4 change in behavior from 4.3: how to catch unset when using ${#length}

[L. A. Walsh]

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?

Re: Correction of CVE-2016-7543 is incomplete

[Ola Lundqvist]

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: for Chet Ramney in Born Againe

[Dan Douglas]

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.

[PATCH] multiline syslog patch

[Czichy, Thoralf (Nokia - FI/Espoo)]

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: Correction of CVE-2016-7543 is incomplete

[up201407890]

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.

Re: bash history / ssh+sudo+reverse-i-search will execute the command found if the ssh process is killed

[Chet Ramey]

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/

Correction of CVE-2016-7543 is incomplete

[Ola Lundqvist]

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

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.

Re: 4.4 change in behavior from 4.3: how to catch unset when using ${#length}

[Chet Ramey]

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/

Re: 4.4 change in behavior from 4.3: how to catch unset when using ${#length}

[Greg Wooledge]

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.