Thanx Ian. I wonder if the BSD sh has the same vulnerability.

On 09/25/2014 01:50 AM, Ian Malone wrote: > > On 25 September 2014 01:36, jd1008 <jd1008(a)gmail.com&gt; wrote: >> >> On 09/24/2014 06:27 PM, Chris Adams wrote: >>> >>> Once upon a time, jd1008 <jd1008(a)gmail.com&gt; said: >>>> >>>> So, is this one of the ways javascripts exec bash to install malware >>>> or do other nasty stuff? >>> >>> This has nothing to do with Javascript. It is probably more serious to >>> servers, such as web servers, than to desktops.

>> Well and good. >> Are you saying that a java script, being executed on your system >> via the browser, cannot also fork and exec bash? > > That in itself is not the vulnerability, the vulnerability is that > starting bash with environment variables that are potentially set by > an untrusted user can execute code, the lwn write up is quite good > http://lwn.net/Articles/613032/

> Thanx Ian. I wonder if the BSD sh has the same vulnerability.

Are you saying that a java script, being executed on your system via the browser, cannot also fork and exec bash?

So, is this one of the ways javascripts exec bash to install malware or do other nasty stuff?

On Wed, 24 Sep 2014 17:33:15 -0600 jd1008 <jd1008(a)gmail.com&gt; wrote: > On 09/24/2014 05:27 PM, Jared K. Smith wrote: >> On Wed, Sep 24, 2014 at 6:56 PM, Patrick O'Callaghan >> <pocallaghan(a)gmail.com <mailto:pocallaghan@gmail.com>> wrote: >> >> Can we assume a patched version of Bash will be released >> shortly? >> >> >> It's in updates-testing now, and has enough karma that it should be >> pushed stable the next time the packages are mashed. See >> https://admin.fedoraproject.org/updates/bash-4.3.22-3.fc21 for more >> details. >> >> -- >> Jared Smith >> >> > So, could someone explain the nature of the vulnerability? https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environ... has a good writeup... along with: http://lwn.net/Articles/613032/ kevin

On 09/24/2014 05:27 PM, Jared K. Smith wrote: > > On Wed, Sep 24, 2014 at 6:56 PM, Patrick O'Callaghan > <pocallaghan(a)gmail.com <mailto:pocallaghan@gmail.com>> wrote: > > Can we assume a patched version of Bash will be released > shortly? > > > It's in updates-testing now, and has enough karma that it should be > pushed stable the next time the packages are mashed. See > https://admin.fedoraproject.org/updates/bash-4.3.22-3.fc21 for more > details. > > -- > Jared Smith > > So, could someone explain the nature of the vulnerability?

Quoting Edik Landaveri <elwanka(a)gmail.com&gt;: > #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) > > I assume Red Hat already have their hands into a patch as well. Just > have to > wait. I posted a CentOS patch three hours ago, I assume that came from upstream. Dave > -- > users mailing list > users(a)lists.fedoraproject.org > 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 >

#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) I assume Red Hat already have their hands into a patch as well. Just have to wait.

-- users mailing list users(a)lists.fedoraproject.org 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

http://arstechnica.com/security/2014/09/bug-in-bash-shell-creates-big-sec... From the article: The vulnerability affects versions 1.14 through 4.3 of GNU Bash. [...] To check your system, from a command line, type: env x='() { :;}; echo vulnerable' bash -c "echo this is a test" If the system is vulnerable, the output will be: vulnerable this is a test An unaffected (or patched) system will output: $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test I tried it and got the positive (vulnerable) result. Can we assume a patched version of Bash will be released shortly? poc

Thu, 25 Sep 2014 13:11:01 -0600 jd1008 <jd1008(a)gmail.com&gt; kirjoitti: > Thanx Ian. > I wonder if the BSD sh has the same vulnerability. > Quick updates http://koji.fedoraproject.org/koji/buildinfo?buildID=580601

On 25 September 2014 01:36, jd1008 <jd1008(a)gmail.com&gt; wrote: > On 09/24/2014 06:27 PM, Chris Adams wrote: >> Once upon a time, jd1008 <jd1008(a)gmail.com&gt; said: >>> So, is this one of the ways javascripts exec bash to install malware >>> or do other nasty stuff? >> This has nothing to do with Javascript. It is probably more serious to >> servers, such as web servers, than to desktops. >> >> On a web server, let's say you have some PHP or perl CGI code, and it >> needs to call out to an external program. Depending on how the code is >> written, the PHP/perl interpreter may run the external program via >> /bin/sh (which is bash on many systems, especially Linux systems). Now, >> if the web client has set some specific variables that get put into >> environment variables that get passed on to /bin/sh, bash will execute >> the arbitrary shell code as the web server user (e.g. Apache). >> >> At that point, it can get full remote access, which can then often see >> database credentials and such, accessing a lot of potentially secure >> data. Even on RHEL/CentOS/Fedora systems, SELinux probably won't help >> much (since the web user already has access to read that information). >> >> On a client system, there are some potential routes to exploiting this >> as well. For example, I think the DHCP and PPP clients will run >> external scripts to configure things (such as DNS, NTP, etc.), using >> environment variables to pass information, so a malicious server could >> potentially get full root access to a vulnerable client system. In most >> cases though, I don't think bash or /bin/sh get passed arbitrary remote >> data in environment variables on a client system (e.g. desktop). >> >> I could be missing some things (I'm not entirely familiar with the >> complexity added by modern desktop environments), but I don't think this >> is probably a huge deal for desktop Linux; I think the biggest impact >> would be on web servers with PHP/perl that calls out to external >> programs. >> > Well and good. > Are you saying that a java script, being executed on your system > via the browser, cannot also fork and exec bash? That in itself is not the vulnerability, the vulnerability is that starting bash with environment variables that are potentially set by an untrusted user can execute code, the lwn write up is quite good http://lwn.net/Articles/613032/ I might be wrong about this, but my understanding is that since CGI uses environment variables to communicate parameters, any request to a bash CGI script, or a CGI script that forks bash, exposes this vulnerability, even if it does nothing with the parameters and is just a hello world. Whereas if firefox forks bash somehow (something I don't think Javascript can do, but I could be wrong), the environment is controlled by Firefox (javascript code can't set environment variables either), so you're less exposed, though the RedHat page on the vulnerability does mention that they can't exclude all vulnerabilities to this in Firefox. https://access.redhat.com/articles/1200223 suggests Apache modules are unaffected, so if you use mod_php for example it should not allow remote requests to set environment variables so even if bash gets forked (which is hard to guarantee it wont by some module) it doesn't expose this. Think I'll double check that...

I was wondering if it could be a good workaround to link /bin/sh to tcsh instead of bash. I'm not using bash at all but probably something in the system is so do you know some contraindication on a system with apache and SVN servers?

http://arstechnica.com/security/2014/09/bug-in-bash-shell-creates-big-sec... From the article: The vulnerability affects versions 1.14 through 4.3 of GNU Bash. [...] To check your system, from a command line, type: env x='() { :;}; echo vulnerable' bash -c "echo this is a test" If the system is vulnerable, the output will be: vulnerable this is a test An unaffected (or patched) system will output: $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test I tried it and got the positive (vulnerable) result. Can we assume a patched version of Bash will be released shortly? poc

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?

Confused?

> Quoting Edik Landaveri <elwanka(a)gmail.com&gt;: > >> #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)

On Wed, Sep 24, 2014 at 6:56 PM, Patrick O'Callaghan <pocallaghan(a)gmail.com <mailto:pocallaghan@gmail.com>> wrote: Can we assume a patched version of Bash will be released shortly? It's in updates-testing now, and has enough karma that it should be pushed stable the next time the packages are mashed. See https://admin.fedoraproject.org/updates/bash-4.3.22-3.fc21 for more details. -- Jared Smith