Kurt Seifried (kseifried) reports: While looking at various components for Storage I ran across some tmp file issues in vdsm: ./vdsm/SecureXMLRPCServer.py: make -C /etc/pki/tls/certs /tmp/selfsign.pem ./vdsm/storage/storageServer.py: localPathBase = "/tmp" ./vdsm/utils.py: MONITORED_PATHS = ['/tmp', '/var/log', '/var/log/core', ./vdsm/API.py: 'No space on /tmp?'}} ./vdsm/API.py: 'No space on /tmp? ' + e.message}} ./vdsm/sos/vdsm.py.in: self.addCopySpec("/tmp/vds_installer*") ./vdsm/sos/vdsm.py.in: self.addCopySpec("/tmp/vds_bootstrap*") ./vdsm/libvirtvm.py: <kernel>/tmp/vmlinuz-2.6.18</kernel> ./vdsm/libvirtvm.py: <initrd>/tmp/initrd-2.6.18.img</initrd> ./vdsm/libvirtvm.py: <source mode='bind' path='/tmp/socket'/> ./vdsm_hooks/scratchpad/before_vm_start.py: scratchpad=20G,/tmp/myimg ./vdsm_hooks/scratchpad/before_vm_start.py: scratchpad=20G,/tmp/disk1,1T,/tmp/disk2 ./vds_bootstrap/miniyum.py: extraLog = open("/tmp/miniyum.log", "a") ./configure:# creating and moving files from /tmp can sometimes cause problems. ./configure:# creating and moving files from /tmp can sometimes cause problems. ./build-aux/install-sh: tmpdir=${TMPDIR-/tmp}/ins$RANDOM-$$ ./build-aux/py-compile: py-compile --destdir /tmp/pkg-root --basedir /usr/share/test test.py test2.py ./vdsm_reg/deployUtil.py.in:_WORK_DIR = "/tmp" # hardcoded as server use it as-is ./vdsm_reg/save-config: rm -f /tmp/save.out ./vdsm_reg/save-config: ovirt_store_config $1 > /tmp/save.out 2>&1 ./vdsm_reg/save-config: cat /tmp/save.out
./vdsm/SecureXMLRPCServer.py: make -C /etc/pki/tls/certs /tmp/selfsign.pem comment ./vdsm/storage/storageServer.py: localPathBase = "/tmp" not being used, but should be fixed. ./vdsm/utils.py: MONITORED_PATHS = ['/tmp', '/var/log', '/var/log/core', harmless monitoring *against* /tmp malicious behavior. ./vdsm/API.py: 'No space on /tmp?'}} ./vdsm/API.py: 'No space on /tmp? ' + e.message}} comments ./vdsm/sos/vdsm.py.in: self.addCopySpec("/tmp/vds_installer*") ./vdsm/sos/vdsm.py.in: self.addCopySpec("/tmp/vds_bootstrap*") no need to fix, collection of deprecated logs. ./vdsm/libvirtvm.py: <kernel>/tmp/vmlinuz-2.6.18</kernel> ./vdsm/libvirtvm.py: <initrd>/tmp/initrd-2.6.18.img</initrd> ./vdsm/libvirtvm.py: <source mode='bind' path='/tmp/socket'/> ./vdsm_hooks/scratchpad/before_vm_start.py: scratchpad=20G,/tmp/myimg ./vdsm_hooks/scratchpad/before_vm_start.py: scratchpad=20G,/tmp/disk1,1T,/tmp/disk2 comments ./vds_bootstrap/miniyum.py: extraLog = open("/tmp/miniyum.log", "a") please do not fix, deprecated means of installation ./configure:# creating and moving files from /tmp can sometimes cause problems. ./configure:# creating and moving files from /tmp can sometimes cause problems. comments ./build-aux/install-sh: tmpdir=${TMPDIR-/tmp}/ins$RANDOM-$$ no real problem in autobuild, $RANDOM in use. ./build-aux/py-compile: py-compile --destdir /tmp/pkg-root --basedir /usr/share/test test.py test2.py comment ./vdsm_reg/deployUtil.py.in:_WORK_DIR = "/tmp" # hardcoded as server use it as-is please do not touch, deprecated means of installation ./vdsm_reg/save-config: rm -f /tmp/save.out ./vdsm_reg/save-config: ovirt_store_config $1 > /tmp/save.out 2>&1 ./vdsm_reg/save-config: cat /tmp/save.out Effective only in ovirt-node, where /tmp is not accessible by untrusted users. I suggest to fix by dumping vdsm-reg. Bottom line: only two non-urgent issues to tackle: ./vdsm/storage/storageServer.py: localPathBase = "/tmp" ./vdsm_reg/save-config: rm -f /tmp/save.out
I don't have access to the CVE details but I took the liberty of pointing out what those code excerpts mean so you could make a decision about how it affects VSDM. // This is just code for testing that generates a self signed crt. VDSM doesn't use it during normal operation ./vdsm/SecureXMLRPCServer.py: make -C /etc/pki/tls/certs /tmp/selfsign.pem // This is the default and we change it in hsm.py // storageServer.MountConnection.setLocalPathBase(mountBasePath) ./vdsm/storage/storageServer.py: localPathBase = "/tmp" // This is for reporting free space for tmp files logs and core dumps. ./vdsm/utils.py: MONITORED_PATHS = ['/tmp', '/var/log', '/var/log/core', // We put disk images in a subdirectory with appropriate permissions ./vdsm/API.py: 'No space on /tmp?'}} ./vdsm/API.py: 'No space on /tmp? ' + e.message}} // This is when an SOS report is being formed and we make sure it never contains sensitive data ./vdsm/sos/vdsm.py.in: self.addCopySpec("/tmp/vds_installer*") ./vdsm/sos/vdsm.py.in: self.addCopySpec("/tmp/vds_bootstrap*") // This is an example tests documentation ./vdsm/libvirtvm.py: <kernel>/tmp/vmlinuz-2.6.18</kernel> ./vdsm/libvirtvm.py: <initrd>/tmp/initrd-2.6.18.img</initrd> ./vdsm/libvirtvm.py: <source mode='bind' path='/tmp/socket'/> // This is documentation as well ./vdsm_hooks/scratchpad/before_vm_start.py: scratchpad=20G,/tmp/myimg ./vdsm_hooks/scratchpad/before_vm_start.py: scratchpad=20G,/tmp/disk1,1T,/tmp/disk2 // This is bootstrep log and doesn't contain sensitive data ./vds_bootstrap/miniyum.py: extraLog = open("/tmp/miniyum.log", "a") // Documentation and this is the build process ./configure:# creating and moving files from /tmp can sometimes cause problems. ./configure:# creating and moving files from /tmp can sometimes cause problems. ./build-aux/install-sh: tmpdir=${TMPDIR-/tmp}/ins$RANDOM-$$ ./build-aux/py-compile: py-compile --destdir /tmp/pkg-root --basedir /usr/share/test test.py test2.py // This is for deployment scripts ./vdsm_reg/deployUtil.py.in:_WORK_DIR = "/tmp" # hardcoded as server use it as-is ./vdsm_reg/save-config: rm -f /tmp/save.out ./vdsm_reg/save-config: ovirt_store_config $1 > /tmp/save.out 2>&1 ./vdsm_reg/save-config: cat /tmp/save.out
So things like: // This is bootstrep log and doesn't contain sensitive data ./vds_bootstrap/miniyum.py: extraLog = open("/tmp/miniyum.log", "a") can be used for symlink attacks. So it would appear that at least some of these are exploitable.
> ./vds_bootstrap/miniyum.py: extraLog = open("/tmp/miniyum.log", "a") > please do not fix, deprecated means of installation this is only used for testing... it is part of test main.
I agree that any fix for vdsm-reg is to done when dropping the component, whenever I reach this task it eludes me, however I agree that these related to vdsm-reg are minor as the rhev-h/ovirt-node is accessible only for the server sysadmin, and he has much better ways to attack self.
Statement: Red Hat Storage 2 is now in Extended Life Cycle phase of the support and maintenance life cycle. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/site/support/policy/updates/rhs