Re: Bash-4.3 Official Patch 27
I'd send it to your vendor. If appropriate they can send it upstream.
Chet
I've sent this to a debian person following advice on the Arch list I initially
asked. I probably won't get used as I imagine they'll want a more general
approach to all the various versions of the bash fixes. Our ubuntu servers are
showing .025 right now and have environments with BASH_FUNC_name()='()
{}' in them. Luckily I'm not using at on any of them and cron seems
unaffected.
Thanks for all the hard work on these panic issues.
hashlib.c add NULL check for string parameter
Hello I noticed hash_search() did not check if string parameter was non-NULL. Please find attached a patch for this. There are others similar. So I will wait and see if you are happy with these kind of changes, and if so I can submit more when I have analysed. I'm not on this list, so please include my email address in any replies. Regards, Jonny hashlib_c.patch Description: Binary data
Re: hashlib.c add NULL check for string parameter
On 9/29/14, 8:22 AM, Notes Jonny wrote: Hello I noticed hash_search() did not check if string parameter was non-NULL. Please find attached a patch for this. It's the caller's responsibility to ensure that the string passed to hash_search is non-NULL. 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: [Help-bash] make error
On Mon, Sep 29, 2014 at 05:11:52PM +0800, ??? wrote: /bin/echo: line 1: Mon: command not found make: *** [.build] Error 127 This is just a guess, but it looks like you tried to build bash in a shell where you had previously been testing for shellshock-type vulnerabilities, and you have a contaminated environment. If this is true, then the fix would be for you to exit out of this shell, launch a new one (without contaminants), and try again.
Re: Bash-4.3 Official Patch 27
2014-09-27 22:48:44 -0600, Eric Blake:
On 09/27/2014 08:50 PM, Chet Ramey wrote:
BASH PATCH REPORT
=
/* Don't import function names that are invalid identifiers from the
environment, though we still allow them to be defined as shell
variables. */
! if (absolute_program (tname) == 0 (posixly_correct == 0 ||
legal_identifier (tname)))
! parse_and_execute (temp_string, tname,
SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
This patch forbids importing function names containing '/' (yay!), and
we already established that bash has never been able to properly import
functions with names containing '='. But I'm assuming there will need
to be a followup patch to actually reject the attempt to create such
function names (that is, bash -c 'a/b () { echo oops; }; a/b' should
issue an error message instead of printing oops), so that we do not
have the confusing situation of being unable to pass all permitted
function names through an export/import cycle.
[...]
I'd say it's unfortunate that the fix for CVE-2014-6271 removes
the support for exporting functions with slash in their name.
functions share the same namespace as other commands (and not as
variables which is also why the original implementation of
function exports was flawed/inconsistent), so it would make
sense to allow any name for a function.
Exported functions was a usefully debugging tool. You could do
things like:
env rm='() { [ $1 = want-to-keep ] || command rm $@; }
' /bin/rm='() { [ $1 != want-to-keep ] command rm $@; }
' my-command
To avoid want-to-keep be removed by my-command eventually
running system(/bin/rm want-to-keep).
I guess I'll have to switch to zsh now (using $ZDOTDIR/.zshenv) for
this kind of trick.
In zsh, any function name is allowed, even the empty
string, even those with spaces or NUL characters, using quoting:
$'\0' () echo I am the nul command
Or
'my command' () echo spaces in my name...
Forbidding functions (even importing them) with those names
doesn't bring any significant security benefit AFAICT.
From what I understand, it was done as a simple fix to avoid
problems with env vars whose name contains shell code and
because bash parser does not support defining functions with
arbitrary names like zsh does.
A better fix, IMO, would have been to allow any name in a
function name, or allow the same names from imported functions
as for functions declared normally.
I'd agree that if you can no longer import them, not allowing
declaring them would make sense, but might break existing
scripts which rely on that ability.
Also, as I said before, what is deemed a valid identifier is
locale specific (and there's a bug in that it only works
properly in single-byte locales), so one can still make locales
where (` or = are part of valid identifiers.
--
Stephane
Re: REGRESSION: shellshock patch rejects valid function names
2014-09-27 23:53:12 +0200, Arfrever Frehtes Taifersar Arahesis:
[...]
Ability to export/import functions with = in function names
could be achieved by not embedding function names in
environmental variables and using a single BASH_FUNCTIONS
environmental variable whose value would contain code of all
exported functions (in format similar to `declare -fpx` /
`export -fp`).
[...]
That's what I had in mind as well.
bash could align its function definition syntax with zsh's and
do
BASH_FUNCTIONS=f(){ echo f;}
'some function'(){ echo sf; }
'even with
newline and / and '\''quote
...'() { echo x; }
That would also be nicer with the environment as well
(BASH_FUNC_xxx()= needs 14 bytes, plus the pointer (4/8 bytes)
per exported function.
If bash were to implement that, sudo and possible others would
have to be updated at the same time to blacklist that variable
(at the moment sudo blacklists variables whose value starts with
() which is why the change to BASH_FUNC_xxx()=()... didn't
expose sudo).
--
Stephane
Re: Issues with exported functions
On 09/28/2014 10:31 AM, Ángel González wrote:
David A. Wheeler wrote:
2. Import environment variables *ONLY* when they are requested; do *NOT*
import them by default. Christos Zoulas has proposed this. This *IS* a
real backwards-incompatible change. But most users do *NOT* use this
functionality, and increasingly downstream systems are *already* switching
to this mode. E.G., FreeBSD has already switched to this; function imports
require --import-functions or enabling the IMPORTFUNCTIONS option. E.G.,
see: https://svnweb.freebsd.org/ports?view=revisionrevision=369341
This change eliminates the entire class of problems. It's still good to do
#1, even with #2, because if someone DOES perform an import, it reduces the
probability of accidentally importing the wrong thing. People are ALREADY
making this change, whether upstream does or not.
There's also the middleground of not parsing the environment variables
before they are going to be used. That avoids the issues caused by
parsing what is not needed *and* doesn't break backwards compatibility.
See the patch I sent a couple days ago.
That patch doesn't address the fact that variables and functions are in
different namespaces, though. That is, if I do 'export f=1; f(){ echo
2;}; export -f f', then what would $f be in the child shell? With
just your patch, but not the fix for separate namespaces of 4.3.27, you
are still trying to pass two separate 'f=...' environment variables,
with unspecified results, and risk the child getting 'echo $f' to see
the unexpected () { echo 2; }' instead of the expected 1. Your
approach of lazy parsing may still have benefits, but it is not a middle
ground, in that we MUST have separate namespaces (patch 27), and once we
have separate namespaces, your patch is no longer adding security, just
optimization.
John Haxby recently posted that A friend of mine said this could be a
vulnerability gift that keeps on giving.
(http://seclists.org/oss-sec/2014/q3/748). Bash will be a continuous rich
source of system vulnerabilities until it STOPS automatically parsing normal
environment variables; all other shells just pass them through! I've
turned off several websites I control because I have *no* confidence that
the current official bash patches actually stop anyone, and I am
deliberately *not* buying products online today for the same reason. I
suspect others have done the same. I think it's important that bash change
its semantics so that it obviously has absolutely no problems of this kind.
That's exactly what my patch does, although it wouldn't be transparent
if used inside bash (eg. echo $FUNC), as opposed of usage by its
children (wouldn't be hard to change, though).
I consider it an important design goal to ensure that ALL exported
variables cannot be corrupted no matter what their contents are. We
aren't quite there yet (due to the issues of 'function a=b () {:;}
corrupting the variable named BASH_FUNC_a even after patch 27 is
applied). But your own admission that $FUNC may be corrupted is an
argument against your patch in isolation.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Input line wrapping broken in 4.3.27 if built using included libtermcap
On 9/28/14, 7:02 PM, rain.back...@gmail.com wrote: Bash Version: 4.3 Patch Level: 27 Release Status: release Description: This is a bug affecting the latest of the shellshock patches at the time of writing, 4.3.27. If bash is configured and built on a system with no libtermcap, it attempts to build statically linking its own one. In this case, the resulting bash that is built does not correctly wrap long input lines. Well, sure. The included libtermcap is enough for bash to link successfully and run, but it doesn't know anything about your terminal and doesn't know how to read all the termcap/terminfo files out there. It can do really basic character movement, but that's about it. This has always been the case. There's nothing about patches 25-27 that introduced any changes here. 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: REGRESSION: shellshock patch rejects valid function names
2014-09-29 09:04:00 -0600, Eric Blake: [...] I would expect something like It shall be an error if fname is the name of a special built-in utility, as _that_ would be a hard requirement on bash, not just the application. Maybe we have a bug in the POSIX spec for a missing requirement. [...] Such a requirement would break bash, zsh, mksh, ATT ksh (for disciplines), which currently all allow a function called a.b Cheers, Stephane
Re: Issues with exported functions
Chet Ramey wrote: On 9/28/14, 12:31 PM, Ángel González wrote: There's also the middleground of not parsing the environment variables before they are going to be used. That avoids the issues caused by parsing what is not needed *and* doesn't break backwards compatibility. See the patch I sent a couple days ago. That's a reasonably elegant extension, but it doesn't really solve the problem any better than fixing the underlying parser problem. You still have to fix the parser, obviously. It reduces the attack surface for parsed-but-not-executed functions (and I expect a performance improvement, too). A user who can figure out how to pass a function with the appropriate name encoding, which at this point nobody has figured out to do remotely, can more than likely arrange for that function to be called, at which point it will be parsed and any underlying parser bug exposed. Or he can simply put the code to be executed inside the function to be called. There's no merit in exploiting a parser bug in the exported variable grep (before patch 27) if the bash script executes grep.
Re: Patch file bash42-049 is broken
Deron Meranda wrote: On an unrelated note, I have also tried to compare sources against the Savannah Git repository, and I noted that the repository has a couple small differences from the FTP files + patches. The Git repo has a blank file called -i, probably an accident of some command line arguments. It's intentional, see http://lists.gnu.org/archive/html/bug-bash/2014-07/msg00075.html
Re: Issues with exported functions
On Eric Blake wrote:
On 09/28/2014 10:31 AM, Ángel González wrote:
David A. Wheeler wrote:
2. Import environment variables *ONLY* when they are requested; do *NOT*
import them by default. Christos Zoulas has proposed this. This *IS* a
real backwards-incompatible change. But most users do *NOT* use this
functionality, and increasingly downstream systems are *already* switching
to this mode. E.G., FreeBSD has already switched to this; function
imports require --import-functions or enabling the IMPORTFUNCTIONS option.
E.G., see: https://svnweb.freebsd.org/ports?view=revisionrevision=369341
This change eliminates the entire class of problems. It's still good to
do #1, even with #2, because if someone DOES perform an import, it reduces
the probability of accidentally importing the wrong thing. People are
ALREADY making this change, whether upstream does or not.
There's also the middleground of not parsing the environment variables
before they are going to be used. That avoids the issues caused by
parsing what is not needed *and* doesn't break backwards compatibility.
See the patch I sent a couple days ago.
That patch doesn't address the fact that variables and functions are in
different namespaces, though. That is, if I do 'export f=1; f(){ echo
2;}; export -f f', then what would $f be in the child shell?
It would be (and is) 1, as required.
With just your patch, but not the fix for separate namespaces of 4.3.27, you
are still trying to pass two separate 'f=...' environment variables,
That's right, exactly what bash 4.3.27 did.
with unspecified results, and risk the child getting 'echo $f' to see
the unexpected () { echo 2; }' instead of the expected 1.
The bash children correctly get the two things, there are no unspecified
results for them.
The problems are:
* Non-bash programs reading f from the environment
* bash programs reading a free-text variable from the environment (which
the attacker can prefix with () {)
Your approach of lazy parsing may still have benefits, but it is not a middle
ground, in that we MUST have separate namespaces (patch 27),
The reasons I listed above justify having separate namespaces. The only
concern not to do it was BC. I agree with patch 27
and once we have separate namespaces, your patch is no longer adding
security, just
optimization.
No. If we had a perfect bash with no parser bugs (which we won't be able
to prove to have reached), then my patch would only be an optmization.
Otherwise it does add a security layer over that of patch 27 -although
the BASH_FUNCT prefix already sets the bar so high it might be
impossible to bypass-.
John Haxby recently posted that A friend of mine said this could be a
vulnerability gift that keeps on giving.
(http://seclists.org/oss-sec/2014/q3/748). Bash will be a continuous rich
source of system vulnerabilities until it STOPS automatically parsing
normal environment variables; all other shells just pass them through!
I've turned off several websites I control because I have *no* confidence
that the current official bash patches actually stop anyone, and I am
deliberately *not* buying products online today for the same reason. I
suspect others have done the same. I think it's important that bash
change its semantics so that it obviously has absolutely no problems of
this kind.
That's exactly what my patch does, although it wouldn't be transparent
if used inside bash (eg. echo $FUNC), as opposed of usage by its
children (wouldn't be hard to change, though).
I consider it an important design goal to ensure that ALL exported
variables cannot be corrupted no matter what their contents are. We
aren't quite there yet (due to the issues of 'function a=b () {:;}
corrupting the variable named BASH_FUNC_a even after patch 27 is
applied).
Using the colon there makes it invalid. Pasting the poc from the other
thread:
env -i bash -c 'function a=b(){ echo oops;};export -f a=b;export
BASH_FUNC_a=hi; bash -c echo \$BASH_FUNC_a'
But your own admission that $FUNC may be corrupted is an argument against
your patch in isolation.
Fair enough, I acknowledged from the beginning that it could be
combined with the other flying patches. I was trying to do only one fix.
Actually, I was thinking that the move should be to use a single
namespace. I realized now that it is a POSIX requirement that they are
separate:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_05
Regards
Re: Detecting invocation as /bin/sh ?
On 9/26/14, 4:29 PM, Alexandre Ferrieux wrote: On Friday, September 26, 2014 10:00:08 AM UTC+2, Andreas Schwab wrote: Alexandre Ferrieux alexandre.ferri...@gmail.com writes: So, what about, in bash's initialization, detecting that we are invoked as /bin/sh, It already does. See (bash) Bash POSIX Mode. Yes, it does do this detection, but too late for our concern, since things occur in the following order: (1) set_shell_name(argv[0]) = this detects sh and sets 'act_like_sh' (2) shell_initialize() = this decides to import funcs from env depending on flags like 'posixly_correct' (3) if (act_like_sh) ... sv_strict_posix (POSIXLY_CORRECT) So it seems the order is wrong. As a consequence, and this is confirmed by experience, the #!/bin/sh prefix behaves as featuristic bash. My suggestion then is to undo that mistake. Posix mode was never intended to turn bash into a shell that provides only what Posix specifies and nothing more. It makes bash conform to Posix by changing things where the default mode differs from what Posix specifies. Posix allows this, and allows extensions, and every shell that claims Posix conformance (except perhaps `posh') offers extensions beyond minimal Posix features. 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: Bash-4.2 Official Patch 49
On 9/27/14, 1:00 AM, V S, Nagendra (Nonstop Filesystems Team) wrote: Hi Chet, Thanks a lot for the patch. The official bash patch the patch that you posted on openwall forum seems to be different. The official bash patch does not contain this *** ../bash-4.2.48/y.tab.c 2012-12-31 11:53:10.0 -0500 --- y.tab.c2014-09-25 20:23:25.0 -0400 *** *** 5163,5166 --- 5163,5168 word_desc_to_read = (WORD_DESC *)NULL; + eol_ungetc_lookahead = 0; + current_token = '\n'; /* XXX */ last_read_token = '\n'; *** *** 8377,8379 } #endif /* HANDLE_MULTIBYTE */ - --- 8379,8380 Is this intentional ? Yes, it was intentional. Previous patches to bash-4.2 modified parse.y without updating y.tab.c, so it didn't seem like a good idea to start now. 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/
make error
Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-g$ uname output: Linux compiler 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4 11:26:59 UTC 2012 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.1 Patch Level: 0 Release Status: release Description: 1. `cd' to the directory containing the source code and type `./configure' to configure Bash for my system. 2.run 'make' I can see the following error message . rm -f mksyntax gcc -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -o mksyntax ./mksyntax.c rm -f syntax.c ./mksyntax -o syntax.c /bin/sh ./support/mkversion.sh -b -S . -s release -d 4.1 -o newversion.h \ mv newversion.h version.h gcc -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -DBUILDTOOL -c -o buildversion.o ./version.c gcc -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -o bashversion ./support/bashversion.c buildversion.o /bin/echo: line 1: Mon: command not found make: *** [.build] Error 127 please give me some help,thank you very much. 周有泉 YouQuan Zhou 技术研发|程序开发17组 Technology Research Development iPanel 2014 智慧激发创新 梦想振翅高飞 - 深圳市茁壮网络股份有限公司 iPanel.TV Inc. 广东省深圳市国威路罗湖高新技术产业第一园区113栋(518004) Block 113, Luohu High-tech Industry 1st Park, Guowei Road, Shenzhen, Guangdong, China 518004 电邮(Personal) zho...@ipanel.cn 网站(Web) www.iPanel.cn 公司微信(WeChat) 茁壮网络iPanel 直线(Direct)+86 755 2502 3361 手机(Mobile)+86 158 1407 7981 会议电话(Con)+86 755 8237 8388 客服电话(Hotline)+86 755 8237 8128 - 声明 (Declaration) 本邮件及其附件含有深圳市茁壮网络股份有限公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何人未经发件人许可以任何形式（包括但不限于部分地泄露、复制或散发）不当使用本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件，谢谢！ This email and its attachments contain confidential information from iPanel, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it. Thanks!
make error
Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-g$ uname output: Linux compiler 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4 11:26:59 UTC 2012 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.1 Patch Level: 0 Release Status: release Description: 1. `cd' to the directory containing the source code and type `./configure' to configure Bash for my system. 2.run 'make' I can see the following error message . rm -f mksyntax gcc -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -o mksyntax ./mksyntax.c rm -f syntax.c ./mksyntax -o syntax.c /bin/sh ./support/mkversion.sh -b -S . -s release -d 4.1 -o newversion.h \ mv newversion.h version.h gcc -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -DBUILDTOOL -c -o buildversion.o ./version.c gcc -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -o bashversion ./support/bashversion.c buildversion.o /bin/echo: line 1: Mon: command not found make: *** [.build] Error 127 please give me some help,thank you very much.
Re: REGRESSION: shellshock patch rejects valid function names
Just a few points to add.
On Monday, September 29, 2014 04:29:52 PM Stephane Chazelas wrote:
2014-09-29 09:04:00 -0600, Eric Blake:
[...]
The function is named fname; the application shall ensure that it is a
name (see XBD Name) and that it is not the name of a special built-in
utility.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_05
This doesn't normally matter because POSIX requires special builtins to take
precedence over functions during command search, so even if you have such a
function defined it is impossible to call. Bash doesn't use the correct search
order however.
Mksh has the reverse bug. It allows defining the function (wrongly) but then
calls the special builtin anyway (correctly).
Another bug is in ksh93 whose `builtin` allows disabling special builtins
(which according to the manual, shouldn't work).
$ ksh -c 'builtin -d set; function set { echo test; }; set'
test
Bash's enable correctly disallows that.
I agree the requirement is on the application, and I can't see
why POSIX should force a shell to reject a function whose name
doesn't contain a valid identifier.
...
Another thing you can do in bash is bypass its command name check by using a
null zeroth word.
$ { function } { echo test; }; () }; }
test
Ordinarily } would be uncallable, but apparently since bash only checks the
command name of the first word, calling with e.g. `() }` or `$() }` works.
--
Dan Douglas
signature.asc
Description: This is a digitally signed message part.
Re: Detecting invocation as /bin/sh ?
On Monday, September 29, 2014 9:51:45 PM UTC+2, Chet Ramey wrote: So it seems the order is wrong. As a consequence, and this is confirmed by experience, the #!/bin/sh prefix behaves as featuristic bash. My suggestion then is to undo that mistake. Posix mode was never intended to turn bash into a shell that provides only what Posix specifies and nothing more. It makes bash conform to Posix by changing things where the default mode differs from what Posix specifies. Posix allows this, and allows extensions, and every shell that claims Posix conformance (except perhaps `posh') offers extensions beyond minimal Posix features. Forget about posix mode then: bash -p (privileged) offers a lean-and-mean variant which pretty much satisfies anybody needing just sh. However, there is no way to store an option in a symbolic link, so all distributions doing sh - bash are bound to perpetuate the danger (of eval-from-the-env). So it would seem normal for some of them to move away from bash as the default sh. -Alex
Re: Bash-4.3 Official Patch 27
Linda Walsh wrote: wrote: The change only affects environment variables **loaded as exported functions**. Bash won't forbid you from using / inside the name of an environment variables. The below doesn't demonstrate bash doing anything with the variable you declared. You declare an ENV var with 'env' (not part of bash), then you start a new shell and use env to see that the original value is still there. It should be. You are not demonstrating any interaction with BASH. I was precisely trying to demostrate that bash wasn't doing anything. I got the impression that becker/Jon? was claiming that with Patch 27 (which removes those variable with a slash from loading as functions), variables with a / were removed from the environment. After rereading the subthread, I think I may have misunderstood them.
Re: REGRESSION: shellshock patch rejects valid function names
Dan Douglas orm...@gmail.com writes:
Another thing you can do in bash is bypass its command name check by using a
null zeroth word.
$ { function } { echo test; }; () }; }
test
Ordinarily } would be uncallable,
Only literal } is special, you can use \} instead, or store it in a
variable.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: REGRESSION: shellshock patch rejects valid function names
On Tuesday, September 30, 2014 12:11:15 AM Andreas Schwab wrote:
Dan Douglas orm...@gmail.com writes:
Another thing you can do in bash is bypass its command name check by using
a
null zeroth word.
$ { function } { echo test; }; () }; }
test
Ordinarily } would be uncallable,
Only literal } is special, you can use \} instead, or store it in a
variable.
Yeah I forgot there are a few ways. `0 }` is yet another.
--
Dan Douglas
Re: Detecting invocation as /bin/sh ?
On 9/29/14, 5:46 PM, Alexandre Ferrieux wrote: Forget about posix mode then: bash -p (privileged) offers a lean-and-mean variant which pretty much satisfies anybody needing just sh. However, there is no way to store an option in a symbolic link, so all distributions doing sh - bash are bound to perpetuate the danger (of eval-from-the-env). So it would seem normal for some of them to move away from bash as the default sh. Are we talking about the same thing? Privileged mode is intended for use when bash might run setuid (a bad idea in any case). It affects what bash will use from the environment -- yes, including shell functions -- and inhibits setting the euid to the ruid. It doesn't have any other effect. It certainly doesn't turn off any bash features. 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: Bash-4.3 Official Patch 26
On 9/26/14, 8:58 PM, Nathan McGarvey wrote: Pardon my catching up. This (and all the other related patches for other past versions) is to remedy CVE-2014-7169 and CVE-2014-6271 was remedied by the previous Patch 25 (and related set for all other versions.) Is this correct? Or are there still outstanding issues? You should install patch 27, which closes all known remote attack vectors. -- ``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: Detecting invocation as /bin/sh ?
On Tuesday, September 30, 2014 1:40:55 AM UTC+2, Chet Ramey wrote:
Forget about posix mode then: bash -p (privileged) offers a lean-and-mean
variant which pretty much satisfies anybody needing just sh. However,
there is no way to store an option in a symbolic link, so all distributions
doing sh - bash are bound to perpetuate the danger (of
eval-from-the-env). So it would seem normal for some of them to move away
from bash as the default sh.
Are we talking about the same thing?
Privileged mode is intended for use when bash might run setuid (a bad idea
in any case). It affects what bash will use from the environment -- yes,
including shell functions -- and inhibits setting the euid to the ruid.
It doesn't have any other effect. It certainly doesn't turn off any bash
features.
It *does* disable that embarrassing nightmare of a misfeature that is function
import:
if (privmode == 0 ... STREQN (() {, string, 4))
...
parse_and_execute(...)
So, from the perspective of a just the sh, Ma'am goal, it is a pretty good
contender. Regardless of the faith one can have in the recent patches, shunning
that 'parse_and_execute(environment)' altogether sounds orders of magnitude
safer.
-Alex
Re: Detecting invocation as /bin/sh ?
On 9/29/14, 7:53 PM, Alexandre Ferrieux wrote: On Tuesday, September 30, 2014 1:40:55 AM UTC+2, Chet Ramey wrote: Forget about posix mode then: bash -p (privileged) offers a lean-and-mean variant which pretty much satisfies anybody needing just sh. However, there is no way to store an option in a symbolic link, so all distributions doing sh - bash are bound to perpetuate the danger (of eval-from-the-env). So it would seem normal for some of them to move away from bash as the default sh. Are we talking about the same thing? Privileged mode is intended for use when bash might run setuid (a bad idea in any case). It affects what bash will use from the environment -- yes, including shell functions -- and inhibits setting the euid to the ruid. It doesn't have any other effect. It certainly doesn't turn off any bash features. It *does* disable that embarrassing nightmare of a misfeature that is function import: I guess if that's what you mean by just the sh, then yes, it does. That's a unique interpretation. -- ``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: REGRESSION: shellshock patch rejects valid function names
On 9/29/14, 5:25 PM, Dan Douglas wrote: This doesn't normally matter because POSIX requires special builtins to take precedence over functions during command search, so even if you have such a function defined it is impossible to call. Bash doesn't use the correct search order however. Bash searches for special builtins before shell functions when in Posix mode. -- ``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/
