PUDA Explained: Understanding Use-After-Free-Style Bugs

Вади корупції пам'яті залишаються одним із найбільш стійких класів вразливостей у системному програмному забезпеченні, і розуміння механіки, що їх лежить в основі, важливо для будь-кого, хто працює у дослідженні вразливостей, безпечному кодуванні або пом'якшенні експлойтів. "PUDA" — це термін, що використовується неформально в деяких спільнотах безпеки для опису Premature Use of Dangling Access — категорії вад, де програма посилається на пам'ять (покажчик, дескриптор або посилання на об'єкт) після того, як ця пам'ять була звільнена, перерозподілена або інакше визнана недійсною. Це тісно пов'язано з проблемами use-after-free (UAF) та dangling pointer і часто використовується як взаємозамінне поняття. Незалежно від того, чи ви зустрічаєте термін PUDA у writeup CTF, науковій роботі чи внутрішньому трекері помилок, базова концепція одна й та сама: застаріле посилання використовується так, ніби воно все ще було дійсним.

Що викликає стан PUDA

По суті, вада PUDA виникає внаслідок невідповідності між фактичним часом життя об'єкта та часом життя, припущеним кодом, що на нього посилається. Поширені першопричини включають:

• Відсутність null-out після free: покажчик звільняється, але не встановлюється на NULL, залишаючи його dangling та доступним для помилкового використання.
• Умови гонки: у багатопоточному коді один потік звільняє об'єкт, тоді як інший потік все ще утримує та використовує посилання на нього (класична сценарій, суміжна з TOCTOU).
• Логіка зворотного виклику та керована подіями: об'єкт знищується під час зворотного виклику, але код, що викликає, продовжує працювати з ним після повернення зворотного виклику.
• Помилки підрахунку посилань: счетчик посилань об'єкта зменшується неправильно, викликаючи його звільнення, але все ще