Błędy związane z korupcją pamięci pozostają jedną z najbardziej uporczywych klas vulnerabilności w oprogramowaniu systemowym, a zrozumienie mechaniki stojącej za nimi jest istotne dla każdego pracującego w badaniach vulnerabilności, bezpiecznym kodowaniu lub ograniczaniu exploitów. "PUDA" to termin używany nieformalnie w niektórych społecznościach bezpieczeństwa do opisania Premature Use of Dangling Access — kategorii błędów, w której program odwołuje się do pamięci (wskaźnika, handle'a lub referencji do obiektu) po tym, jak ta pamięć została zwolniona, ponownie przydzielona lub innym sposobem unieważniona. Jest to ściśle powiązane z, i często używane zamiennie z, use-after-free (UAF) oraz problemami z wiszącymi wskaźnikami. Niezależnie od tego, czy spotykasz termin PUDA w writeupie CTF, artykule badawczym czy wewnętrznym trackerze błędów, koncepcja leżąca u podstaw jest ta sama: stara referencja używana tak, jakby była wciąż ważna.
Co powoduje warunek PUDA
W swojej istocie, błąd PUDA wynika z niezgodności między rzeczywistym czasem życia obiektu a czasem życia założonym przez kod, który go odwołuje. Typowe przyczyny źródłowe obejmują:
- Brak zerowania po zwolnieniu: wskaźnik jest zwolniony, ale nie ustawiony na
NULL, pozostawiając go wiszącym i przypadkowo ponownie używanym. - Race conditions: w kodzie wielowątkowym jeden wątek zwalnia obiekt, podczas gdy inny wątek nadal utrzymuje i używa do niego referencję (klasyczny scenariusz zbliżony do TOCTOU).
- Logika callback'ów i zdarzeń: obiekt jest niszczony podczas callback'u, ale kod wywołujący kontynuuje operacje na nim po powrocie callback'u.
- Błędy liczenia referencji: licznik referencji obiektu jest zmniejszany niepoprawnie, powodując jego zwolnienie mimo iż wciąż