While testing before release is needed but the component update process with new system template as we have now takes a long time logistically.
Thanks Animesh > -----Original Message----- > From: Sheng Yang [mailto:sh...@yasker.org] > Sent: Tuesday, September 30, 2014 6:08 PM > To: <dev@cloudstack.apache.org> > Subject: Re: Shellshock > > It's not a safe approach, because upgrade without testing may introduce other > bugs, such as one bug we saw recently introduced by upgrade of openswan. I > think we still need to generate template, then distribute it after testing. > > If we can maintain an supported Debian repo for CloudStack, then it would be > much easier for upgrade. > > --Sheng > > On Tue, Sep 30, 2014 at 5:31 PM, ilya musayev <ilya.mailing.li...@gmail.com> > wrote: > > > Perhaps we take an approach from a different angle. > > > > Each time systemvm deployed, it mounts an ISO which contains some > > shell scripts that are run on first boot. > > > > We can alter the iso file and "inject" user specified script that will > > run "apt-get/yum update bash" or anything else user needs to do to > > customize the router vm to his liking. > > > > Regards > > ilya > > > > On 9/30/14, 4:26 PM, Adrian Lewis wrote: > > > >> @John - Quite agree. It's not just scripts that need checking either. > >> Very unsettling to have a vulnerable version of bash on every system > >> vm, many with direct access to both the CS infrastructure as well as client > VMs. > >> All > >> it takes is for someone to find another vector (e.g. DHCP, DNSmasq) > >> other than a script to inject system variables and there's suddenly a > >> MUCH bigger problem. > >> > >> Is there no way to simply update the version of bash included with > >> the system vm template? At the moment it seems to be version 4.2.37 > >> which is vulnerable (based on > >> http://cloudstack.apt-get.eu/systemvm/4.4/systemvm64template-4.4.1-7- > >> vmware.ova). > >> > >> I'm not too familiar with what happens to the template as it's > >> deployed but if I log in as root/password to the system vm template > >> running as downloaded in VMware Workstation and 'echo $SHELL' I get > >> '/bin/bash' even though '/bin/sh' is a symlink to '/bin/dash'. > >> > >> Perhaps someone is already working quietly on this but surely this > >> should be treated as a fairly major priority? I'd far rather not have > >> bombs in every system vm in the first place regardless of whether > >> people think there aren't any detonators. > >> > >> Adrian > >> > >> -----Original Message----- > >> From: John Kinsella [mailto:j...@stratosec.co] > >> Sent: 30 September 2014 22:57 > >> To: dev@cloudstack.apache.org > >> Subject: Re: Shellshock > >> > >> I’m not worried about any specific use-case, but I’d rather not have > >> vulnerable software running on SSVMs in general. > >> > >> John > >> > >> On Sep 30, 2014, at 2:47 PM, Sheng Yang > >> <sh...@yasker.org<mailto:sh...@yasker.org>> wrote: > >> > >> The parameters of system() function have been verified as valid > >> IP/netmask format by script, so I don't think other parameters would > >> be able to slip in in this case. > >> > >> --Sheng > >> > >> On Tue, Sep 30, 2014 at 8:38 AM, Go Chiba > >> <go.ch...@gmail.com<mailto:go.ch...@gmail.com>> wrote: > >> > >> Hi folks, > >> > >> By my digging, ipcalc included system() function call but debian > >> based our system vm are using dash as system shell. So I think this > >> shellshock concern are not directly affected to system vm cgi-bin. > >> right? > >> > >> GO > >> > >> from my iPhone > >> > >> 2014/09/30 10:13、Demetrius Tsitrelis > >> <demetrius.tsitre...@citrix.com<mailto:demetrius.tsitre...@citrix.com > >> >> > >> のメッセージ: > >> > >> http://systemvm-public-ip/cgi-bin/ipcalc is a perl script. > >> > >> -----Original Message----- > >> From: Sheng Yang [mailto:sh...@yasker.org] > >> Sent: Monday, September 29, 2014 5:21 PM > >> To: <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> > >> Subject: Re: Shellshock > >> > >> http://systemvm-public-ip/cgi-bin/ipcalc is NOT a bash script, so > >> it's normal that it cannot be exploited. > >> > >> --Sheng > >> > >> On Fri, Sep 26, 2014 at 1:57 PM, Demetrius Tsitrelis < > >> demetrius.tsitre...@citrix.com<mailto:demetrius.tsitre...@citrix.com> > >> > > >> wrote: > >> > >> Do you mean you tried setting the USER_AGENT like in > >> https://community.qualys.com/blogs/securitylabs/2014/09/25/qualysguar > >> d -remote-detection-for-bash-shellshock > >> ? > >> > >> > >> -----Original Message----- > >> From: Ian Duffy [mailto:i...@ianduffy.ie] > >> Sent: Friday, September 26, 2014 6:56 AM > >> To: CloudStack Dev > >> Subject: Re: Shellshock > >> > >> Tried this against the latest system vms built on Jenkins. > >> > >> Didn't get a successful exploited response. Tested against > >> http://systemvm > >> - public-ip/cgi-bin/ipcalc > >> On 25 Sep 2014 16:56, "Abhinandan Prateek" <agneya2...@gmail.com> > >> wrote: > >> > >> > >> After heart bleed we are Shell shocked > >> http://www.bbc.com/news/technology-29361794 ! > >> It may not affect cloudstack directly as it is a vulnerability that > >> affects bash, and allows the attacker to take control of the system > >> running bash shell. > >> > >> -abhi > >> > >> > >> > >> Stratosec - Secure Finance and Heathcare Clouds http://stratosec.co > >> o: 415.315.9385 > >> @johnlkinsella<http://twitter.com/johnlkinsella> > >> > > > >
