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.
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.
Wednesday, April 29, 2020
Our team, DeisLabs, recently released a new piece of software called Krustlet, which is a tool for running WebAssembly modules on the popular, open-source container management tool called Kubernetes. Kubernetes is used quite extensively to run cloud software across many vendors and companies and is primarily written in the Go programming language.
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!
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.
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.
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.
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.
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.
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.
