Security Research & Defense

Vulnerability hunting with Semmle QL, part 2

Tuesday, March 19, 2019

The first part of this series introduced Semmle QL, and how the Microsoft Security Response Center (MSRC) are using it to investigate variants of vulnerabilities reported to us. This post discusses an example of how we’ve been using it proactively, covering a security audit of an Azure firmware component. This was part of a wider defense in depth security review of Azure services, exploring attack vectors from the point of view of a hypothetical adversary who has already penetrated at least one security boundary, and now sits in the operating environment of a service backend (marked with * on the diagram below).

Local privilege escalation via the Windows I/O Manager: a variant finding collaboration

Thursday, March 14, 2019

The Microsoft Security Response Center (MSRC) investigates all reports of security vulnerabilities affecting Microsoft products and services to help make our customers and the global online community more secure. We appreciate the excellent vulnerability research reported to us regularly from the security community, and we consider it a privilege to work with these researchers.

Fuzzing para-virtualized devices in Hyper-V

Monday, January 28, 2019

Introduction Hyper-V is the backbone of Azure, running on its Hosts to provide efficient and fair sharing of resources, but also isolation. That’s why we, in the vulnerability research team for Windows, have been working in the background for years now helping secure Hyper-V. And why Microsoft invites security researchers across the globe to submit their vulnerabilities through the Hyper-V Bounty Program for payment of up to $250,000 USD.

First Steps in Hyper-V Research

Monday, December 10, 2018

Microsoft has put a lot of effort in Hyper-V security. Hyper-V, and the whole virtualization stack, runs at the core of many of our products: cloud computing, Windows Defender Application Guard, and technology built on top of Virtualization Based Security (VBS). Because Hyper-V is critical to so much of what we do, we want to encourage researchers to study it and tell us about the vulnerabilities they find: we even offer a $250K bounty for those who do.

Microsoft Security Servicing Criteria for Windows

Monday, September 10, 2018

One of our goals in the Microsoft Security Response Center (MSRC) is to be more transparent with security researchers and our customers on the criteria we use for determining when we intend to address a reported vulnerability through a security update. Our belief is that improving transparency on this topic helps provide clarity on how we assess risk, sets expectations for the types of vulnerabilities that we intend to service, and facilitates constructive dialogue as the threat landscape evolves over time.

Vulnerability hunting with Semmle QL, part 1

Thursday, August 16, 2018

Previously on this blog, we’ve talked about how MSRC automates the root cause analysis of vulnerabilities reported and found. After doing this, our next step is variant analysis: finding and investigating any variants of the vulnerability. It’s important that we find all such variants and patch them simultaneously, otherwise we bear the risk of these being exploited in the wild. In this post, I’d like to explain the automation we use in variant finding.

For the past year or so, we’ve been augmenting our manual code review processes with Semmle, a third-party static analysis environment. It compiles code to a relational database (the snapshot database – a combination of database and source code), which is queried using Semmle QL, a declarative, object-oriented query language designed for program analysis.

The basic workflow is that, after root cause analysis, we write queries to find code patterns that are semantically similar to the original vulnerability. Any results are triaged as usual and provided to our engineering teams for a fix to be developed. Also, the queries are placed in a central repository to be re-run periodically by MSRC and other security teams. This way, we can scale our variant finding over time and across multiple codebases.

In addition to variant analysis, we’ve been using QL proactively, in our security reviews of source code. This will be the topic of a future blog post. For now, let’s look at some real-world examples inspired by MSRC cases.

Analysis and mitigation of L1 Terminal Fault (L1TF)

Monday, August 13, 2018

In January 2018, Microsoft released an advisory and security updates for a new class of hardware vulnerabilities involving speculative execution side channels (known as Spectre and Meltdown). In this blog post, we will provide a technical analysis of a new speculative execution side channel vulnerability known as L1 Terminal Fault (L1TF) which has been assigned CVE-2018-3615 (for SGX), CVE-2018-3620 (for operating systems and SMM), and CVE-2018-3646 (for virtualization).

Announcing Changes to Microsoft’s Mitigation Bypass Bounty

Thursday, June 21, 2018

Today we’re announcing a change to the Mitigation Bypass Bounty that removes Control Flow Guard (CFG) from the set of in-scope mitigations. In this blog, we’ll provide additional background and explain why we’re making this change. Mitigation Bypass Bounty Background Microsoft started the Mitigation Bypass Bounty in 2013 with the goal of helping us improve key defense-in-depth mitigation technologies by learning about bypasses.

Draft of Microsoft Security Servicing Commitments for Windows

Tuesday, June 12, 2018

Updated September 10, 2018 The Servicing Criteria for Windows has transitioned to an official document and can be found at the link below. Microsoft thanks the members of the research community who provided feedback on the draft copy. Microsoft Security Servicing Criteria for Windows

Analysis and mitigation of speculative store bypass (CVE-2018-3639)

Monday, May 21, 2018

In January, 2018, Microsoft published an advisory and security updates for a new class of hardware vulnerabilities involving speculative execution side channels (known as Spectre and Meltdown). In this blog post, we will provide a technical analysis of an additional subclass of speculative execution side channel vulnerability known as Speculative Store Bypass (SSB) which has been assigned CVE-2018-3639.