We (ACS security team) are aware of the glibc vulnerability, and yes a vulnerable version exists in the current supported version of the system VM image. The question though, which I’ve been trying to figure out is does the code running on the secondary storage VM, console proxy, or virtual router actually call the vulnerable code, and do so in a manner which a malicious party could leverage the vulnerability on the VM in a usable way.
Basically a malicious user would have to compromise the DNS resolver that the System VM uses for DNS resolution, and then get System VM to execute (basically) a reverse DNS lookup to that compromised DNS server. I don’t think the chance of this is significant. All that said, best move right now is probably to update glibc if you can do so. In the future, I’d ask if you have questions about security-related issues with CloudStack, to contact [email protected]. Once we have a solid feel on this in the coming days, we’ll put out a blog post and/or update. John > On Feb 22, 2016, at 7:00 AM, Stephan Seitz > <[email protected]> wrote: > > >> is the latest system vm template vulnerable to CVE-2015-7547 >> (https://security-tracker.debian.org/tracker/CVE-2015-7547)? >> I cannot find anything about it in the mailinglist and/or CS page. > > If you ssh into the system-VMs, you'll find the vulnurable version of > libc. > > to mitigate this, we've updated the libc (and only the installed > libc-packages) in the running system-VMs and rebooted them. > > Additionally, we've updated the libc in the respective template. > Since we're using XenServer, thats a vhd located at the 2nd. storage, > which we've chroot'ed into, using blktap2, kpartx and mount. > > cheers, > > - Stephan > > > >
