Patch to Vulnerability Linkage
Is there any linkage between bash patches and known CVE (or any other database) IDs? (Source-code comment, bug-tracker, etc.) I understand that there is not a one<->one relationship, but for the bug-fixes that do pertain to one or more vulnerability entry, it may be beneficial to outright state "this patch is designed to fix X". -Nathan
Re: bash-2.05b patch 11 is missing from ftp.gnu.org
On 10/2/14, 6:27 PM, Sang Suh wrote: > Unlike other versions, bash-2.05b patch 11 is missing from > ftp.gnu.org. Will it be appear soon? It was uploaded with the rest of that batch: ftp.gnu.org://gnu/bash/bash-2.05b-patches/bash205b-011 -- ``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: Patch to Vulnerability Linkage
On 10/3/14, 4:55 AM, Nathan McGarvey wrote: > Is there any linkage between bash patches and known CVE (or any other > database) IDs? (Source-code comment, bug-tracker, etc.) > I understand that there is not a one<->one relationship, but for the > bug-fixes that do pertain to one or more vulnerability entry, it may be > beneficial to outright state "this patch is designed to fix X". Yes, here's a list. I lose track of the CVE IDs myself. bash43-025 CVE-2014-6271 9/24/2014 bash43-026 CVE-2014-7169 9/26/2014 bash43-027 exported function namespace change 9/27/2014 bash43-028 CVE-2014-7186/CVE-2014-7187 10/1/2014 bash43-029 CVE-2014-6277 10/2/2014 There is still one more, for CVE-2014-6278, that I have to do some minor work on before rolling out patches. 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: Patch to Vulnerability Linkage
2014-10-03 08:56:41 -0400, Chet Ramey: > On 10/3/14, 4:55 AM, Nathan McGarvey wrote: > > Is there any linkage between bash patches and known CVE (or any other > > database) IDs? (Source-code comment, bug-tracker, etc.) > > I understand that there is not a one<->one relationship, but for the > > bug-fixes that do pertain to one or more vulnerability entry, it may be > > beneficial to outright state "this patch is designed to fix X". > > Yes, here's a list. I lose track of the CVE IDs myself. > > bash43-025CVE-2014-6271 9/24/2014 > bash43-026CVE-2014-7169 9/26/2014 > bash43-027exported function namespace change 9/27/2014 > bash43-028CVE-2014-7186/CVE-2014-7187 10/1/2014 > bash43-029CVE-2014-6277 10/2/2014 > > There is still one more, for CVE-2014-6278, that I have to do some minor > work on before rolling out patches. [...] To clarify, only bash43-027 matters (stop bash parser from being exposed to untrusted input (any environment variable) (CVE-2014-ShouldHaveBeen)). Once that's fixed, the other bugs become either - non-bugs: CVE-2014-6271 (interpret code after the function definition) is not a bug in that it doesn't affect the behavior of function exporting and could even be seen as a feature (a debugging tool which makes it more convenient to have bash run code on startup rather than having to rely on BASH_ENV and also works when bash is invoked as sh) - or very very minor ones (the type of bug you would not bother fixing unless you're a perfectionist) as they would never be hit, and not security vulnerabilities in any case. For instance CVE-2014-6278 is the most severe bug (almost as bad as CVE-2014-6271) when the door is open (when the parser is exposed), and becomes the most insignificant one when it's closed (when bash43-027 is applied). -- Stephane
Re: Patch to Vulnerability Linkage
Thanks much for the list and all the rapid patch releases as of late. Good stuff. -Nathan On Fri, Oct 3, 2014 at 8:56 AM, Chet Ramey wrote: > On 10/3/14, 4:55 AM, Nathan McGarvey wrote: > > Is there any linkage between bash patches and known CVE (or any other > > database) IDs? (Source-code comment, bug-tracker, etc.) > > I understand that there is not a one<->one relationship, but for the > > bug-fixes that do pertain to one or more vulnerability entry, it may be > > beneficial to outright state "this patch is designed to fix X". > > Yes, here's a list. I lose track of the CVE IDs myself. > > bash43-025 CVE-2014-6271 9/24/2014 > bash43-026 CVE-2014-7169 9/26/2014 > bash43-027 exported function namespace change 9/27/2014 > bash43-028 CVE-2014-7186/CVE-2014-7187 10/1/2014 > bash43-029 CVE-2014-6277 10/2/2014 > > There is still one more, for CVE-2014-6278, that I have to do some minor > work on before rolling out patches. > > 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/ >
Bash 2.05 patch for "shellshock"
Hi, I'm really going out on a limb, but is there any chance of getting a shellshock patch for Bash 2.05? I've got many legacy systems running RH7.2 (enigma) that I'm trying to locate a fix for. I've looked at the patches for Bash, but the fixes only go as far back as 2.05b. I've attempted to manually make the changes that the patches for 2.05b make, however there were a lot of changes between 2.05 and 2.05b so not everything matches. These are legacy systems that I've got to support and upgrading to a newer version of Bash is not possible. I've run the tests and this version of Bash is vulnerable. Thanks -Tom
Environment parsed for Functions when invoked as rbash (and sh)
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.2
-L/home/abuild/rpmbuild/BU\
ILD/bash-4.2/../readline-6.2
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='l\
inux-gnu' -DCONF_MACHTYPE='x86_64-suse-linux-gnu' -DCONF_VENDOR='suse'
-DLOCALE\
DIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I.
-I. -I.\
/include -I./lib -fmessage-length=0 -grecord-gcc-switches
-fstack-protector -\
O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables
-fasynchronous-unwind-tables -g -\
D_GNU_SOURCE -DRECYCLES_PIDS -Wall -g -std=gnu89 -Wuninitialized -Wextra
-Wno-u\
nprototyped-calls -Wno-switch-enum -Wno-unused-variable
-Wno-unused-parameter -\
ftree-loop-linear -pipe -DBNC382214=0 -fprofile-use
uname output: Linux enet-h1n1 3.11.10-21-default #1 SMP Mon Jul 21
15:28:46 UTC\
2014 (9a9565d) x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-suse-linux-gnu
Bash Version: 4.2
Patch Level: 47
Release Status: release
Description:
When run as rbash, it parses then environment for functions when the
man page specifically says it does NOT do this.
It is also UNEXPECTED for bash run as "sh" to import fuctions
from the environment (which it also seems to do).
Repeat-By:
while running bash:
export Y=\(\)\ \{\ ignored\;\ \}\;\ /usr/bin/id
rbash
(same with sh)
Note the error message which means rbash and sh are parsing the
environment to find functions.
Fix:
When bash is run as rbash or sh it should NOT parse the inherited
environment for functions (nor for options).
Actually, I suggest bash be modified to ONLY parse the environment for
functions when it is specifically invoked as bash - and act as rbash
when invoked as any unrecognized name.
--
-
The views and opinions expressed above are strictly
those of the author(s). The content of this message has
not been reviewed nor approved by any entity whatsoever.
I should not be considered an "AUTHORITY" on any subject.
-
Paul FM Info: http://www.umn.edu/~paulfm/
-
Re: Environment parsed for Functions when invoked as rbash (and sh)
On 10/03/2014 03:37 PM, Paul FM wrote:
>
> Bash Version: 4.2
> Patch Level: 47
You are several patches behind.
> Repeat-By:
> while running bash:
> export Y=\(\)\ \{\ ignored\;\ \}\;\ /usr/bin/id
This syntax no longer causes function parsing, as of 4.2 patch level 50.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Environment parsed for Functions when invoked as rbash (and sh)
On 10/3/14, 5:37 PM, Paul FM wrote: > Bash Version: 4.2 > Patch Level: 47 > Release Status: release > > > > Description: > When run as rbash, it parses then environment for functions when the > man page specifically says it does NOT do this. Yeah, that's a documentation problem. It's never behaved that way. The restrictions are enforced after startup files are read, which happens after the environment is read. The restricted shell isn't actually all that restricted, anyway. > It is also UNEXPECTED for bash run as "sh" to import fuctions from > the environment (which it also seems to do). Maybe you don't expect it, but it's always behaved that way, and there's no reason it shouldn't. -- ``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/
