pinion Posted May 13, 2015 Share Posted May 13, 2015 http://arstechnica.com/security/2015/05/extremely-serious-virtual-machine-bug-threatens-cloud-providers-everywhere/ So there's no way for me to patch this myself right? I'm basically at the mercy of the unraid team when KVM will be patched? Quote Link to comment
jonp Posted May 13, 2015 Share Posted May 13, 2015 http://arstechnica.com/security/2015/05/extremely-serious-virtual-machine-bug-threatens-cloud-providers-everywhere/ So there's no way for me to patch this myself right? I'm basically at the mercy of the unraid team when KVM will be patched? This is a non-issue for unRAID users. 1 - The headline of the article says a lot: Extremely serious virtual machine bug threatens cloud providers everywhere unRAID users are not cloud providers. You are not hosting a multi-tenant virtual environment for random people as a business service (or at least you shouldn't be). Cloud providers are companies like Amazon, Google, Rackspace, VPS.net, etc. They are the ones primarily impacted by this because the exploit allows for a customer with access to a single guest VM to traverse the file directory structure of other VMs on the same system. In our applied use of VMs, all VMs are operated and maintained by YOU, so unless you're worried about hacking yourself, this isn't an issue. 2 - The exploit's source: The vulnerability is the result of a buffer-overflow bug in QEMU's virtual Floppy Disk Controller, which is used in a variety of virtualization platforms and appliances. We do not generate a virtual floppy disk controller in our generation of VMs from QEMU. We generate IDE or VirtIO. You would have to manually add into the XML a FD controller in which case, you are causing the exposure to the exploit yourself, not unRAID. 3 - You are 100% at the mercy of us to patch this bug, which will be patched in the future, but this isn't a critical security bug because our use case/configuration limits exposure significantly. Hope this clarifies and calms nerves. I sure wouldn't want to be working at Amazon or Google as a virtual server admin right now. Got a feeling they'll be patching till the wee hours of the night. Quote Link to comment
archedraft Posted May 13, 2015 Share Posted May 13, 2015 so unless you're worried about hacking yourself I'll do it, don't think I won't! Quote Link to comment
jonp Posted May 13, 2015 Share Posted May 13, 2015 so unless you're worried about hacking yourself I'll do it, don't think I won't! Quote Link to comment
jonp Posted May 13, 2015 Share Posted May 13, 2015 And for those that are still skeptical, here's an easy way to check: 1 - ssh/telnet into your server 2 - navigate to /var/log/libvirt/qemu 3 - for any VMs you have started, you will see log files present denoted by their name 4 - cat the log file and look for the floppy disk attribute inside. From QEMU documentation: ‘-fdb file’ Use file as floppy disk 0/1 image (see section Disk Images). You can use the host floppy by using ‘/dev/fd0’ as filename (see section Using host drives). As an example, here's my Windows 8.1 VM: qemu-system-x86_64 -name Windows 8.1 Localized Virtual Desktop -S -machine pc-i440fx-2.3,accel=kvm,usb=off,mem-merge=off -cpu host -drive file=/usr/share/qemu/ovmf-x64/OVMF-pure-efi.fd,if=pflash,format=raw,unit=0 -m 10240 -realtime mlock=on -smp 6,sockets=1,cores=6,threads=1 -uuid 20cb5203-13e5-47e7-82c9-209ed8559d4d -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows 8.1 Localized Virtual Desktop.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/dev/disk/by-id/ata-Corsair_Neutron_GTX_SSD_1341790500009756003E,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=22 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:16:3e:1a:b3:4a,bus=pci.0,addr=0x2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/Windows 8.1 Localized Virtual Desktop.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device vfio-pci,host=02:00.0,id=hostdev0,bus=pci.0,addr=0x5 -device vfio-pci,host=00:1b.0,id=hostdev1,bus=pci.0,addr=0x6 -device vfio-pci,host=00:1d.0,id=hostdev2,bus=pci.0,addr=0x8 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on Or you could just take my word for it... Quote Link to comment
jonp Posted May 13, 2015 Share Posted May 13, 2015 Can I rename this thread to "debunked" now? Quote Link to comment
pinion Posted May 13, 2015 Author Share Posted May 13, 2015 Can I rename this thread to "debunked" now? Thanks for your response. And I'm certainly much less worried about it now. I think there are some convoluted ways I could still be vulnerable but I don't think it's anything that necessitates an emergency LimeTechs part. It still seems like if I were to create a KVM Ubuntu server for friends to host websites I would be vulnerable if one of them chose to play around and see if they could exploit me. That's just one example. I'm personally not doing that and I'm not hosting anything on my server that friends or anyone else should have access to. But that's not to say no one here is doing that. So no... I don't think this is debunked. I think there are use cases where there is a credible threat to some users depending on how they use the software LimeTech has officially blessed and I think they should be made aware how they are or aren't at risk with examples. I think your response goes a long way to answer that but I also believe there are ways people could make themselves vulnerable and they should be made aware. Quote Link to comment
jonp Posted May 13, 2015 Share Posted May 13, 2015 Can I rename this thread to "debunked" now? Thanks for your response. And I'm certainly much less worried about it now. I think there are some convoluted ways I could still be vulnerable but I don't think it's anything that necessitates an emergency LimeTechs part. It still seems like if I were to create a KVM Ubuntu server for friends to host websites I would be vulnerable if one of them chose to play around and see if they could exploit me. That's just one example. I'm personally not doing that and I'm not hosting anything on my server that friends or anyone else should have access to. But that's not to say no one here is doing that. So no... I don't think this is debunked. I think there are use cases where there is a credible threat to some users depending on how they use the software LimeTech has officially blessed and I think they should be made aware how they are or aren't at risk with examples. I think your response goes a long way to answer that but I also believe there are ways people could make themselves vulnerable and they should be made aware. I think it's debunked only because unRAID users are not affected...period. If you give root access to your unRAID server to someone else, of course they could destroy your system / leak your data, no hackery required, VENOM or otherwise. To state that there are "credible threats" here is like someone leaving the front door wide open and then blaming the cops for being vandalized. If you give someone access to a guest VM on unRAID 6, you are safe unless: A) You, the administrator, forcefully go into the XML and add code that was not present by default; or B) You, the administrator, give root access to your server to an untrustworthy person; or C) You, the administrator, add the exploitable code to your system, which isn't present by default. None of those are security exploits, they are examples of bad decision-making on part of the user. All of this said, it will be patched in the next release of unRAID which further makes this a non-issue. I want to mark this thread debunked because while the security threat to cloud providers / other solutions may be very real, it is NOT real to unRAID unless the user manually invokes it, which isn't something any of our tools will allow you to do by default. I want to mark it debunked also because I don't want folks to see this thread headline and have a panic attack. Quote Link to comment
pinion Posted May 13, 2015 Author Share Posted May 13, 2015 If it pleases you mark it debunked. I didn't know there were so many noobs that used the VM manager to create their instances I kid I kid! I moved to the VM manager too Quote Link to comment
archedraft Posted May 13, 2015 Share Posted May 13, 2015 I want to mark it debunked also because I don't want folks to see this thread headline and have a panic attack. Soooo you're saying I can stop putting tin foil all over my unRAID server now?? To be honest the tin foil was getting expensive. Quote Link to comment
jonp Posted May 13, 2015 Share Posted May 13, 2015 Lol! No the tin foil helps prevent bit rot ;-). Leave it exactly where it is. I needed that today. Thanks arch! Quote Link to comment
archedraft Posted May 13, 2015 Share Posted May 13, 2015 Lol! No the tin foil helps prevent bit rot ;-). Leave it exactly where it is. I needed that today. Thanks arch! lol, anytime! Quote Link to comment
pinion Posted May 13, 2015 Author Share Posted May 13, 2015 What is this bitrot you speak of? Is there a road map to have it fixed? Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.