6

This interesting article talks about confidentiality concerns regarding weak references in languages with garbage collection. But I didn't fully understand it.

For code that can overtly sense what has been collected ... such observation opens an overt information leakage channel.

What kind of information could leak?

They seem to be saying that the "duration of an allocation" is one thing that might be detected. How could that be used maliciously?

(By the way, I found the article in this question about potentially avoiding memory leaks by asserting garbage collection has occurred on specific objects.)

3

The linked article is speaking in very general terms because it is talking about a generic implementation of weak referencing in garbage collectors. They are stating the potential confidentiality issues because, at the abstract level they're working on, the specific types of side-channel attack which may be presented are entirely up to individual implementations.

For a start, it's important to understand what weak references do.

In a garbage collected system, the GC is tasked with clearing up objects which are no longer in use by the program. The detection of whether an object is in use is often implemented via reference counting, in which the program stores reference metadata alongside the object to aid the GC, incrementing and decrementing the reference counter as and when consuming objects and scopes enter and exceed their lifetimes. The traditional types of reference are usually called strong references.

A downside to strong referencing is that you can't observe an object without preventing the GC from disposing of it. For example, you may want to provide internal debug commands which display information about allocated objects within a collection, without creating a strong reference which causes the object to permanently sit on the heap until your program exits. This is where weak references are useful - they indicate to the GC that the program is still interested in the object, but that it is not strictly necessary for the object to remain. More importantly, they implement a procedure by which the application can check (or be notified) whether the GC has removed the object, and most likely some locking mechanisms which ensure that the GC cannot remove the object while executing code is directly operating upon the object.

The specific implementation of a weak reference falls down to the general memory architecture and type paradigms of the language, and the GC itself is often considered a black-box. Relying upon specific behaviour of the GC, outside of documented concrete behaviour, is poor practice for user code. However, as an attacker in a specific scenario, you have the benefit of being able to study the internals of the specific implementation in use and use them to your advantage.

As a theoretical example, let's say there's a GC whose disposal process for weakly referenced objects works as follows:

  • Is there memory pressure?
  • Have you disposed all objects with zero references, weak or otherwise?
  • Is there still memory pressure?
  • Prioritise objects which have not been accessed for a long time.
  • Prioritise objects which have fewer weak references.
  • Prioritise objects which are larger in size.

Now, if an attacker can detect that a specific object has been disposed (some GCs allow for user-defined finalisation code, which may leak the event externally in some way) then they would know that there was memory pressure, other objects may well have been cleared off the heap too, the object they know was disposed probably wasn't accessed for a while, it probably only had one or two weak references, and it may be larger than others on the heap.

This could be very useful information for a range of side-channel attacks, or even for coordinating other attack types such as timing attacks. It could also be useful when understood in the context of a specific application, e.g. if a weakly referenced object is only continually accessed while the user is present at the system, its disposal may well indicate that the user is not at their station.

The important thing to keep in mind, here, is that the vulnerabilities are theoretical, and the article is simply trying to get GC implementers to keep these issues in mind when designing weak referencing functionality.

2

It's a stretch, but consider if a certain object is allocated only when the code flows down a certain path.

if (secret_bit_is_set(hidden_flags))
    { Object = new TellTale(); }

This is a subset of side channel attacks, and is closely related to timing attacks in general.

Or maybe the lifetime of an object designed to monitor some resource might be useful if I was trying to figure out when it was safe to attack the resource.

  • From reading the article linked, you are correct that they are referring to timing attacks. A weak reference implies that the GC is free to remove the referenced object, as long as the program has a way of knowing that that occurred. Most GCs implement access frequency and time heuristics in order to prioritise which objects should be collected when under memory pressure. Known object disposal (e.g. via a side effect in a destructor, or simply timing / DPA side channel) could leak information about the state of the system via those heuristics. The article is speaking in very general terms. – Polynomial Oct 26 '16 at 8:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.