Theo De Raadt σχεδιάζει να ενισχύσει τον μηχανισμό προστασίας μνήμης W^X (Write XOR Execute). Η ουσία του μηχανισμού είναι ότι οι σελίδες μνήμης διεργασίας δεν μπορούν να προσπελαστούν ταυτόχρονα για εγγραφή και εκτέλεση. Έτσι, ο κώδικας μπορεί να εκτελεστεί μόνο αφού απενεργοποιηθεί η εγγραφή και η εγγραφή σε μια σελίδα μνήμης είναι δυνατή μόνο μετά την απενεργοποίηση της εκτέλεσης. Ο μηχανισμός W^X βοηθά στην προστασία των εφαρμογών χώρου χρήστη από κοινές επιθέσεις υπερχείλισης buffer, συμπεριλαμβανομένων υπερχείλισης στοίβας, και είναι ενεργός στο OpenBSD .
Από την αρχή των εργασιών στο W^X, ήταν σαφές ότι επρόκειτο για μακρύ δρόμο, καθώς υπήρχε σημαντικός αριθμός εφαρμογών που χρησιμοποιούν JIT. Οι υλοποιήσεις JIT μπορούν να χωριστούν σε τρεις κατηγορίες:
- Εναλλαγή μνήμης μεταξύ καταστάσεων W και X, αποδοχή του «κόστους» της κλήσης συστήματος .
- Δημιουργία ψευδωνύμων μεταξύ ενός ζεύγους αντιστοιχίσεων W και X της ίδιας μνήμης.
- Η πιο «βρώμικη» επιλογή απαιτεί ένα μοντέλο μνήμης W|X που επιτρέπει την ταυτόχρονη εγγραφή και εκτέλεση.
Επί του παρόντος, υπάρχουν σημαντικά λιγότερα προγράμματα που χρησιμοποιούν την τρίτη επιλογή και περισσότερα που χρησιμοποιούν την πρώτη και τη δεύτερη. Ωστόσο, δεδομένου ότι ήταν απαραίτητο να εκτελούνται προγράμματα με W|X JIT (κυρίως Chromium και Iridum), προστέθηκε μια επιλογή "wxallowed" προσάρτησης συστήματος αρχείων, η οποία επέτρεπε τη χρήση της μνήμης ταυτόχρονα τόσο για εγγραφή όσο και για εκτέλεση, σε περίπτωση που το εκτελέσιμο ELF Το αρχείο επισημαίνεται με τον δείκτη "wxneeded" και οι ίδιες οι εφαρμογές προστατεύτηκαν επιπλέον με τη χρήση μηχανισμών и για να περιορίσετε τη λίστα των κλήσεων συστήματος που χρησιμοποιούνται και τα μέρη του συστήματος αρχείων που είναι διαθέσιμα στην εφαρμογή, αντίστοιχα.
Για να περιπλέξει περαιτέρω την εκμετάλλευση των τρωτών σημείων σε τέτοιες εφαρμογές, προτείνεται μια προσθήκη στον μηχανισμό , το οποίο ελέγχει εάν η κλήση συστήματος εκτελείται από μια εγγράψιμη σελίδα μνήμης. Εάν η σελίδα είναι εγγράψιμη, η διαδικασία αναγκάζεται να τερματιστεί. Με αυτόν τον τρόπο, ένας εισβολέας δεν θα είναι σε θέση να εκμεταλλευτεί τις κλήσεις συστήματος και θα αναγκαστεί να προσπαθήσει να βρει τα απαραίτητα gadget στην εφαρμογή JIT ή ακόμα και να κάνει την πιο δύσκολη δουλειά του εντοπισμού στελέχη κλήσεων συστήματος απευθείας μέσα .
Οι διεργασίες Chrome/Iridium προστατεύονται ήδη αρκετά αξιόπιστα με χρήση δέσμευσης και αποκάλυψης, αλλά η αφαίρεση της δυνατότητας χρήσης, για παράδειγμα, της κλήσης συστήματος εγγραφής(2) έχει προφανώς κάποιο πλεονέκτημα, καθώς δημιουργεί πρόσθετες δυσκολίες στον εισβολέα. Ωστόσο, μπορεί επίσης να προκύψουν δυσκολίες εάν η υλοποίηση JIT χρησιμοποιεί εγγενείς κλήσεις συστήματος από τη μνήμη W|X. Ωστόσο, υπάρχει λόγος να ελπίζουμε ότι αυτό δεν θα συμβεί, αφού το ABI έχει αλλάξει αρκετές φορές, αλλά κανείς δεν ανέφερε ποτέ προβλήματα.
Οι αλλαγές είναι ήδη διαθέσιμες σε κανονικά στιγμιότυπα του κλάδου OpenBSD-Current, όλοι οι ενδιαφερόμενοι καλούνται να δοκιμάσουν.
Σχετικές ειδήσεις σχετικά με την εμφάνιση της λειτουργίας στο Chrome/Iridium αξίζουν ένα ξεχωριστό σχόλιο από τον Theo . Από την άποψή του, αυτό είναι αποδεκτό για ορισμένα μοντέλα χρήσης, αλλά πιθανότατα όχι για όλα, καθώς αυτή η λειτουργία προφανώς θα αυξήσει το φορτίο στον επεξεργαστή. Επί του παρόντος, το Chrome θα λειτουργεί ως επί το πλείστον εάν απενεργοποιήσετε το "wxallowed" για το /usr/local, αν και ενδέχεται να υπάρχουν προβλήματα με ορισμένες επεκτάσεις (το ghostery είναι ένα παράδειγμα). Με τον ένα ή τον άλλο τρόπο, ο Theo ελπίζει ότι η πλήρης εργασία σε λειτουργία JITless θα τεθεί σε πλήρη λειτουργία στο εγγύς μέλλον.
Πηγή: opennet.ru