Researcher Who Found Nvidia Bug Confirms Security Update Clears Up Driver Zero Day
Contributed by: Email on 01/07/2013 04:18 PM
[
Comments
]
Nvidia has released a new driver for its graphics cards that includes a security update for a zero-day vulnerability in the Nvidia Display Driver Service that came to light on Christmas day. UK researcher Peter Winter-Smith posted vulnerability details and an exploit to Pastebin describing a stack buffer overflow vulnerability in the service, as well as his exploit, which bypassed DEP and ASLR on Windows machines.
Winter-Smith told Threatpost today that he stands by his assertion that the issue was not particularly severe given the conditions under which the exploit would have to be carried out.
I have had a quick look at the patch and it does indeed appear to address the issue and it does so by entirely removing the endpoint over which the vulnerability could be exploited (the listening named pipe instance), Winter-Smith said. So for this particular Nvidia service, this issue should have been completely addressed. If there were other similar weaknesses within the service which could be exploited in the same fashion, these should have also been addressed by the fix.
An attacker would only be able to successfully exploit the vulnerability if they were on a machine in the same domain and firewall rules were severely relaxed, or file sharing were turned on. With local access, an attacker could elevate their privileges to root, or if the above conditions were met, could gain remote access from the same domain.
The service listens on a named pipe (\pipe\nsvr) which has a NULL DACL configured, which should mean that any logged on user or remote user in a domain context (Windows firewall/file sharing permitting) should be able to exploit this vulnerability, Winter-Smith wrote on Pastebin; the details and exploit have since been removed from his Pastebin post. The buffer overflow occurs as a result of a bad memmove operation.
Memmove operations copy data from a source location to a memory destination. Winter-Smith said the service copies data unchecked; an attacker would be able to control the source location as well as the number of bytes copied into the response buffer; an attacker would be able to leak data from the stack by overflowing it.
The memmove function copies data from one place in memory to another, and the fact that it was not properly used allowed me to both copy data critical to bypassing the Windows protections, Winter-Smith said, by copying private data in memory within the Nvidia service process into the data buffer that would be sent back to me, and trigger the vulnerability (by overwriting memory sufficient to give me full control over what the Nvidia service would try to do once the processing of my messages had completed).
He said he was unaware of any exploits in the wild.
Some friends who tested the exploit against their machine have reported that it is quite reliable, which is always a good thing if you're into writing exploits, he said. Otherwise however I've (fortunately) not heard of any reports of this issue being exploited in the wild; I didn't anticipate that I would, given the constraints on the attack vector.
Winter-Smith, formerly of NGS Software of the UK, said he did not contact Nvidia with details because the risk of exploit was low and he wanted to publicly share details in a timely manner. Nvidia is a manufacturer of graphics processing units for PCs and mobile devices; any Windows-based computer running a Nvidia GPU ran the vulnerable nvsvc32.exe service.
I still believe that this issue wasn't particularly severe. The fact that it was discovered in a big name vendor's software probably explains the unexpected level of attention it ended up receiving, Winter-Smith said. I released the original exploit since (I felt) there was something fairly elegant in the way the vulnerability lent itself to allowing a bypass of the three major operating-system based anti-exploit mechanisms in play today, rather than for any expected media attention.
Winter-Smith told Threatpost today that he stands by his assertion that the issue was not particularly severe given the conditions under which the exploit would have to be carried out.
I have had a quick look at the patch and it does indeed appear to address the issue and it does so by entirely removing the endpoint over which the vulnerability could be exploited (the listening named pipe instance), Winter-Smith said. So for this particular Nvidia service, this issue should have been completely addressed. If there were other similar weaknesses within the service which could be exploited in the same fashion, these should have also been addressed by the fix.
An attacker would only be able to successfully exploit the vulnerability if they were on a machine in the same domain and firewall rules were severely relaxed, or file sharing were turned on. With local access, an attacker could elevate their privileges to root, or if the above conditions were met, could gain remote access from the same domain.
The service listens on a named pipe (\pipe\nsvr) which has a NULL DACL configured, which should mean that any logged on user or remote user in a domain context (Windows firewall/file sharing permitting) should be able to exploit this vulnerability, Winter-Smith wrote on Pastebin; the details and exploit have since been removed from his Pastebin post. The buffer overflow occurs as a result of a bad memmove operation.
Memmove operations copy data from a source location to a memory destination. Winter-Smith said the service copies data unchecked; an attacker would be able to control the source location as well as the number of bytes copied into the response buffer; an attacker would be able to leak data from the stack by overflowing it.
The memmove function copies data from one place in memory to another, and the fact that it was not properly used allowed me to both copy data critical to bypassing the Windows protections, Winter-Smith said, by copying private data in memory within the Nvidia service process into the data buffer that would be sent back to me, and trigger the vulnerability (by overwriting memory sufficient to give me full control over what the Nvidia service would try to do once the processing of my messages had completed).
He said he was unaware of any exploits in the wild.
Some friends who tested the exploit against their machine have reported that it is quite reliable, which is always a good thing if you're into writing exploits, he said. Otherwise however I've (fortunately) not heard of any reports of this issue being exploited in the wild; I didn't anticipate that I would, given the constraints on the attack vector.
Winter-Smith, formerly of NGS Software of the UK, said he did not contact Nvidia with details because the risk of exploit was low and he wanted to publicly share details in a timely manner. Nvidia is a manufacturer of graphics processing units for PCs and mobile devices; any Windows-based computer running a Nvidia GPU ran the vulnerable nvsvc32.exe service.
I still believe that this issue wasn't particularly severe. The fact that it was discovered in a big name vendor's software probably explains the unexpected level of attention it ended up receiving, Winter-Smith said. I released the original exploit since (I felt) there was something fairly elegant in the way the vulnerability lent itself to allowing a bypass of the three major operating-system based anti-exploit mechanisms in play today, rather than for any expected media attention.
Comments
