Re: Issue with Bash-4.3 Official Patch 27
On 10/15/14, 9:38 AM, lorenz.bucher@rohde-schwarz.com wrote: > Hello, > in refer to > http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00278.html variables > with suffix "%%" can't be set/exported. > This makes problems restoring environments which where saved by external > programs like printenv (see example below) This trick -- which was always fragile because printenv is not a robust way to do this -- will not work any more. One of the reasons we implemented the new exported function name encoding scheme was to avoid name collisions with exported variables. You can use `export -f' to generate a function definition and declaration that you can save in a file for later use. 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: Issue with Bash-4.3 Official Patch 27
On 10/15/14, 1:49 PM, lorenz.bucher@rohde-schwarz.com wrote: > But anyway. > In my opinion I should trust a shell not violating their own rules and be > able to import their own variables. That's not the issue. The shell can import variables like that just fine, as evidenced by exported functions actually working. The question is whether or not `export' lets you set and export non-identifiers. It does and should not. > So the % character should be allowed to be used in variable names. No, shell variable names should continue to be shell identifiers. You can already use `%' (any character, really) in environment variable names. -- ``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: Issue with Bash-4.3 Official Patch 27
2014-10-16 15:09 GMT+02:00 Chet Ramey : > On 10/15/14, 1:49 PM, lorenz.bucher@rohde-schwarz.com wrote: > > > But anyway. > > In my opinion I should trust a shell not violating their own rules and be > > able to import their own variables. > > That's not the issue. The shell can import variables like that just fine, > as evidenced by exported functions actually working. The question is > whether or not `export' lets you set and export non-identifiers. It does > and should not. > > > So the % character should be allowed to be used in variable names. > > No, shell variable names should continue to be shell identifiers. You > can already use `%' (any character, really) in environment variable > names. Regardless though, shouldn't source <(declare -xp) work whether or not the environment contains invalid identifiers? It doesn't at present: $ env %=% bash -c 'echo "$BASH_VERSION"; source <(declare -xp)' 4.3.30(1)-release /dev/fd/63: line 1: declare: `%': not a valid identifier Isn't declare -p output meant to be reusable as shell input? -- Geir Hauge
bash-2.05b-013 appears to not work
We have been compiling some of the older versions of bash to fix vulnerabilities, and for the most, has been working. However, when we patch the 013 patch for CVE-2014-7187, and run the nested loop, it's still showing as vulnerable. Has anyone else had a similiar experience? Thanks for the help, D
Re: bash-2.05b-013 appears to not work
On 10/16/14, 5:02 PM, Dave Kalaluhi wrote: > We have been compiling some of the older versions of bash to fix > vulnerabilities, and for the most, has been working. > > However, when we patch the 013 patch for CVE-2014-7187, and run the > nested loop, it's still showing as vulnerable. > > Has anyone else had a similiar experience? Since the code that had the off-by-one error was not even in bash-2.05b, I'm skeptical that it's vulnerable. -- ``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-2.05b-013 appears to not work
On 10/16/2014 03:02 PM, Dave Kalaluhi wrote: > We have been compiling some of the older versions of bash to fix > vulnerabilities, and for the most, has been working. > > However, when we patch the 013 patch for CVE-2014-7187, and run the > nested loop, it's still showing as vulnerable. Exactly HOW are you testing? > > Has anyone else had a similiar experience? Reading the archives, I see other people using an invalid test for CVE-2014-7187: https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00137.html https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00140.html Remember, a parser bug is not necessarily an exploitable vulnerability. It is sufficient to know that bash cannot be exploited once you apply patch 10 (all 6 CVEs were neutralized by that one patch, as well as any other as-yet-unreported parser bugs). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
