# [Keynote] Supply-chain Security : Trust but Verify

Jonathan Brossard

► To cite this version:

Jonathan Brossard. [Keynote] Supply-chain Security : Trust but Verify. Doctoral. Campus Cyber, Paris, France. 2025. hal-05130637

HAL Id: hal-05130637

https://hal.science/hal-05130637v1

Submitted on 26 Jun 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
<figure><img src="image_2.png" /></figure>

MOABI

# Supply-Chain Security : Trust but Verify

Jonathan Brossard

13th of March 2025

<figure><img src="image_3.png" /></figure>

PROGRAMME DE
**transfert** au
campus cyber

<figure><img src="image_4.png" /></figure>

FRANCE

PROGRAMME
DE RECHERCHE

CYBERSÉCURITÉ

<figure><img src="image_5.png" /></figure>

le cnam
# Agenda

salesforce

- Motivation

- Problem Statement

- Introduction to ELF Libification

- Procedural Debugging

- Partial Proofs of Vulnerabilities

- Conclusion & Future Work

<figure><img src="image_6.png" /></figure>

<figure><img src="image_7.png" /></figure>
Conformité réglementaire

<figure><img src="image_8.png" /></figure>

<figure><img src="image_9.png" /></figure>

<figure><img src="image_10.png" /></figure>

<figure><img src="image_11.png" /></figure>

<figure><img src="image_12.png" /></figure>

<figure><img src="image_13.png" /></figure>

<figure><img src="image_14.png" /></figure>
Motivation
# Motivation: SBOMs vulnerability assessments don't scale well

Software Bill of Materials (SBOMs) contain lists of CPEs or Package URLs (purl) describing all the components of a given Software.

They allow to perform vulnerability assessments by comparing the CPEs to the dictionaries published by the NIST for each CVE.

```json
"components": [
  {
    "type": "application",
    "name": "sshd",
    "hashes": [
      {
        "alg": "MD5",
        "content": "0e6e1c30f8e10e45647ba5d9d4ea6948"
      },
      {
        "alg": "SHA-1",
        "content": "399e5d00e2d91628792eefe066489f64a6310486"
      },
      {
        "alg": "SHA-256",
        "content": "5bd9544d2da6daf7519ee8d6efcd71d6edc16a507f86a90e233174bbebb843c2"
      }
    ]}
  },
  {
    "type": "application",
    "description": "sshd",
    "group": "openbsd",
    "name": "openssh",
    "version": "9.6p1",
    "cpe": "cpe:2.3:a:openbsd:openssh:9.6p1:*:*:*:*:*:*:*,*",
    "externalReferences": [
      {
        "type": "website",
        "url": "https://www.openssh.com/"
      }
    ],
    "licenses": [
      {
        "license": {
          "id": "BSD-2-clause"
        }
      },
      {
        "license": {
          "id": "BSD-3-clause"
        }
      },
```

Software Bill of Materials are becoming mandatory
# Motivation : SBOMs vulnerability assessments don't scale well

<figure><img src="image_15.png" /></figure>

MAY 12, 2021

## Executive Order on Improving the Nation's Cybersecurity

<figure><img src="image_16.png" /></figure>

BRIEFING ROOM

PRESIDENTIAL ACTIONS

By the authority vested in me as President by the Constitution and the laws of the United States of America, it is hereby ordered as follows:

**Section 1. Policy.** The United States faces persistent and increasingly sophisticated malicious cyber campaigns that threaten the public sector, the private sector, and ultimately the American people's security and privacy. The Federal Government must improve its efforts to identify, deter, protect against, detect, and respond to these actions and actors. The Federal Government must also carefully examine what occurred during any major cyber incident and apply lessons learned. But cybersecurity requires more than government action. Protecting our Nation from malicious cyber actors requires the Federal Government to partner with the private sector. The private sector must adapt to the continuously changing threat environment, ensure its products are built and operate securely, and partner with the Federal Government to foster a more secure cyberspace. In the end, the trust we place in our digital infrastructure should be proportional to how trustworthy and transparent that infrastructure is, and to the consequences we will incur if that trust is misplaced.

<figure><img src="image_17.png" /></figure>

## EU Cyber Resilience Act

New EU cybersecurity rules ensure safer hardware and software.

From baby-monitors to smart-watches, products and software that contain a digital component are omnipresent in our daily lives. Less apparent to many users is the security risk such products and software may present.

The Cyber Resilience Act (CRA) aims to safeguard consumers and businesses buying or using products or software with a digital component. The Act would see inadequate security features become a thing of the past with the introduction of mandatory cybersecurity requirements for manufacturers and retailers of such products, with this protection extending throughout the product lifecycle.

The problem addressed by the Regulation is two-fold.

First is the inadequate level of cybersecurity inherent in many products, or inadequate security updates to such products and software.

Second is the inability of consumers and businesses to currently determine which products are cybersecure, or to set them up in a way that ensures their cybersecurity is protected.

The Cyber Resilience Act will guarantee:

* harmonised rules when bringing to market products or software with a digital component;

<figure><img src="image_18.png" /></figure>

GUIDANCE DOCUMENT

## Select Updates for the Premarket Cybersecurity Guidance: Section 524B of the FD&C Act

Draft Guidance for Industry and Food and Drug Administration Staff

MARCH 2024

Download the Draft Guidance Document

Read the Federal Register Notice

Draft

Not for implementation. Contains non-binding recommendations.

<figure><img src="image_19.png" /></figure>

<figure><img src="image_20.png" /></figure>

<figure><img src="image_21.png" /></figure>

<figure><img src="image_22.png" /></figure>

<figure><img src="image_23.png" /></figure>

<figure><img src="image_24.png" /></figure>

<figure><img src="image_25.png" /></figure>

**Docket Number:** FDA-2021-D-1158

**Issued by:** Center for Devices and Radiological Health
Center for Biologics Evaluation and Research

FDA has developed this draft guidance to propose select updates to the FDA guidance document "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" (hereafter referred to as the "Premarket Cybersecurity Guidance"). FDA is proposing to add a Section VII. to the Premarket Cybersecurity Guidance to address new considerations for cyber devices. The new section identifies the cybersecurity information FDA considers to generally be necessary to support obligations under section 524B of the FD&C Act. The Premarket Cybersecurity Guidance, in its
# Motivation : SBOMs vulnerability assessments don't scale well

<figure><img src="image_26.png" /></figure>

MOABI

## 243 SOFTWARE MONITORED

<table><thead><tr><th>SOFTWARE</th><th>SCAN DATE</th><th>NEW CVES</th><th>Last Modified</th></tr></thead><tbody><tr><td>Hyundai.update.zip</td><td>10 August 2022</td><td>1230</td><td>8 August 2024</td></tr><tr><td>psa_rcc.zip</td><td>10 August 2022</td><td>1151</td><td>8 August 2024</td></tr><tr><td>Firmware.bin</td><td>17 October 2022</td><td>952</td><td>8 August 2024</td></tr><tr><td>Tesla_2019.20.4.2.model3.squashfs</td><td>20 June 2023</td><td>467</td><td>8 August 2024</td></tr></tbody></table>

SBOMs provide possible CVES. For each vulnerability : is it true ?

## CONTINUOUS MONITORING

1019 new vulnerabilities identified for software Tesla_2019.20.4.2.model3.squashfs

Updated report for dnsmasq

<figure><img src="image_27.png" /></figure>

Description

Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the &quot;KeyTrap&quot; issue. One of the concerns is that, when there is a zone with many DNSKEY and RRSIG records, the protocol specification implies that an algorithm must evaluate all combinations of DNSKEY and RRSIG records.

Impact

<figure><img src="image_28.png" /></figure>

Type

<figure><img src="image_29.png" /></figure>

Attack Vector

CVSSv3 Vector : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Motivation (bis)
# Zerodays : No patch, am I vulnerable ?

## Taint analysis on binary
(no source code)

<figure><img src="image_30.png" /></figure>

## Calling convention SYSTEM V:
RDI, RSI, RDX, RCX, R8, R9
# Zerodays : No patch, am I vulnerable ?

Taint analysis on binary
(no source code)

<figure><img src="image_31.png" /></figure>

<figure><img src="image_32.png" /></figure>
Problem Statement :

Partial Proofs of Vulnerabilities
through
Procedural Debugging
<figure><img src="image_33.png" /></figure>

# Proving Exploitability

Industry standard to Prove exploitability : Write an exploit

This bar is too high.

If we decompose an exploit into 3 problems:

- Reach the vulnerable function

- Trigger the vulnerability

- Achieve code execution/Weaponize

The first step alone is already undecidable ("reachability problem").

<figure><img src="image_34.png" /></figure>

DANGER
# Proving Exploitability : Partial Proof of Vulnerability

Let's do only step 2:

If we decompose an exploit into 3 problems:

- Reach the vulnerable function

- Trigger the vulnerability

- Achieve code execution/Weaponize

This a reasonable heuristic to determine vulnerability of the application.

We'd like to be able to call the vulnerable function directly.

Problem : How to do this out of context ?

Proposal : Let's turn the vulnerable application into a shared library !

<figure><img src="image_35.png" /></figure>

DANGER
<figure><img src="image_36.png" /></figure>

# Proving Exploitability : Procedural Debugging

<figure><img src="image_37.png" /></figure>

ELF Executable
or Library

Load in Memory
(+ load dependencies
& solve relocations)

function1()

...

function...()

...

function_vulnerable()

....

**Note:** If the ELF is statically linked, loading its segments is enough.

We simply need a userland ELF loader.

Confere userland exec() techniques (eg: The Grugg, phrack, 2004)

We would like to map the ELF in memory, solve dependencies/relocations if the ELF is dynamically linked.

Then call the potentially vulnerable function with chosen arguments, with just enough context to trigger the vulnerability.

Address Space
# Loading Dynamic Executables : Introduction to ELF Libification
Reverse Engineering :
Compilation Process

<figure><img src="image_38.png" /></figure>

Source Code

<figure><img src="image_39.png" /></figure>

Compiler

<figure><img src="image_40.png" /></figure>

Assembly
Code (.S)

<figure><img src="image_41.png" /></figure>

Assembler

<figure><img src="image_42.png" /></figure>

Object Files (.o)

<figure><img src="image_43.png" /></figure>

Shared Libraries

<figure><img src="image_44.png" /></figure>

Static Link Editor

<figure><img src="image_45.png" /></figure>

Executables
Reverse Engineering :
Disassembly

<figure><img src="image_46.png" /></figure>

Source Code

<figure><img src="image_47.png" /></figure>

Compiler

<figure><img src="image_48.png" /></figure>

Assembly
Code (.S)

<figure><img src="image_49.png" /></figure>

Assembler

<figure><img src="image_50.png" /></figure>

Object Files (.o)

<figure><img src="image_51.png" /></figure>

Disassembly

Executables

<figure><img src="image_52.png" /></figure>

Static Link Editor

Undecidable
Reverse Engineering :
Decompilation

<figure><img src="image_53.png" /></figure>

Undecidable
Reverse Engineering :
Libification

<figure><img src="image_54.png" /></figure>

Source Code

<figure><img src="image_55.png" /></figure>

Compiler

<figure><img src="image_56.png" /></figure>

Assembly
Code (.S)

<figure><img src="image_57.png" /></figure>

Assembler

<figure><img src="image_58.png" /></figure>

Object Files (.o)

<figure><img src="image_59.png" /></figure>

Shared Libraries

Libification
(wld)

<figure><img src="image_60.png" /></figure>

Executables

<figure><img src="image_61.png" /></figure>

<figure><img src="image_62.png" /></figure>

<figure><img src="image_63.png" /></figure>

Static Link Editor
# Executables vs Shared Libraries :
## How Do They Differ ?

<figure><img src="image_64.png" /></figure>

Same headers, same segments, same
sections. They mostly differ through
their metadata (various ELF headers)

The work to be done:

Modify the various ELF headers to
turn an Executable into a Shared
Library

Tool Interface Standard (TIS)
Executable and Linking Format (ELF)
Specification
Version 1.2

TIS Committee

May 1995

ELF Header

Some object file control structures can grow, because the ELF header contains their actual sizes. If the object file format changes, a program may encounter control structures that are larger or smaller than expected. Programs might therefore ignore "extra" information. The treatment of "missing" information depends on context and will be specified when and if extensions are defined.

<caption>Figure 1-3. ELF Header</caption>

```c
#define EI_NIDENT 16
typedef struct {
    unsigned char   e_ident[EI_NIDENT];
    Elf32_Half     e_type;
    Elf32_Half     e_machine;
    Elf32_word     e_version;
    Elf32_Addr     e_entry;
    Elf32_Off       e_phoff;
    Elf32_Off       e_shoff;
    Elf32_word      e_flags;
    Elf32_Half      e_hsize;
    Elf32_Half      e_phentsize;
    Elf32_Half      e_phnum;
    Elf32_Half      e_shentsize;
    Elf32_Half      e_shnum;
    Elf32_Half      e_shstrndx;
} Elf32_Ehdr;
```

**e_ident** The initial bytes mark the file as an object file and provide machine-independent data with which to decode and interpret the file's contents. Complete descriptions appear below, in "ELF Identification."

**e_type** This member identifies the object file type.

<table><thead><tr><td>Name</td><td>Value</td><td>Meaning</td></tr></thead><tbody><tr><td>ET_NONE</td><td>0</td><td>No file type</td></tr><tr><td>ET_REL</td><td>1</td><td>Relocatable file</td></tr><tr><td>ET_EXEC</td><td>2</td><td>Executable file</td></tr><tr><td>ET_DYN</td><td>3</td><td>Shared object file</td></tr><tr><td>ET_CORE</td><td>4</td><td>Core file</td></tr><tr><td>ET_LOPROC</td><td>@xff00</td><td>Processor-specific</td></tr><tr><td>ET_HIPROC</td><td>@ffff</td><td>Processor-specific</td></tr></tbody></table>
# Automated Libification : the
# Witchcraft Linker

URL: https://github.com/endrazine/wcc

License: MIT/BSD-2

ARTIFACT
EVALUATED

<figure><img src="image_65.png" /></figure>

usenix
ASSOCIATION

AVAILABLE

ARTIFACT
EVALUATED

<figure><img src="image_66.png" /></figure>

usenix
ASSOCIATION

FUNCTIONAL

ARTIFACT
EVALUATED

<figure><img src="image_67.png" /></figure>

usenix
ASSOCIATION

REPRODUCED

jonathan@blackbox:~/woot$

Fichier Édition Affichage Rechercher Terminal Aide

jonathan@blackbox:~/woot$ file ls
ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamicall
y linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=3eca7e
3905b37d48cf0a88b576faa7b95cc3097b, for GNU/Linux 3.2.0, stripped

jonathan@blackbox:~/woot$ wld -libify ./ls

jonathan@blackbox:~/woot$ file ls
ls: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=3eca7e3
905b37d48cf0a88b576faa7b95cc3097b, for GNU/Linux 3.2.0, stripped

jonathan@blackbox:~/woot$

DOI

10.5281/zenodo.11405214
# Validation

Test Repository:

https://github.com/endrazine/wcc-tests

<table><thead><tr><td>Version</td><td>Codename</td><td>Year</td><td>GCC Version</td><td>Passed</td><td>Failed</td></tr></thead><tbody><tr><td>24.04</td><td>noble</td><td>2024</td><td>12.3.0</td><td>440</td><td>0</td></tr><tr><td>22.04</td><td>Jammy</td><td>2022</td><td>11.2.0</td><td>435</td><td>0</td></tr><tr><td>20.04</td><td>focal</td><td>2020</td><td>9.3.0</td><td>435</td><td>0</td></tr><tr><td>18.04</td><td>bionic</td><td>2018</td><td>7.3.0</td><td>369</td><td>0</td></tr><tr><td>16.04</td><td>xenial</td><td>2016</td><td>5.3.1</td><td>363</td><td>0</td></tr><tr><td>14.04</td><td>trusty</td><td>2014</td><td>4.8.2</td><td>352</td><td>0</td></tr></tbody></table>

<figure><img src="image_68.png" /></figure>

<figure><img src="image_69.png" /></figure>

<figure><img src="image_70.png" /></figure>

<figure><img src="image_71.png" /></figure>

DOI

10.5281/zenodo.11301409
# Procedural Debugging
Procedural Debugging : Libification based
Debugging

<figure><img src="image_72.png" /></figure>

MOABI

<figure><img src="image_73.png" /></figure>

ELF Executable
or Library

Load in Memory
(+ load dependencies
& solve relocations)

function1()

...

function...()

...

function_vulnerable()

....

If the ELF is dynamically
linked, libify it and load via
dlopen().

If the ELF is statically linked, loading its segments
is enough.

We simply need a userland ELF loader.

Confere userland exec() techniques (eg: The
Grugg, phrack, 2004)

Address Space
## Challenges
(Without Control Flow Analysis, which is Undecidable)

In Dynamically linked ELFs, parse the link_map

- Provides a list of all ELFs in memory

- Dynamic linker exports iterators to symbols

- Use dlsym() function from the Dynamic Linker to obtain address of symbols.

function1()

...

function...()

...

function_vulnerable()

...

Library_1

...

Library_n

Address Space
# Procedural Debugging : Crafting Minimal Context/Arguments

<figure><img src="image_74.png" /></figure>

MOABI

Calling convention is architecture specific. On x86_64 GNU/Linux, arguments passing is done via registers:

RDI, RSI, RDX, RCX, R8, R9 for integers or pointers, and XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6 and XMM7 for floating-point arguments.

We can craft those arguments and point RIP to function_vulnerable() to achieve selective procedural execution.

* Avoid reachability problem.

function1()

...

function...()

...

function_vulnerable()

...

Library_1

...

Library_n

WSH

Address Space

We would like to map the ELF in memory, solve dependencies/relocations if the ELF is dynamically linked.

Then call the potentially vulnerable function with chosen arguments, with just enough context to trigger the vulnerability.
# Procedural Debugging

- Libify ELF executables

- Make ELF executables scriptable

- Call arbitrary functions
  (procedural debugging)

<figure><img src="image_75.png" /></figure>

URL: https://github.com/endrazine/wcc

License: MIT/BSD-2

DOI

10.5281/zenodo.13902925
Partial Proofs of Vulnerabilities
<figure><img src="image_76.png" /></figure>

# Partial Proofs of Vulnerabilities

The ability to turn ELF executables into libraries will allow us to create partial proofs of vulnerabilities in the form of WSH test scripts.

## Examples:

https://github.com/endrazine/wcc-tests/tree/main/scripts

<figure><img src="image_77.png" /></figure>
print(" [*] Testing for CVE-2022-3602")

-- Input Arguments

teststring = "hello! -gr25faaaaaaaaaaaaa"

decoded = calloc(80)

decodedlen = calloc(1,2)

memcpy(decodedlen, 0x14, 1)

res = ossl_punycode_decode(teststring, 26, decoded, decodedlen)

if res > 0 then free(res) else print(" [*] Not vulnerable to CVE-2022-3602") ; exit(0) ; end

OpenSSL
Cryptography and SSL/TLS Toolkit
Bonus

<figure><img src="image_78.png" /></figure>
# Binary Reflection

The Witchcraft Shell implements:

- An exposition of binary functions from the LUA interpreter.

Thanks to lua, we then implement:

- Binary introspection

- Binary intercession

=> We implement binary reflection, without source code.

DOI 10.5281/zenodo.13902925
# Cross Architecture Procedural Debugging
(JIT)

<figure><img src="image_79.png" /></figure>

MOABI

By cross-compiling WSH to other architectures and running it within qemu-user, we benefit from JIT translation to the host architecture (eg: Aarch64 to x86_64) without a Virtual Machine, and in a single process (debugger + debuggee + JIT translator)

function1()

...

function...()

...

function_vulnerable()

...

Library_1

...

Library_n

WSH

Qemu-user (JIT)

DOI

10.5281/zenodo.13902925

Address Space
Conclusion & Future Work
# Partial Proofs of Vulnerabilities

- Turning Dynamically linked ELFs into shared libraries is practical (Witchcraft Linker)

- The Witchcraft Shell can perform procedural debugging.

- Selective execution of vulnerable functions is practical via procedural debugging.

- Work to be done: Automatically write the scripts to trigger CVEs ?

DOI 10.5281/zenodo.13902925
# Witchcraft Linker : Libification

<figure><img src="image_80.png" /></figure>

Undecidable
# Witchcraft Compiler: Unlinking

<figure><img src="image_81.png" /></figure>

Source Code

<figure><img src="image_82.png" /></figure>

Compiler

<figure><img src="image_83.png" /></figure>

Assembly
Code (.S)

<figure><img src="image_84.png" /></figure>

Assembler

<figure><img src="image_85.png" /></figure>

Object Files (.o)

Shared Libraries

<figure><img src="image_86.png" /></figure>

Unlinking
(wcc)

<figure><img src="image_87.png" /></figure>

Static Link Editor

Executables

<figure><img src="image_88.png" /></figure>
# Witchcraft Compiler: Unlinking + Relinking
= Assured Patching

<figure><img src="image_89.png" /></figure>
# Witchcraft Compiler: Unlinking + Instrumentation = Fuzzing

<figure><img src="image_90.png" /></figure>
<figure><img src="image_91.png" /></figure>

THANK YOU FOR
YOUR ATTENTION

<figure><img src="image_92.png" /></figure>

PROGRAMME DE
transfert AU
campus cyber

<figure><img src="image_93.png" /></figure>

FRANCE
2030
PROGRAMME
DE RECHERCHE
CYBERSÉCURITÉ

Jonathan Brossard
jonathan.brossard@moabi.com

<figure><img src="image_94.png" /></figure>