Heap Allocators, Object Lifetimes και Memory Debugging — DedSec Project

Ελληνική έκδοση — Μάθημα 116. Οι διεθνείς τεχνικοί όροι, protocol names, standards και commands παραμένουν στα Αγγλικά όπου αυτό αυξάνει την ακρίβεια.

Μελέτησε πώς οργανώνεται το heap, πώς εμφανίζονται lifetime bugs και πώς sanitizers/diagnostic allocators βοηθούν να εντοπίσεις το αρχικό root cause χωρίς weaponization.

Όριο εξουσιοδοτημένης χρήσης: Κάνε πρακτικές δοκιμές μόνο σε συστήματα, κώδικα, λογαριασμούς, captures και lab environments που σου ανήκουν ή για τα οποία έχεις ρητή άδεια. Προτίμησε localhost, synthetic data, disposable VMs/containers και read-only analysis.

Μαθησιακοί στόχοι

Στο τέλος πρέπει να μπορείς να:

• εξηγήσεις το allocator metadata and arenas και να εντοπίσεις trust boundary, state transition και evidence που σχετίζονται με αυτό,
• εξηγήσεις το size classes, bins and caches και να εντοπίσεις trust boundary, state transition και evidence που σχετίζονται με αυτό,
• εξηγήσεις το allocation/free lifecycle και να εντοπίσεις trust boundary, state transition και evidence που σχετίζονται με αυτό,
• εξηγήσεις το use-after-free and stale references και να εντοπίσεις trust boundary, state transition και evidence που σχετίζονται με αυτό,
• εξηγήσεις το double-free and ownership confusion και να εντοπίσεις trust boundary, state transition και evidence που σχετίζονται με αυτό,
• εξηγήσεις το heap fragmentation and determinism και να εντοπίσεις trust boundary, state transition και evidence που σχετίζονται με αυτό,

Μέθοδος ανάλυσης

Χρησιμοποίησε τη Μεθοδολογία Μελέτης. Όρισε ownership/identity, state transition, trust boundary και το ελάχιστο evidence που χρειάζεται για ασφαλή validation.

Βαθιές τεχνικές έννοιες

1. allocator metadata και arenas

Οι heap allocators κρατούν metadata που αντιστοιχούν allocations σε πραγματική μνήμη. Corruption σε arenas ή bookkeeping μπορεί να εμφανιστεί πολύ αργότερα από το αρχικό bug, γι’ αυτό το evidence πρέπει να περιλαμβάνει allocation/free stacks και allocator configuration.

2. size classes, bins και caches

Οι allocators ομαδοποιούν chunks ανά μέγεθος και χρησιμοποιούν caches για απόδοση. Αυτό αλλάζει το πότε επαναχρησιμοποιείται freed memory και εξηγεί γιατί το ίδιο lifetime bug μπορεί να είναι σταθερό σε ένα build και intermittent σε άλλο.

3. allocation/free lifecycle

Κάθε object έχει lifecycle: allocation, initialization, publication, χρήση, ownership transfer, retirement και free. Κατέγραψε ποιος είναι owner σε κάθε φάση και ποια references πρέπει να ακυρώνονται όταν τελειώνει η ζωή του object.

4. use-after-free και stale references

Use-after-free σημαίνει ότι κώδικας χρησιμοποιεί reference αφού το object έχει απελευθερωθεί. Σε ασφαλές research χρησιμοποίησε toy program και sanitizer ώστε να βρεις το πρώτο invalid access και την πραγματική ownership αστοχία.

5. double-free και ownership confusion

Double-free συνήθως δείχνει ότι δύο paths πιστεύουν ότι είναι υπεύθυνα για το ίδιο cleanup. Έλεγξε error paths, reference counting και shared ownership ώστε μία μόνο component να εκτελεί final destruction.

6. heap fragmentation και determinism

Fragmentation και allocator state επηρεάζουν τη θέση μελλοντικών allocations. Μην θεωρείς σταθερά addresses ή layout από ένα run· σύγκρινε επαναλήψιμα allocation traces και versions.

7. guard allocators και quarantine

Guard pages, quarantine και delayed reuse κάνουν invalid access να αποτυγχάνει νωρίτερα και πιο κοντά στη ρίζα του bug. Είναι diagnostic hardening με κόστος σε memory/performance, όχι από μόνο του διόρθωση του ownership model.

8. ASan, GWP-ASan και heap diagnostics

ASan και sampled diagnostics όπως GWP-ASan μπορούν να δείξουν out-of-bounds και lifetime violations. Επιβεβαίωσε first bad access, allocation/free stack, build flags και ότι το finding εξαφανίζεται μετά το code fix.

Engineering focus

Μετέτρεψε κάθε σημαντικό claim σε security invariant και regression test. Προτίμησε controls που μειώνουν authority, κάνουν explicit το state και αφήνουν αρκετή telemetry για root-cause analysis.

Μοτίβα αστοχίας

• Confused deputy: privileged component ενεργεί για caller χωρίς επαρκή έλεγχο authority/context.
• Identity/context confusion: issuer, subject, tenant, role, origin, audience ή resource χρησιμοποιείται σε λάθος security context.
• State/replay failure: valid state γίνεται δεκτό όταν είναι stale, duplicated, revoked, reordered ή σε λάθος workflow step.
• Parser mismatch: δύο layers ερμηνεύουν διαφορετικά το ίδιο input/configuration.
• Excess authority: service, process, token, key ή admin role έχει περισσότερα permissions από όσα χρειάζεται.
• Telemetry gap: δεν καταγράφεται αρκετό actor/resource/policy/result context ώστε να γίνει αξιόπιστο investigation.

Αμυντικό checklist

1. Γράψε το security invariant πριν από το test.
2. Μείωσε permissions/capabilities και lifetime όσο γίνεται.
3. Κάνε validation στο component που παίρνει την τελική security απόφαση.
4. Δέσε identity/state με σωστό tenant, resource, audience, origin ή protocol phase.
5. Βάλε explicit schemas, allowlists, resource limits και ασφαλή failure behavior.
6. Κατέγραψε actor, resource, operation, policy/version και result χωρίς secrets.
7. Προετοίμασε rollback/recovery πριν από state-changing lab.

Καθοδηγούμενο εργαστήριο

• Εργαστήριο 1 — Κατασκεύασε ένα μικρό τοπικό πρόγραμμα C/C++ με σκόπιμα λανθασμένο χρόνο ζωής αντικειμένου και παρατήρησέ το με sanitizer.

• Εργαστήριο 2 — Σχεδίασε χρονογραμμή δεσμεύσεων μνήμης με μεταβίβαση ιδιοκτησίας, αποδέσμευση, παρωχημένη αναφορά και στοιχεία κατάρρευσης.

Εργαστήριο 3 — Σύγκρινε το ίδιο ασφαλές εκπαιδευτικό σφάλμα με ενεργοποιημένα και απενεργοποιημένα διαγνωστικά του διαχειριστή μνήμης.

Για κάθε lab χρησιμοποίησε owned/synthetic inputs και κράτησε objective, scope, version, expected/observed behavior, cleanup, remediation και regression result σύμφωνα με τη Μεθοδολογία Μελέτης.

Evidence που αξίζει να κρατήσεις

• version/build και σχετικό configuration χωρίς secrets,
• μικρό διάγραμμα trust boundaries και data/state flow,
• sanitized logs, traces ή packet metadata,
• ακριβές test input με synthetic values,
• before/after αποτέλεσμα remediation,
• limitations και μη ελεγμένες υποθέσεις.

Συχνά λάθη

• Αντιγραφή command χωρίς κατανόηση του mechanism.
• Χρήση production/τρίτου συστήματος ενώ αρκεί localhost ή synthetic data.
• Σύγχυση authentication με authorization, encryption με trust ή signature με safety.
• Θεώρηση ενός alert ως οριστικής απόδειξης.
• Παράβλεψη version, timing, identity context, parser behavior ή recovery.

Έλεγχος γνώσεων

1. Ποιο είναι το βασικό trust boundary;
2. Ποιο state/identity μπορεί να γίνει stale ή να χρησιμοποιηθεί σε λάθος context;
3. Ποιο evidence θα σε έκανε να απορρίψεις την αρχική υπόθεση;
4. Ποιο control μειώνει πραγματικά authority/blast radius;
5. Πώς θα κάνεις ασφαλές retest μετά τη remediation;

Πλήρες αγγλικό μάθημα

English Module 116

Επόμενα μαθήματα

Σχετικά modules: 053, 065, 066, 068, 099, 109. Από το κύριο menu επίλεξε Αναζήτηση μαθημάτων για να βρεις σχετικά θέματα σε όλο το project.