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.