NDSS 2023 Notes. Part 1

And I'm back with a top security conferences highlights review. This is my first time at NDSS (I'm attending it virtually). Again, the 10 hours difference and my sleep habits do not work together well, so I can see only the first half of each day. I will try to catch up with the rest of the talks later.

So, on the first day of the conference, I followed the Software Security track, and here're a few talks I found most interesting.

Assessing the Impact of Interface Vulnerabilities in Compartmentalized Software presented by Hugo Lefeuvre presents a systematic study of an interesting question: are popular libraries ready for automatic compartmentalization? The principle of least privilege is the basis od secure systems design. Many recent studies proposed mechanisms for automatically isolating unsafe, error-prone, or sensitive code into a separate process. Think of placing an image-parsing library into a separate process so that it can't harm the rest of the application when attacked. The problem is that the existing libraries were not built for such separation, and their APIs accept and receive parameters that the malicious or attacked compartment can abuse. This can happen even in industry-standard libraries such as OpenSSL.

For example, suppose you separated OpenSSL into a process separate from your application, and there is a shared memory between them (this is what most automatic compartmentalization tools do). In the two methods on the right, OpenSSL arbitrarily writes its memory under the full control of the caller and calls arbitrary functions controlled by ctx parameter controlled by the (untrusted) caller. The fact that there is a lot of code like that is not surprising. The contribution of this paper is an impressive attempt to create a framework and tools to assess the readiness of popular existing tools for such compartmentalization.

Instead of poorly scaling manual and static analysis approaches, the authors developed a fuzzing-based tool that automatically detects the compartment's boundaries (usually these are library or module APIs), instruments them, and then fuzzes the parameters, return values, and calls ordering recording the unique ASan crashes. They applied this method to real-world sandboxing and safeboxing (untrusted app and trusted library holding a secret) scenarios and found more than 600 crashes. The crashes are systematically analyzed, and the insights are presented. It should not surprize you: the existing code will not yield a secure and safe system after automatic compartmentalization. Even battle-proved libraries and utilities such as OpenSSL and SU contained fatal vulnerabilities in this scenario.

The most interesting part to me was the section with design guidelines for interfaces built with distrust in mind. You will find there things such as resources (memory, handles) segregation, copying API-crossing objects (to avoid TOCTOU), and more. I think these are important when you build any application, and I will try to incorporate them in our API-design guidelines.

I've got a follow-up question: is Rust code free of such issues? I would love to see someone doing this research.

Drone Security and the Mysterious Case of DJI’s DroneID presented by Nico Schiller . Drone (in)security was on my radar several times in recent years. I tried to read every paper on the topic. I think this one is the most impressive I've seen, specifically regarding modern DJI drones that take security seriously. I knew it would be interesting when I saw @Felix Domke (the name I remember from my NDS days) in the list of authors. And it indeed is fascinating. I think it sets the new standard in drone security research.

The authors start with a detailed description of the drone's interfaces, including a proprietary DUML protocol used by DJI for controlling the drone. Then they start the attacks as a passive eavesdropper aiming at the proprietary DroneID signals that are used to report the drone locations to Aueroscope devices used by law enforcement. The amount of work the authors have done to reverse this undocumented radio broadcast completely is unbelievable - I thought this was impossible before I saw this paper. It starts with SDR capturing the signal, then full signal processing, including demodulation and decoding. Nothing of these signal processing details was known; they were reversed by carefully analyzing the radio signals and then combined with the information extracted from the firmware. At the end of the day, the DroneID packets were recovered - and appeared to be in the clear. This allows the passive eavesdropper to disclose the operator's location.

Next, the authors explored the capabilities of an active attacker. First, they found that although the firmware is being signed, patch files are applied without signature validation. Next, they discovered a way of delivering these patch files to the drone, thus enabling the uploading of malicious firmware patches - eventually arriving at a privileged shell on the drone!

The last cool part of the paper is the fuzzing mechanism the authors built that allowed them to fuzz the real device by altering the DUML commands and automatically monitoring its effects in the UI of a phone displaying the drone's camera and status. This fuzzing yielded 16 vulnerabilities, with 14 of them remote and some resulting in remote code execution!

I can't describe every interesting detail of the paper here, so I strongly recommend to anyone interested in the topic to read it in its entirety.

I also found DiffCSP: Finding Browser Bugs in Content Security Policy Enforcement through Differential Testing to be interesting, mainly due to a novel idea of using differential testing to automate correct content security policy behavior. The problem is that it is very hard to specify what is the correct behavior for the browser when encountering each combination of the policy (CSP) and HTML. The authors decided to use the majority behavior as correct. I appreciate this nice practical trick, but I think it points out a real problem with interpreting these specs in an unambiguous way. This problem asks for a more strict and formal solution.