Dev/Advanced Deanonymization Attacks

From Whonix
< Dev
(Redirected from Dev/Advanced Attacks)
Jump to navigation Jump to search

Notes on Advanced Deanonymization Attacks.

Covert Channels[edit]

This page is a brain-dump all known covert channels and mitigation ideas. A brushed up version for users will be written later when countermeasures are deployed.

See also:
Advanced Deanonymization Attacks

Covert Channels Meta



choices: Some can be eliminated outright, Other channels need to be degraded sufficiently). Good news is it is possible to defend against them all but not without cost.

All problems linked (keystroke dynamics, cpu-induced network latency, TCP ISN CPU temp-induced timer skew, DRAMA cross-vm keystroke monitoring, cpu-cache crypto sidechannels).

covert channels are part of TEMPEST category of attacks. Cryptographers had to deal with them forever but they pose serious problems for systems aiming to isolate untrusted malicious processes. They can be classified as snooping on activity outside a VM or being able to communicate secretly with the outside world.

keystroke fingerprinting:

Excellent paper on covert channels in general:

cpu stress solution for keystrokes? not effective

Question: How to delay keystrokes?:

Answer: funnel all system input events through a local network interface which you inject random latency in. On host so its system wide.

uinput is the kernel input device API but needs C expertise to write a program to do this directly.

usbip? - in mainline. --Not a solution for PCI input devices - most of PCs.

network latency: iperf stress tool or Ethan's netfilter_queue soltion


netevent cobbles netcat host/client together. set on loopback. Run as service with client as localhost. Apply netfilter_queing on loopback to introduce random delays. Pros: kernel solution, display server agnostic. (It uses uinput interface to capture all events)

New research results on obfuscation - no working tool. Contact them and ask if they can write one?

block tcp isn firewall? rewrite tcp isn?

Not possible and needed for security anyway. Are a part of all modern OSs

23C3 Slide 30:

Run CPU at full load Inefficient and must be done with care since different types of tasks can have varying temperature ef- fects

CPU stress must be full load - (what about c-states and temp? Is there a technique less damaging to hardware?) - mitigation for TCP ISN. Maintains constant CPU temperature hence foils skew patterns in timers/crystal clock.

on host out of reach of malicious code in vm.

cpu activity induced latency:

QoS solution by Ethan White

Concept originally proposed in 23C3 slides and has now been realized.

Status: Awaiting deployment as a host and GW package.

very dangerous - process in anon vm can sniff keystrokes in other vms unmasking and stealing user data. /Scenario: JS in browser can pull this off:

Test PoC:

memory stress - DRAMA attack mitigation

stress-m2 in parallel (i.e., the attacker’s core is under stress) made any measurements impossible. While no false positive detections occurred, only 9 events were correctly detected. Thus, our attack is susceptible to noise especially if the attacker only gets a fraction of CPU time on its core.

NUMA combined with CPU pinning also described as valid mitigation. Problem is NUMA environments exist for server systems only for the most part.

on host out of reach of malicious code in vm.

"In this attack, the spy and the victim can run on sepa- rate CPUs and do not share memory, i.e. , no access to shared libraries and no page deduplication between VMs. "

crypto side channels:

vcpu pinning to physical to guarantee no cross cache attacks on cryptoand make other attacks harder.

See also:
Advanced Deanonymization Attacks

Covert Channels Meta

We believe security software like Whonix needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!