On 26 September 2014 05:43, Roger <arelem@xxxxxxxxxxx> wrote:
> I don't know what to think. I have tried all of the bash tests mentioned so
> far and bash shell indicates they all fail as explained in the reports.
> Therefore my shell in Ubuntu 14.04 must be already patched. Why is mine ok
> yet others have not yet patched?
> Has Linux not yet released the update?
"Linux" isn't an organisation that releases updates. If anything it
would refer to kernel.org and the problem isn't connected to the
kernel. In fact bash is also used by Mac OS-X and BSDs, so those are
affected. Ubuntu on the other hand has for some years used a
light-weight POSIX shell called "Dash" of bash as it's main
interpreter. Confused yet?
> Confused?
Okay.
The command interpreter used for many traditional shell scripts and
the 'system' function (which many programs will use when launching
other programs) is located at:
/bin/sh
This can be any POSIX compatible shell (see Chris Adams's email on
this thread). And Bash has been used for that purpose for a long time.
RHEL 6 (RedHat)
$ ls -lh /bin/sh
lrwxrwxrwx. 1 root root 4 Sep 9 09:51 /bin/sh -> bash
Most systems do the above and make sh a link to bash, so when a script
or 'system' calls sh it really calls bash. (For more on 'system' see
the end of email)
On Ubuntu:
$ ls -lh /bin/sh
lrwxrwxrwx 1 root root 4 2010-09-17 15:36 /bin/sh -> dash
So 'system' and /bin/sh scripts get Dash which doesn't have this vulnerability.
On those systems the following test comes back okay:
$ env x='() { :;}; echo OOPS' sh -c :
$
But on the same unpatched (and very well isolated, non-server system):
$ env x='() { :;}; echo OOPS' bash -c :
OOPS
Because while sh is okay, bash is still present, so bash scripts are
still vulnerable. The difference in the tests is the first one tests
your systems /bin/sh and the second tests bash explicitly.
Of course the other possibility the test shows things are okay on your
system is:
>> Quoting Edik Landaveri <elwanka@xxxxxxxxx>:
>>
>>> #Thu Sep 25 19:11:30 PDT 2014
>>>
>>> Debian already released a patch
>>> GNU bash, version 4.3.25(1)-release-(x86_64-pc-linux-gnu)
Ubuntu being debian based has probably also got the patch out quickly.
As has RedHat, I finally upgraded a F18 system to F19 last night using
Yum (because of this bug) and was pleasantly surprised to find it had
at least one of the earlier versions of the RH patch applied. RH are
updating their blog on it as progress is made
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
* system: this is one of the reasons this is really poisonous for CGI,
because CGI uses environment variables to communicate parameters and
therefore even if you're not using bash in any CGI script, if your
/bin/sh is bash and a CGI script uses system to start another program,
no matter how well sanitised the command is it's still exposed to this
bug. In fact the man page for the system function has long had this
warning:
Do not use system() from a program with set-user-ID or set-group-ID
privileges, because strange values for some environment variables might
be used to subvert system integrity. Use the exec(3) family of func‐
tions instead, but not execlp(3) or execvp(3)
--
imalone
http://ibmalone.blogspot.co.uk
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
