El artículo vinculado habla en términos muy generales porque habla de una implementación genérica de referencias débiles en los recolectores de basura. Están indicando los posibles problemas de confidencialidad porque, en el nivel abstracto en el que están trabajando, los tipos específicos de ataques de canal lateral que pueden presentarse dependen completamente de las implementaciones individuales.
Para empezar, es importante comprender lo que hacen las referencias débiles.
En un sistema de recolección de basura, el GC tiene la tarea de eliminar los objetos que el programa ya no utiliza. La detección de si un objeto está en uso a menudo se implementa a través del recuento de referencias , en el que el programa almacena metadatos de referencia junto con el objeto. para ayudar al GC, incrementando y disminuyendo el contador de referencia a medida que los objetos y los ámbitos que consumen ingresan y exceden sus vidas. Los tipos tradicionales de referencia se denominan generalmente referencias fuertes .
Una desventaja de las referencias fuertes es que no puede observar un objeto sin evitar que el GC lo deseche. Por ejemplo, es posible que desee proporcionar comandos de depuración internos que muestren información sobre los objetos asignados dentro de una colección, sin crear una referencia sólida que haga que el objeto permanezca permanentemente en el montón hasta que el programa salga. Aquí es donde las referencias débiles son útiles: le indican al GC que el programa aún está interesado en el objeto, pero que no es estrictamente necesario que el objeto permanezca. Más importante aún, implementan un procedimiento mediante el cual la aplicación puede verificar (o recibir una notificación) si el GC ha eliminado el objeto, y muy probablemente algunos mecanismos de bloqueo que aseguran que el GC no puede eliminar el objeto mientras se ejecuta el código directamente sobre el objeto. .
La implementación específica de una referencia débil se basa en la arquitectura de memoria general y los paradigmas de tipo del lenguaje, y el propio GC a menudo se considera una caja negra. Confiar en el comportamiento específico del GC, fuera del comportamiento concreto documentado, es una mala práctica para el código de usuario. Sin embargo, como atacante en un escenario específico, tiene la ventaja de poder estudiar los aspectos internos de la implementación específica en uso y utilizarlos en su beneficio.
Como ejemplo teórico, digamos que hay un GC cuyo proceso de eliminación para objetos con referencias débiles funciona de la siguiente manera:
- ¿Hay presión de memoria?
- ¿Ha eliminado todos los objetos con cero referencias, débiles o no?
- ¿Todavía hay presión de memoria?
- Priorice los objetos a los que no se ha accedido durante mucho tiempo.
- Priorice los objetos que tengan menos referencias débiles.
- Priorice los objetos que son más grandes en tamaño.
Ahora, si un atacante puede detectar que se ha eliminado un objeto específico (algunos GC permiten el código de finalización definido por el usuario, que puede filtrar el evento de forma externa) entonces sabrían que había presión en la memoria, otros objetos Es posible que también se haya eliminado el montón, el objeto que saben que se eliminó probablemente no se accedió durante un tiempo, probablemente solo tenía una o dos referencias débiles, y puede ser más grande que otros en el montón.
Esta podría ser una información muy útil para una serie de ataques de canal lateral, o incluso para coordinar otros tipos de ataques, como los ataques de temporización. También podría ser útil cuando se entiende en el contexto de una aplicación específica, p. Ej. si solo se accede a un objeto con una referencia débil mientras el usuario está presente en el sistema, su eliminación puede indicar que el usuario no está en su estación.
Lo importante a tener en cuenta, aquí, es que las vulnerabilidades son teóricas , y el artículo simplemente intenta que los implementadores de GC tengan en cuenta estos problemas al diseñar una funcionalidad de referencia débil. / p>