More notes from my visit to 32C3. Part 1.

Unpatchable: Living with a vulnerable implanted device

Fahrplan link. Recording.

Marie Moe & Eireann Leverett.

Marie lives with a pacemaker: “A project to break my own heart.”

A rather low-key presentation with no alarming remote cracking of pacemakers, but interesting insights into medical implants. For instance, Marie's own pacemaker has two wireless interfaces: one near-field and another for remote monitoring/telemetry when used with an optional a base station in her home.

They bought a programmer for the pacemaker and some base stations on Ebay and did experiments. They could extend the programmable range to several metres!

Some issues:

  • Patient privacy issues.
  • Battery exhaustion.
  • Device malfunction - software bugs.
  • Death threats and extortion.
  • (Remote murder). More unlikely than the others, but this is what would get the press.

Some research needed:

  • Open source medical devices!
  • Medical device crypto. Any backdoors in crypto will end up here!
  • Personal area network monitoring

“We need to be able to verify the software that control our lives.”

“You to can do this research! Lots of low hanging fruit.”

There is na excemption to the Digital Millennium Copyright Act (DMCA) for research on medical devices and automotive devices. Reverse engineering possible without infringing copyright law.

The programmers are unique for the device. Some standardization, perhaps?

Much smaller pacemakers coming. Inside the heart!

“Are there laws requiring the doctor to tell them they are upgrading the software?”

No third party tests? No consumer laboratory?

How the Great Firewall discovers hidden circumvention servers

Fahrplan link.

Philipp Winter,

An analysis of how China's Great Firewall blocks traffic and knows what to block.

“We know what is blocked, how it is blocked, where it is topologically.”

“Most measurements are one-off, continuous measurements challaneging.”

Even if you use DNS resolver outside of China, a DPI looks at your traffic and spoofs the results. If you wait for a while... you get the real DNS reply as well! Not filtered!

  • Many keywords are blocked: DPI looks at your GET request, sends RST to your browser before the TCP connection is fully established. HTTPS helps, but see above about DNS.
  • Encrypted tunnels help - but DPI looks at port numbers, type of encryption, handshake parameters, flow info.
  • Active probing: Checks the cipher list in the TLS client hello from client in China to server in Germany. Vanilla Tor (not using any obfuscation) looks special. Is it Tor? The GFW starts a short-lived probe and tries to speak the Tor protocol to the server. If it is, it blocks client to access this server.

Several data sets collected to see where the probes come from.

  • Shadow data set: they did a test with clients in cernet, unicom in china and Tor bridges using vanilla tor, obfs 3, and obfs 4.
  • The Sybil data set, clients in china with 600 ports on a tor server.
  • Log dataset: web server with logs dating back to 2010.

Collected 16 000 unique probe ip addresses! 95% addresses seen only once!

Reverse DNS with “adsl” in them... Looks like ISP addresses. The single IP address was almost 50% of the probes!?

Majority of probes comes from three ASes: 4837, 4134, 17622.

Do they hijack these addresses for GFW use? While the probe is active no communication with them possible: traceroute times out, no ping...

What do they have in common?

  • Narrow ttl distribution.
  • Uses source ports in the entire 16 bit port range!
  • Exhibit patterns in TCP TSval.
  • Does not seem like off-the-shelf TCP/IP stack. A user space stack?
  • Strange tcp's initial sequence numbers... not really random... zig zag pattern. Perfectly correlated with time. State leakage!
  • Probes all share an auncommon TLS client hello.
  • No random-generated SNI.
  • A unique cipher list.

Physical infrastructure

  • State leakage shows that probes are centrally controlled.
  • Not clear how they control probes.
  • A proxy network?
  • Off-path device in ISP'S data centre? Machines connected to switch ports?

Blocking is reliable but fails predictable

In 2012 probes were batched, perhaps started by cron.

Now real time. Median arrival time only 500 ms.

Blocked protocols

  • SSH blocked in 2011 but no longer.
  • VPN, Openvpn sometimes? Softether.
  • Tor, vanilla, obfs2 & obfs 3.
  • Appspot - possibly because they're looking for GoAgent proxies.
  • TLS.

The probes doesn't seem to be using reference software. Handcrafted!? The probes look very different from ordinary software and can be easily identified.

Find your own probes


DPI must re-assemble the stream before pattern matching. Make the protocol harder ro reassemble. Server-side manipulation of TCP window size can hide the protocol signature. Used in brdgrd.

TCP/ip based circumvention difficult to deploy: “use this unknown kernel module, will you?”

Tor project pluggable transport to the rescue! Pluggable transports that work in China

  • scramblesuit - clients share a shared secret.
  • obfs4 - extends scramblesuit.
  • meek - tunnels traffic over cdns! amazon, azure, google
  • fte - shapes ciphertext based on regular expressions
  • more.... perhaps something webrtc-based?

CloudABI: Pure capability-based security for UNIX

Fahrplan link.

Ed Schouten,

A new Unix runtime with capabilities.

What's wrong with unix?

Unix doesn't stimulate you to run software securely. A web service only needs a specific set of capabilites but can do everything.

Access controls like apparmor not a real solution. Puts the burden on the package maintainers.

Untrusted third-party programs are also extremely unsafe. Can the OS provide better isolation?


Capabilities: Example, Capsicum. Programs starts as an ordinary process, opens all files it needs, then calls cap_enter(), process can still use file descriptors, read(), write() but can't use open() et cetera. Returns ENOTCAPABLE.

Used in FreeBSD by some programs: dhclient, hastd, ping, sshd, tcpdump, et cetera.

However, problems: code isn't designed to have system calls disabled!

  • C library: locales unusable, incorrect timezone, et c
  • crypto library: non-random PRNG!
  • capsicum doesn't scale: using in-house maintained code it works (Chrome)
  • but using off-the-shelf libraries becomes harder.

Introducing CloudABI

A new posix-like runtime environment.

  • No more state. Capsicum is always turned on.
  • Capsicum-conflicting APIs have been removed.
  • Bugs becomes compiler errors.
  • Global namespaces are entirely absent.
  • Processes can no longer hardcode paths and identifiers.
  • Resources cannot be acquired out of the blue.

Default rights

  • allocate memory, create pipes, socket pairs.
  • can fork.
  • cannot: open paths on disk.
  • cannot create network connections.

Additional rights: file descriptors

Make sure you have the right set of file descriptors when starting the process.

A file descriptor is its own chroot.

Process descriptors: replacement for wait()/kill(). Special fork gives you a process descriptor. These descriptors can't be passed over Unix sockets.

File descriptors have permission bitmasks allowing fine-grained limiting of actions performed on them.

Example file descriptors for a web server:

  • A listening network socket used to receive incoming HTTP requests,
  • One or more file descriptors to directories containing resources accessible through the web,
  • One or more network sockets connected to backend services used by the web server (e.g., database servers),
  • A file descriptor pointing to a log file.

This web server will be limited to the above and can't escape.


POSIX becomes tiny if you remove all interfaces that conflict with capabilities. Only 58 system calls available.

Goal: add support to existing posix operating systems.

Allows reuse of binaries without recompilation.

Upstreams: freebsd/arm64, /x86-64

Beta: Linux.

Developing for CloudABI

CloudABI ports - a collection of cross compiled libraries and tools.

Builds native packages: Freebsd pkg and Debian packages.

Use cases of CloudABI

  • Secure hardware appliance.
  • High-level cluster management.
  • CloudABI as a service: no virtualization overhead. No need to maintain entire systems, just applications. Can be written in any language.