CppCon 2018

Computer systems are under siege 24 hours a day, day in and day out. The critical security infrastructure designed to protect those systems, won't:

* Perimeter security won't protect you.
* Network analytics won't protect you.
* Virus scanners won't protect you.
* Even the users who should know better than to click on that too-good-to-be-true offer won't protect you.

The other side has the best security hardware and software systems other people's money can buy and they have all the time in the world to find creative ways to defeat them. Meltdown and Spectre are prime examples of security vulnerabilities that have lurked dormant for decades. Or have they? If your systems are in any way connected to the outside world, the other side will get inside the wire on you. Know that going in.

Whether you write applications, libraries or work in kernel code, the line of code you write today may very well be the vulnerability someone else finds tomorrow. By nature every code base contains hundreds of attack surfaces and it only takes one serious vulnerability to compromise your system.

While Modern C++ is designed to be secure, the ways we use it often aren't.


In part one of this talk we'll see:

* How hackers think and how they identify weaknesses in our systems.
* How to identify hidden attack surfaces, attack vectors and vulnerabilities in critical systems.
* Where the most common vulnerabilities in Modern and classic C++ are and how to avoid them.
* Why avoiding parts of the language doesn't help.
* Where we can trade off security for performance.

At the end of part one, we'll do a walkthrough of a classic buffer overflow exploit to see how it works and what we've added to the operating systems and compilers to protect against them. Then we'll use it live to run a privilege escalation exploit and gain admin access on a system.


In part two, we'll see:

* Why common guidelines and static analysis tools often fail to find vulnerabilities.
* How to use Threat Modeling to analyze complex systems and build security into our systems at design time.
* How to use Trust Boundaries to protect critical infrastructure.
* Why open source and third-party libraries are fast becoming hidden liabilities in our software and how to protect ourselves against their vulnerabilities.
* What the best practices for protecting our code from attack are.

At the end of part two, we'll do a walkthrough of an exploit that can be successful today in spite of the safe guards built into our operating systems and compilers. Then, as before, we'll use it live to penetrate a system.


The critical security infrastructure designed to protect your systems is largely out of your control. The one thing you can control is the next line of code you write. This talk is for anyone that uses C++ or Modern C++ for kernel, applications or libraries that run in the real-world and that face real-world attacks.

In today's world, that's all of us.

Computer systems are under siege 24 hours a day, day in and day out. The critical security infrastructure designed to protect those systems, won't:

* Perimeter security won't protect you.
* Network analytics won't protect you.
* Virus scanners won't protect you.
* Even the users who should know better than to click on that too-good-to-be-true offer won't protect you.

The other side has the best security hardware and software systems other people's money can buy and they have all the time in the world to find creative ways to defeat them. Meltdown and Spectre are prime examples of security vulnerabilities that have lurked dormant for decades. Or have they? If your systems are in any way connected to the outside world, the other side will get inside the wire on you. Know that going in.

Whether you write applications, libraries or work in kernel code, the line of code you write today may very well be the vulnerability someone else finds tomorrow. By nature every code base contains hundreds of attack surfaces and it only takes one serious vulnerability to compromise your system.

While Modern C++ is designed to be secure, the ways we use it often aren't.


In part one of this talk we'll see:

* How hackers think and how they identify weaknesses in our systems.
* How to identify hidden attack surfaces, attack vectors and vulnerabilities in critical systems.
* Where the most common vulnerabilities in Modern and classic C++ are and how to avoid them.
* Why avoiding parts of the language doesn't help.
* Where we can trade off security for performance.

At the end of part one, we'll do a walkthrough of a classic buffer overflow exploit to see how it works and what we've added to the operating systems and compilers to protect against them. Then we'll use it live to run a privilege escalation exploit and gain admin access on a system.


In part two, we'll see:

* Why common guidelines and static analysis tools often fail to find vulnerabilities.
* How to use Threat Modeling to analyze complex systems and built security into our systems at design time.
* How to use Trust Boundaries to protect critical infrastructure.
* Why open source and third-party libraries are fast becoming hidden liabilities in our software and how to protect ourselves against their vulnerabilities.
* What the best practices for protecting our code from attack are.

At the end of part two, we'll do a walkthrough of an exploit that can be successful today in spite of the safe guards built into our operating systems and compilers. Then, as before, we'll use it live to penetrate a system.


The critical security infrastructure designed to protect your systems is largely out of your control. The one thing you can control is the next line of code you write. This talk is for anyone that uses C++ or Modern C++ for kernel, applications or libraries that run in the real-world and that face real-world attacks.

In today's world, that's all of us.

From experience we have learned that almost any surface we expose could have weaknesses. We have to have a plan on how to deal with issues as they arise, and an architecture that allows us to correct and protect in products that are already in use. When security is lifted up to the discretion of the user, however, we often fail to inform their decision properly. The usability of security and the architecture of fixability are closely connected, and both need continued refinement and focus. This talk will describe architectural and organizational features that make it easier to make corrective measures. They are down-to-earth everyday scenarios, illustrated by real world software projects and security incidents. Some of the stories are well known, some are anonymized to protect the innocent. Finally we will show examples of how difficult it is to design the user experience of security.

What does a vulnerability using signed integer overflow look like? Or a stack buffer overflow? How does code like this look and how can we change the way we program to reduce our risk? The first half of this talk will show examples of many different vulnerabilities and describe how these are combined to make the first steps of an exploit. Then we will discuss what kind of programming practices we can employ to reduce the chances of these kinds of bugs creeping into our code.

Most computer languages, including C++, cannot guarantee that an integer expression will not produce a incorrect arithmetic result.

This fact is documented in numerous books, articles and conference presentations such as CPPCon. These presentations give good explanations of the problem and it's causes. But they are short on specific practical strategies to address the problem. The Boost.SafeNumerics library addresses this problem through C++ techniques such as operator overloading, template meta-programming. This library can be used to write C or C++ code guaranteed not to produce erroneous arithmetic results. In many cases, this guarantee can be made without adding any run-time overhead.

This presentation will

* illustrate some common problems such as integer overflows and type conversions.
* illustrate how the library can be used to address these problems.
* describe in general terms what the library does and how it works.
* describe the library API in some detail.
* present a case study applying the library to embedded motor controller written in C.

In the talk, I will present a new C++17 library for multi-precision arithmetic for integers in the order of 100--500 bits. Many cryptographic schemes and applications, like elliptic-curve encryption schemes and secure multiparty computation frameworks require multiprecision arithmetic with integers whose bit-lengths lie in that range.

The library is written in “optimizing-compiler-friendly” C++, with an emphasis on the use of fixed-size arrays and particular function-argument-passing styles (including the avoidance of naked pointers) to allow the limbs to be allocated on the stack or even in registers. Depending on the particular functionality, we get close to, or significantly beat the performance of existing libraries for multiprecision arithmetic that employ hand-optimized assembly code.

Beyond the favorable runtime performance, our library is, to the best of the author’s knowledge, the first library that offers big-integer computations during compile-time. For example, when implementing finite-field arithmetic with a fixed modulus, this feature enables the automatic precomputation (at compile time) of the special modulus- dependent constants required for Barrett and Montgomery reduction. Another application is to parse (at compile-time) a base-10-encoded big-integer literal.

In this talk, I will focus on some Modern C++ language features that I've used to write the library and design its API (e.g., std::array, variadic templates, std::integer_sequence, constexpr, user-defined literals, using-declarations and decltype, and combinations thereof). Also, I will show some benchmarks, and will argue that the integer types offered by the library compose well with STL containers or other libraries (like Eigen for matrix/linear algebra operations).

I will also present some results on formal verification of correctness and the "constant-time" property:
- Correctness is verified using a tool named SAW (Software Analysis Workbench), which tries to prove equivalence between the compiled C++ code (represented as LLVM bitcode) and a behavioral specification given in a high-level functional language;
- "Constant-timeness" is a property that is crucial for implementations of cryptographic protocols to prevent timing attacks. In particular, I succeeded to verify my C++ code with "ct-verif", a tool for verifying the constant-time property for C programs (which was, in its original form, incompatible with C++ due to usage of non-ANSI C in one of its header files)

The library is on Github (Apache 2 licensed)
https://github.com/niekbouman/ctbignum

This session will feature four panelists who have extensive experience in designing systems that have to work securely in an insecure world. Two of the panelists have multiple decades defending everything from operating systems to networks to sensitive military systems from attackers.

In spite of more than 40 years of programming practice, we still make even the most basic errors of API design and coding: integer overflow, error-prone floating point arithmetic, unconstrained/flawed templated interfaces.
A few such examples from Boost, the C++17 standard and a discussion on generic and metaprogramming issues will illustrate why we need to focus more on quality and less on quantity.
When the most basic building blocks offer few or no guarantees on the validity of their results, the task of writing correct programs becomes a lot more difficult. At the same time, the standard library is not providing some essential primitives that would make writing correct code easier and with better performance characteristics.
The presentation will also include a surprise guest from the functional programming languages family.

The discovery of speculative execution side-channel attacks (called "Spectre") fundamentally changes the security model of every modern superscalar microprocessor. Extracting secret data (credit cards, cryptographic keys) through side-channels is not new and has challenged the cryptographic community for decades. Despite this, the industry has often been complacent in our response, viewing these attacks as impacting a tiny amount of code and being nearly impossible to weaponize. But speculative execution attack techniques have fundamentally altered the ease and applicability of side-channels, making them a serious threat to computer security. Responding to these issues has impacted CPU design, compiler design, library design, sandbox techniques and even the C++ programming language and standard.

This talk will explain how these kinds of attacks work at a high level and provide a clear set of terminology to describe these classes of vulnerabilities and attacks. It will show how the different variants work at the low level of modern hardware to give a detailed and precise understanding of the mechanics involved on CPUs today.

It will also provide guidance about what makes applications and services vulnerable and how to analyze your software to understand the degree of its exposure. It will include an overview of the numerous different mitigation techniques available, how to deploy them, and what tradeoffs come with them. Some of these mitigations will be covered in detail: how they work at a hardware level, where they don't work, and what attack vectors remain.

Finally, the talk will show how traditional side-channel risks are made substantially easier to exploit due to speculative execution. This will cover how cryptographic and other libraries dealing in high-value secrets need to be adapted to correctly defend against these attacks. Further, it will introduce general problems of sandboxing untrusted code from secret data and the current best techniques in those circumstances.

This talk will be accessible to most C and C++ programmers. No deep background on CPUs, assembly, hardware instructions, Spectre, side-channels, or security is needed.

This panel will consist of three experts from across the industry who have been working on and responding to Spectre, a new class of information leak vulnerability in modern CPUs and software. It will cover any and all questions the audience has about this new class of vulnerabilities, how they work, what it means for you, and what you can do about them.