For the fourth time in a row, we’ve followed Pass the SALT, a small but high quality, three days, conference dedicated to free software and security. This edition, that we sponsored, hosted 26 talks covering 9 Security topics (Secure Messaging, DFIR & TI, HW & Embedded, Network etc), but also 6 workshops with top-notch speakers (and attendees of course).
Here are all the slides and videos of the talks and rumps.
And as usual, you can find a quick review of our favourite talks.
The Last Resort: Debugging Embedded Systems with Unconventional Methods - Vincent Lopes
This talk from Vincent Lopes goes into his implementation of a hardware debugger on an embedded system and what we can learn from it.
Vincent first introduces the different types of software that can be found on embedded systems. These are bare metal software, real time operating systems (RTOS) and general purpose OSes. The method presented was more relevant to Baremetal and RTOS.
Then, he talked about how debuggers can help with dynamic reverse engineering and explained the difference between software and hardware debuggers. Embedded systems can generally be debugged thanks to hardware debuggers via JTAG or other proprietary protocols, but these are often disabled in production systems, which makes debugging more complicated.
Vincent detailed his solution which is applicable when it’s possible to patch the firmware. During his talk, he took a chip with the ARMv6-M ISA as an example. However, he focused more on the general methodology. The implementation of the solution is specific to the architecture, as every architecture has its own specificities related to its registers, the handling of interrupts, etc.
An overview of his implementation is the following:
First, using a protocol to communicate between the microcontroller and the computer during the debugging, for this he wrote a custom gdb extension and chose not to use gdb remote serial protocol.
Writing a debug handler that will be embedded in the patched firmware. The debug handler will be called when an interrupt related to debugging is triggered.
The debug handler will need to be written in assembly, this allows to avoid the compiler doing something unexpected and allows for full control and optimisation of the debug handler. The handler should do several things such as saving the registers, disabling interrupts, communicating with gdb etc.
Using a custom gdbserver to interface gdb with the custom debugging protocol, for this, Vincent used minigdbstub.
This methodology is adaptable to several different use cases and has the benefit, in general, of having a lightweight implementation.
Matrix French gov deployment: opening a private federation securely - Mathieu Velten, Yoan Pintas
Mathieu and Yoan talked about the implementation and deployment of Tchap. Tchap is an open source messaging platform for the French public sector that is based on Matrix.
The Matrix protocol is a secure and open source protocol for communications including instant messaging. With Matrix, anyone can host a public Matrix server or join by making an account on the main server.
Tchap is more than just a Matrix fork. It has its own specific characteristics. It is a closed federation as not anyone can join and is mostly for people in the public sector. Users from the private sector can be invited and join the federation with several restrictions. Tchap also includes some other features such as an antivirus.
Mathieu and Yoan highlighted that user impersonation is a big challenge on Matrix which significantly influenced Tchap’s design. Their aspirations included making it safe and possible to connect to trusted third parties by slowly opening Tchap’s federation. This would allow, for instance, to connect with French local authorities who host their own nodes.
Wirego, a Wireshark plugin development framework - Benoit Girard
This talk by Benoit Girard talked about Wirego, a plugin development framework for wireshark.
Writing a Wireshark plugin can be useful, for example to reverse engineer a network protocol. Wireshark currently supports writing plugins in C and Lua. Benoit highlighted that these choices are limited and that Lua could lack useful libraries, this motivated him to write his own tool: Wirego.
Wirego can be added to Wireshark as a plugin. It acts as a bridge that allows writing additional plugins in any language. Wirego provides APIs for different languages and a communication layer based on a MQ channel.
Putting pacman in jail: a sandboxing story - Rémi Gacogne
This talk from Rémi Gacogne goes into the addition of security features in the Pacman package manager used in Arch linux.
Pacman runs as root in a memory unsafe language and deals with untrusted content, which can lead to security issues. With this in mind, Rémi focused on a way to sandbox the package manager, highlighting that only the installation phase requires elevated privileges.
The sandboxing involved the usage of seccomp to restrict system calls and Landlock to restrict file system accesses along with the creation of a child process for less privileged actions. Even though the first proof of concept was done quickly, a lot of effort and time was necessary to ensure that the patch didn’t introduce regressions and was compatible with the multitude of different user’s workflows. This talk highlights the complexity of implementing a sandbox after the initial design.
Fun with flags: How Compilers Break and Fix Constant-Time Code - Antoine Geimer
This talk from Antoine Geimer was about the impact of compilers on constant-time code.
He first reminded us that side channels are side effects of a program’s execution that can be exploited by an attacker to reveal secret information. One side effect is a difference in timing depending on the user input or the secret data being accessed. A common solution, but difficult to implement, is to have sensitive operations running in constant time. This means that the time it takes for an operation to complete is independent of sensitive data.
He then explained that because the hardware causes are unlikely to be fixed, developers should implement software countermeasures to avoid side-channel attacks. To do this, the code should be implemented using constant-time programming practices. For example, by ensuring that no secret-dependent branches or memory accesses occur.
Even if a developer respects constant-time programming practices, compilers’ optimizations can induce involuntary constant-time violations. Antoine highlighted that there are many variations depending on the compiler, which makes it difficult to predict the output and ensure that there’s no compiler-induced constant time violation.
An example of code that respects constant time programming was presented during the talk. For this specific example, GCC kept the constant time guarantee, but LLVM optimized and added a conditional jump, introducing a constant time (CT) violation.
Antoine then explained what motivated his research, the research questions, and the methodologies behind his research. His goal was to understand how to detect compiler-introduced constant-time violations, what compiler optimization introduces them and what we can do to prevent it while preserving performance. The approach uses differential testing, where the same source code is compiled with different compilers and options. Running the same constant-time detection tool on every output binary allowed him to see what compiler, compiler-option, and optimization pass introduced CT violations. The CT violation detection was done dynamically via the tool microwalk, and manually using tools such as Compiler Explorer.
His research allowed him to reduce the number of compiler-introduced CT violations while limiting the impact on performance. His paper was recently submitted and is currently available on arXiv.
I think the following elements are worth noting:
- Upgrades in a compiler can bring an increase in CT violations.
- Different compilers can break constant time in different ways.
- Some compiler flags, useful to reduce CT violations are not documented.
- The work on limiting compiler-introduced CT violations is still ongoing.
Analyzing Microarchitectural Side-Channel Attacks Using Open-source gem5 simulator - Mahreen Khan
In this talk, Mahreen Khan goes into her research about the evaluation of side-channel attacks on the RISC-V platform.
Mahreen explained that even if software were to be completely bug-free, hardware vulnerabilities and side-channel attacks could still be exploited. For this reason, she focused on microarchitectural side-channel attacks, which are specific to the hardware.
Microarchitecture side channels can be caused by speculative execution, cache hierarchy implementation, and branch prediction. These modern components of CPU design improve the performance but can introduce security vulnerabilities such as the commonly known Spectre and Meltdown.
The RISC-V architecture was chosen in her analysis because she believes that it’s an architecture that is forecasted to be widely deployed but lacks a mature security analysis. Additionally, the modular design of the architecture is subjected to not thoroughly verified custom RISC-V extensions.
Mahreen then shows how she aimed to bridge the research gap by providing an open-source virtual platform dedicated to RISC-V security research to test microarchitectural attacks and defenses. Several virtualization systems were considered for attack assessment such as QEMU, Spike and the Verilog simulator. In the end, gem5 was chosen for its good tradeoff between accuracy and speed.
As a result, she focused mainly on flush-fault attack analysis using the gem5 simulator. Flush-fault attacks are cache-based side-channel attacks, which imply manipulating the cache behavior and looking for side effects such as timings.
She tested and analyzed several side channels and the differences between benign and attack-induced patterns, for instance, by using the hardware performance counter (HPC) that is available through gem5. Part of the analysis was done with the help of machine learning. Her research resulted in the publication of several papers.
The Even Darker Web - Dirty tricks and questionable code choices on some of the world’s largest websites - Raphaël Vinot
In this talk, Raphaël goes into the techniques used by some websites to track and harvest user information and how his tool, Lookyloo can help.
Raphaël highlighted that some websites use questionable techniques that have a negative impact on user privacy, some of these websites load many resources from external domains with many of them used for tracking. This behaviour is also common in large and sometimes unexpected sites.
His tool, Lookyloo, can help to analyse the behaviour of the websites by visiting a page for you and displaying several statistics and the resources loaded from the request. He also showed how his tool can be used to track phishing pages and other scams. For example, his tool can display the list of distinct websites that point to the same resource.