Skip to content ↓ | Skip to navigation ↓

Back in March, I headed down to Alpharetta, GA to spend time with the American half of our Vulnerability and Exposure Research Team (VERT). While the Sunday travel was a nightmare (issues with customs, car rental and hotel), the week proved to be incredibly valuable.

Just prior to my trip, a customer had complained that they had a laptop that was crashing whenever it was scanned with Tripwire IP360. Given the non-invasive nature of our product, this indicated one of two things: We’d made a mistake with new content or our product had inadvertently discovered a new vulnerability.

Given our process of triple-checking for scan interaction issues prior to shipping and a history of identifying new vulnerabilities via IP360, I figured that this was the most likely scenario and had our support team gather data from the customer. It just so happened that this “data” included a laptop exhibiting the issue that arrived at our Alpharetta office the day before I arrived.

This gave those of us on-site a unique project, the rare situation where your hobby and your job overlap one hundred percent and you feel like you’re the Hardy Boys or Nancy Drew solving the world’s greatest mystery. As a team, we tackled the problem reproducing the crash and then working our way through the scan process, packet by packet.

We quickly determined that Remote Desktop was the culprit but that begged the question, “Why doesn’t this happen on all systems running RDP?”

A couple members of the team quickly produced a proof of concept python script allowing us to streamline our testing while another team member dove into the memory dump. We looked at the software installed on the laptop and the data from the memory dump and all indicators screamed video drivers. We uninstalled the drivers, rebooted, and … success! The BSOD had been averted. Reinstalling the drivers once again caused the issue to return.

We debated on the correct point of contact at this point, Microsoft or the video card manufacturer, NVIDIA. Ultimately, we decided to start at the base of the pyramid and work our way up, and we contacted Microsoft on March 14, 2016. Multiple emails were exchanged over the next 48 hours, followed by silence while Microsoft investigated.

We contacted Microsoft again on April 7, 2016, and discovered that they could not reproduce the issue and that they had determined the issue to be with the driver, suggesting that we expand the conversation. That same day, we submitted information to NVIDIA.

Contact with NVIDIA continued throughout April and we also informed Lenovo PSIRT of the issue, providing them with details. May was met with silence, so in June, we followed up with NVIDIA – they apologized for the lack of an update, provided the CVE (CVE-2016-4959) for the issue and mentioned that they were planning on publishing a fix.

On June 20, VERT was provided with a timeline for the fix and agreed to work with NVIDIA to responsibly disclose the issue. NVIDIA’s advisory on the publication can be found here.

In the end, it’s worth stating that it’s absolutely amazing to spend a decade working with a product that, while not its intended purpose, can find new vulnerabilities in major products. It was a pleasure to work with NVIDIA on this and, given some of the poor examples of responsiveness we’ve seen from security teams, it was great to see how responsive they were.