Skip to main content
MSRC

Secure Development

Security Analysis of CHERI ISA

Wednesday, October 14, 2020

Is it possible to get to a state where memory safety issues would be deterministically mitigated? Our quest to mitigate memory corruption vulnerabilities led us to examine CHERI (Capability Hardware Enhanced RISC Instructions), which provides memory protection features against many exploited vulnerabilities, or in other words, an architectural solution that breaks exploits.

Control Flow Guard for Clang/LLVM and Rust

Monday, August 17, 2020

As part of our ongoing efforts towards safer systems programming, we’re pleased to announce that Windows Control Flow Guard (CFG) support is now available in the Clang C/C++ compiler and Rust. What is Control Flow Guard? CFG is a platform security technology designed to enforce control flow integrity. It has been available since Windows 8.

Using Rust in Windows

Thursday, November 07, 2019

This Saturday 9th of November, there will be a keynote from Microsoft engineers Ryan Levick and Sebastian Fernandez at RustFest Barcelona. They will be talking about why Microsoft is exploring Rust adoption, some of the challenges we’ve faced in this process, and the future of Rust adoption in Microsoft. If you want to talk with some of the people working on how Microsoft is evolving its code practices for better security, be sure to attend the keynote and talk to Ryan and Sebastian afterwards!

An intern's experience with Rust

Wednesday, October 16, 2019

Over the course of my internship at the Microsoft Security Response Center (MSRC), I worked on the safe systems programming languages (SSPL) team to promote safer languages for systems programming where runtime overhead is important, as outlined in this blog. My job was to port a security critical network processing agent into Rust to eliminate the memory safety bugs that had plagued it.

Designing a COM library for Rust

Tuesday, October 08, 2019

I interned with Microsoft as a Software Engineering Intern in the MSRC UK team in Cheltenham this past summer. I worked in the Safe Systems Programming Language (SSPL) group, which explores safe programming languages as a proactive measure against memory-safety related vulnerabilities. This blog post describes the project that I have been working on under the mentorship of the SSPL team.

Calling all breakers & builders: BlueHat Seattle registration is open!

Monday, September 16, 2019

@TODO: Exciting changes are coming to BlueHat Seattle 2019! If you’d like to attend this premier security conference, we have good news for you: registration for BlueHat Seattle is now open and we hope you register. Wait, isn’t BlueHat invitation-only? It is…but if we haven’t sent you an invitation, we encourage you to request a seat.

Why Rust for safe systems programming

Monday, July 22, 2019

In this series, we have explored the need for proactive measures to eliminate a class of vulnerabilities and walked through some examples of memory safety issues we’ve found in Microsoft code that could have been avoided with a different language. Now we’ll peek at why we think that Rust represents the best alternative to C and C++ currently available.

We need a safer systems programming language

Thursday, July 18, 2019

In our first post in this series, we discussed the need for proactively addressing memory safety issues. Tools and guidance are demonstrably not preventing this class of vulnerabilities; memory safety issues have represented almost the same proportion of vulnerabilities assigned a CVE for over a decade. We feel that using memory-safe languages will mitigate this in ways that tools and training have not been able to.

A proactive approach to more secure code

Tuesday, July 16, 2019

What if we could eliminate an entire class of vulnerabilities before they ever happened? Since 2004, the Microsoft Security Response Centre (MSRC) has triaged every reported Microsoft security vulnerability. From all that triage one astonishing fact sticks out: as Matt Miller discussed in his 2019 presentation at BlueHat IL, the majority of vulnerabilities fixed and with a CVE assigned are caused by developers inadvertently inserting memory corruption bugs into their C and C++ code.