25. Security issues

This chapter describes security issues that may be present when using the MPS.

25.1. Predictable address space layout on FreeBSD

The MPS acquires address space using the operating system’s virtual memory interface (specifically, mmap() on FreeBSD). As of version 10, FreeBSD does not randomize the allocated regions of address space, which means that the addresses of blocks allocated by the MPS are predictable: a client program that makes an identical series of calls to the MPS gets an identical series of addresses back.

This means that if a program using the MPS has a buffer overflow, the overflow is more easily exploitable by an attacker than if the program had used malloc() (which has some randomization of the allocated addresses), because it is easier for an attacker to determine the address of allocated structures.

There is currently no workaround for this issue. If this affects you, please contact us.

Other supported platforms are unaffected by this issue: Linux and OS X randomize the addresses allocated by mmap(), and Windows randomizes the addresses allocated by VirtualAlloc().

25.2. Address disclosure

The MPS supports semi-conservative garbage collection in which some memory locations are scanned as ambiguous references. This may make it possible for a program to discover the address of an object, even if the programming language has no feature for obtaining the address of an object. Discovering the addresses of objects makes it easier to exploit buffer overflow bugs.

The attack proceeds as follows: create a weak reference (1) to the object of interest (for example, via a weak-key hash table); guess a value for the address of the object; and arrange for that value to be scanned as an ambiguous reference (for example, by ensuring that it appears in registers or on the control stack of a thread). If the guess was correct, the MPS keeps the object alive; if incorrect, the object may die. The attacker can then determine which of these was the case by examining the weak reference to see if it has been splatted.

The attack was pointed out by Dionysus Blazakis in 2012 with respect to JavaScript implementations, but it affects all conservative and semi-conservative garbage collectors.

25.3. Telemetry

In its hot and cool varieties, the MPS contains a telemetry system which can be configured to record a stream of events for later analysis and debugging. When using the default plinth, the behaviour of the telemetry system is under the control of the environment variable MPS_TELEMETRY_CONTROL, and the telemetry stream is written to the file named by the environment variable MPS_TELEMETRY_FILENAME.

This means that an attacker who can set arbitrary environment variables when running a program that uses the MPS can cause that program to write a telemetry stream to an arbitrary file. This behaviour might be unexpected, and might enable a data overwriting attack, or a denial-of-service attack, since telemetry streams are typically very large.

If this is an issue for your program, then you can modify or replace the I/O module in the plinth so that it meets your requirements, or distribute the rash variety of the MPS, which omits the telemetry system entirely, and use the other varieties only for development and testing.