On 18 Jun 2006 13:02:01 -0000, co296@xxxxxxx <co296@xxxxxxx> wrote:
Credit's : n00b email : co296@xxxxxxx Erm was wondering if you could take a close look at this it is a 0day dos exploit by me i found tonight in vmware i have even debug for you guy's to take a look at.I hope you guy's will put it up after checking through it.Ok the first thing is vmware use's.vmx file's as like config file's the problem as follows in vmx file's we have to change the name of our file.iso Following line's ide1:0.fileName = but if wee change it to the following it will cause a d0s and vmware will have to be shut down and rebooted.The file has an overly long file name as follows
[snip] Anyone with access to the .vmx config file for a virtual machine has control over that virtual machine and is unavoidably able to make it fail in a number of other ways. A user could attempt to boot a 3rd-party virtual machine with a specially crafted .vmx file while running other (potentially mission-critical) virtual machines, and in crashing VMware would terminate those other virtual machines--consequently this is a quite legitimate security issue, albeit a non-critical one (as the generally accepted practice of not running noncritical applications alongside critical ones prevents exploitation, and DoS of a virtualization environment pending application restart is far short of a disastrous condition). However, do you (or does anyone) know if it is possible to make a specially crafted .vmx file along similar lines to exploit this buffer overflow in such a way as to execute arbitrary code as the user running VMware? If that were possible, that would make this vulnerability much more critical. -Eliah
