Re: [PLUG] ALL BASH RELEASES STILL VULNERABLE [Re: cross-platform bash vulnerability widespread]
At least one person had different (but still rather wrong-looking) results
for that example (which is the one from CVE-2014-7169's cited links); I've
seen another one being passed around with a moderately different syntax, so
give it a try too:
V='() { function a a>\' bash -c 'iam-vulnerable';ls iam-vulnerable;rm -f
iam-vulnerable
(if it's not clear, the backslash there is a literal backslash, they don't
quote things in single-quote-mode. Also, despite the fact that the word
"env" is missing from the example, be assured it is setting V in the
environment. "VAR=foo cmd..." is a portable sh way to set cmd's env just
prior to executing it (without affecting anything in the outer/interactive
shell).)
-mjc
On Thu, Sep 25, 2014 at 12:31 PM, Micah Cowan
wrote:
> Sorry, that should be:
>
> $ env X='() { (a)=>\' bash -c "echo date"; cat echo
>
> The previous version obviously only works if your sh is bash, obviously.
>
> -mjc
>
> On Thu, Sep 25, 2014 at 12:25 PM, Micah Cowan
> wrote:
>
>> > $ env X='() { (a)=>\' sh -c "echo date"; cat echo
>>
>
___
PLUG mailing list
PLUG@lists.pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] ALL BASH RELEASES STILL VULNERABLE [Re: cross-platform bash vulnerability widespread]
Sorry, that should be:
$ env X='() { (a)=>\' bash -c "echo date"; cat echo
The previous version obviously only works if your sh is bash, obviously.
-mjc
On Thu, Sep 25, 2014 at 12:25 PM, Micah Cowan
wrote:
> > $ env X='() { (a)=>\' sh -c "echo date"; cat echo
>
___
PLUG mailing list
PLUG@lists.pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
[PLUG] ALL BASH RELEASES STILL VULNERABLE [Re: cross-platform bash vulnerability widespread]
Sorry, I should have done this title change in the previous message... it
certainly merits it.
Make sure you're testing with the revised "env X" example (below), not the
one from the original CVE earlier yesterday.
At the moment, they're saying so far they only know you can write to files
(certainly bad enough), and not necessarily execute arbitrary code (in the
patched versions, that is)... but it seems likely to me there's another
remote-code exploit lurking there.
-mjc
On Thu, Sep 25, 2014 at 11:53 AM, Micah Cowan
wrote:
>
>
> None of yesterday's fixes are complete (but still use yesterday's patch
> anyway in the meantime, as it's better than nothing).
>
> bash is STILL vulnerable everywhere, as tracked by this (newer) CVE:
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169
>
> I'm not currently aware of a patch for the revised issue as of yet. Some
> folks I know (my employer, for instance) are responding by completely
> disabling function exports completely, which does the job:
>
>
> https://github.com/akamai/bash/commit/7caac6ee41f645fc21b6e5eddc820151f6e6c43c
>
> Note that (as I discovered) the patch above will successfully apply
> INCORRECTLY to some older versions of bash, unless you also specify --fuzz
> 1 (fuzz 2, the default, lets it apply). In one version of bash
> (4.2.something) I patched, the results were BUILDABLE, but completely
> wrong. Eyeball it after patching to make sure it only excludes the body of
> a single if statement.
>
> Example of the still-existing exploit:
>
> $ env X='() { (a)=>\' sh -c "echo date"; cat echo
>
> (if the file "echo" exists afterwards, it's vulnerable)
>
> Again, as of this time, there is NO released patch for this one yet.
>
> -mjc
>
___
PLUG mailing list
PLUG@lists.pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
