0day.today - Biggest Exploit Database in the World.
- We use one main domain: http://0day.today
- Most of the materials is completely FREE
- If you want to purchase the exploit / get V.I.P. access or pay for any other service,
you need to buy or earn
GOLD
Administration of this site uses the official contacts. Beware of impostors!
We DO NOT use Telegram or any messengers / social networks!Please, beware of scammers!
- Read the [ agreement ]
- Read the [ Submit ] rules
- Visit the [ faq ] page
- [ Register ] profile
- Get [ GOLD ]
- If you want to [ sell ]
- If you want to [ buy ]
- If you lost [ Account ]
- Any questions [ admin@0day.today ]
- Authorisation page
- Registration page
- Restore account page
- FAQ page
- Contacts page
- Publishing rules
- Agreement page
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
Contact us
You can contact us by:
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
Faronics Deep Freeze Arbitrary Code Execution Vulnerability
Author
Risk
[Security Risk High
]0day-ID
Category
Date add
CVE
Platform
Vulnerability title: Arbitrary Code Execution In Faronics Deep Freeze Standard and Enterprise CVE: CVE-2014-2382 Vendor: Faronics Product: Deep Freeze Standard and Enterprise Affected version: Before and including v8.10 Fixed version: N/A Reported by: Kyriakos Economou Details: The latest, and earlier, versions of Deep Freeze Standard/Enterprise allow a local attacker to execute code with Kernel privileges, without the need of loading another kernel mode driver, by exploiting a vulnerability in the DfDiskLo.sys. Unsuccessful exploit attempts will lead to system crash. The vulnerability doesn't currently allow vertical privilege escalation since the driver by default only allows administrator accounts to perform an IOCTL request. We have verified and successfully exploited this vulnerability in WinXP SP3 and Win 7 SP0, both 32-bit builds. The bug is related with the way DfDiskLo.sys driver makes a call to IofCallDriver function without validating properly the parameters passed to it: MOV ESI, DWORD [ECX+8] - ECX should point to a DEVICE_OBJECT structure, which at offset 0x08 has a pointer to a DRIVER_OBJECT structure PUSH EDX PUSH ECX CALL DWORD [ESI+EAX*4+38] - here it calls the major function based on the IRP function code, the IRP function code is stored in EAX. When we send the IOCTL request, ECX is zero instead of pointing to a DEVICE_OBJECT structure, that is why we have to allocate the NULL page before triggering the bug. Once the NULL page is allocated, we can write whatever we want to address 0x08. ESI will then, instead of pointing to a legitimate DRIVER_OBJECT structure, point to an arbitrary memory location that we control. Finally, EAX holds the IRP function code, in this case IRP_MJ_DEVICE_CONTROL (0x0E). We can control the full mathematical expression [ESI+EAX*4+38] and as such we have full control over the EIP redirection. # 0day.today [2024-11-15] #