Alex Rebert
Alex Rebert is a Senior Staff Software Engineer leading memory safety in the Information Security Engineering organization, whose goal is to keep Google’s products secure and users safe.
Before Google, Alex co-founded ForAllSecure to help companies find unknown vulnerabilities, where he led the team that created Mayhem, an autonomous agent that could find, exploit, and patch vulnerabilities. Mayhem won the DARPA Cyber Grand Challenge in 2016. Alex was named one of MIT Tech Review's 35 Innovators Under 35 and Forbes' 30 Under 30.
Before Google, Alex co-founded ForAllSecure to help companies find unknown vulnerabilities, where he led the team that created Mayhem, an autonomous agent that could find, exploit, and patch vulnerabilities. Mayhem won the DARPA Cyber Grand Challenge in 2016. Alex was named one of MIT Tech Review's 35 Innovators Under 35 and Forbes' 30 Under 30.
Research Areas
Authored Publications
Sort By
Preview abstract
For decades, memory safety vulnerabilities have been a stubborn and seemingly unavoidable risk of systems software development. But that long-held view is now shifting. Driven by the success of memory-safe languages, and reinforced by calls to action from government agencies, the industry is recognizing that taking on this risk is no longer necessary.
Vulnerabilities, once an inevitability of systems programming, should increasingly be seen as a deliberate choice. Fortunately, data demonstrates that making a better choice does not require daunting multi-year rewrites of existing codebases. We can dramatically improve security by incrementally shifting the development of just new code to memory safe languages. And if these vulnerabilities can be avoided with low impact on other development goals, then choosing to introduce new ones should increasingly be considered unacceptable, and our goal should be for vulnerabilities to become increasingly impossible to introduce.
As James Clear says, “You do not rise to the level of your goals, you fall to the level of your systems.” A goal without a system is merely a wish. Transitioning even new development within a codebase to a new language is a complex undertaking, but it is solvable. This article lays out an empirically effective system, covering not only why this shift is so powerful but also a practical, staged process you can use to make it happen.
View details
Preview abstract
We document the work required to roll out Hardened Libc++ across Google, including collaboration with Apple on the implementation. We discuss the requirements for hardening, the benefits of rolling out to production instead of pre-production environments. Lastly, we discuss the bugs found, the performance work required to make such a change, and the lasting impact.
View details
Preview abstract
2022 marked the 50th anniversary of memory safety vulnerabilities, first reported by Anderson et al. Half a century later, we are still dealing with memory safety bugs despite substantial investments to improve memory unsafe languages.
Like others', Google’s data and internal vulnerability research show that memory safety bugs are widespread and one of the leading causes of vulnerabilities in memory-unsafe codebases. Those vulnerabilities endanger end users, our industry, and the broader society.
At Google, we have decades of experience addressing, at scale, large classes of vulnerabilities that were once similarly prevalent as memory safety issues. Based on this experience we expect that high assurance memory safety can only be achieved via a Secure-by-Design approach centered around comprehensive adoption of languages with rigorous memory safety guarantees.
We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees that include temporal safety. As a consequence, we are considering a gradual transition of C++ code at Google towards other languages that are memory safe.
Given the large volume of pre-existing C++, we believe it is nonetheless necessary to improve the safety of C++ to the extent practicable. We are considering transitioning to a safer C++ subset, augmented with hardware security features like MTE.
View details
