#serialize-deserialize #traits #deserialize #serialization

detrojt

A hack to support deserialization of arbitrary trait objects

2 releases

Uses old Rust 2015

0.1.1 Jul 8, 2017
0.1.0 Jul 8, 2017

#2136 in Encoding

MIT/Apache

19KB
193 lines

Deserializeable trait objects

Documentation Crates.io

Documentation for the master branch

A dirty hack to support deserialization of arbitrary trait objects.

This is a proof-of-concept created in response to rust-lang/rfcs#668 as well as Dmitry Gordon's question How can deserialization of polymorphic trait objects be added in Rust if at all? (related Rust Forum post).

Caveat emptor

Deserialization may cause arbitrary code execution. The library has some sanity checks to make it hard to accidentally screw up, but there's no guarantee that this library is safe against a malicious attacker.

Even for trusted data, deserializing may cause undefined behavior on platforms and configurations that violate any of the following assumptions:

  • The data being deserialized was originally serialized by the exact same executable built under identical conditions (architecture, optimization levels, other compiler flags, etc)
  • All vtables are mapped to a single contiguous block of memory, located at fixed positions relative to each other (same for every execution)
  • Trait objects have the layout { data: *mut _, vtable: *mut _ }
  • Vtables have the layout { destructor: fn(_), size: usize, alignment: usize, ... }
  • A POSIX system with either /dev/random or /dev/null (it shouldn't be too hard to port this to other platforms)
  • 64-bit pointers (not entirely necessary, but 32-bit pointers would make it easier to exploit)

If Rust adds support for #[repr(align = "N")], it may be possible to use a custom alignment as a secondary sanity check.

Dependencies

~0.5–1MB
~20K SLoC