Transynther

Transynther

Fuzz Testing Meltdown-style attacks

Transynther relies on PTEditor to modify page tables. We can install this submodule by issuing the following commands at the root of this repository:

git submodule update --init
cd PTEditor/module/
make
sudo insmod pteditor.ko

After verifying that PTEditor kernel module is installed by checking the output of lsmod | grep pte, we can start testing the CPU for Meltdown-style (or MDS-related) attacks. By running ./fuzz.py, Transynther starts testing a random set of instructions that may reproduce a variant of these attacks. We generally output the result to a log file to be analyzed later: ./fuzz.py > logs/a_log_file.log.

There is a singleton class named Config in ./fuzz.py that can configure the behavior of the tool. Some of these configurations are as the following:

• RUN_N_SAMPLE: Number of tests. Note that you can, of course, stop the tool at any time.
• RUN_ATTACKER_CPU: The logical CPU that runs the Meltdown-style gadget.
• RUN_VICTIM_CPU: The logical CPU that only executes random memory accesses and other instructions (None for single-thread testing).
• RUN_TIMEOUT: How long to run the sample. Note that both the attacker and victim runs an infinite loop until it is stopped by this timeout.
• ARCH_NO_TSX: Should be enabled for CPUs that do not support TSX.
• ARCH_NO_MPK: Should be enabled for CPUs that do not support MPK.
• ARCH_NO_AVX512 Should be enabled for CPUs that do not support 64-byte AVX512 memory accesses.

./fuzz.py generates random instructions in an autogen.S file; then it compiles it with the wrapper code in main.c by running the make command. Finally, it executes the new test case with a timeout. Note that there are probably better ways to implement this process, but for an academic proof of concept, we went for the easiest way to implement this.

Processing Logs

After generating a log, we use the ./process.py to preprocess a log file by running ./process.py logs/a_log_file.log. This command extracts the instances that leaked some data during the execution of the meltdown-style encoding and classify them based on the root cause under the _processed directory. Additionally, based on where the data has been leaked, some tags are associated with the preprocessed logs. The tags are as the following:

• _ht_: The leaked value was produced by the other logical CPU (i.e hyperthread in this case).
• _st_: The leaked value was produced by the same logical CPU.
• _4k_: The leakage met the 4K aliasing condition (Fallout Attack).
• _un_: An unexpected value is leaked.
• _zr_: The value zero is leaked (Potential for the LVI attack).
• _sm_: The same value that was written to an address was leaked.

Note that a generated log is an assembly file with additional comments. An interesting log, which includes a proof of concept MDS-style attack code can be analyzed further.

Testing a Synthesized Code

The ./test.sh simply copies a processed log/asm file to autogen.S and executes it on the provided CPU numbers. For example, ./test.sh _processed/NC/_ht_/i7-7700_9_0x48.log_21829_2547.asm 1 5 executes this sample on logical CPU 1 and 5 that may be on the same core on most Intel-based CPU configurations.

Description of files/folders

• fuzz.py: The fuzz testing tool.
• process.py: The script to preprocess the testing results
• Makefile: The makefile to compiles a test case (no need to be invoked directly).
• main.c: The wrapper C code that executes the assembly routines.
• medusa.h and medusa.S: Some dependencies.
• logs: some log files generated by us on 4 different Intel CPUs.
• _processed: The preprocessed logs from our experiment on these CPUS.