CVE-2026-31431 (Copy Fail) - Πώς το αντιμετωπίσαμε

Την προηγούμενη εβδομάδα αποκαλύφθηκε μια σοβαρή τοπική κλιμάκωση προνομίων στον πυρήνα Linux: CVE-2026-31431, με το παρατσούκλι "Copy Fail". Επηρεάζει ένα ευρύ φάσμα εκδόσεων πυρήνα σε σύγχρονες διανομές Linux και ένα δημόσιο exploit εμφανίστηκε γρήγορα μετά την αποκάλυψη.

Θέλω να είμαι ξεκάθαρος για το τι συνέβη, τι σημαίνει για το Appbox και τι κάναμε γι' αυτό. Η σύντομη εκδοχή: χάρη στον τρόπο με τον οποίο είναι φτιαγμένα τα containers μας, οι εφαρμογές που εκτελούνται με user namespace remapping ήταν ήδη προστατευμένες από το να μετατραπεί αυτό σε host root, ακόμη και πριν διατεθούν οι διορθωμένοι πυρήνες. Χθες (May 4, 2026), πραγματοποιήσαμε επίσης έκτακτη συντήρηση για να αναβαθμίσουμε κάθε server σε διορθωμένο πυρήνα, οπότε το σφάλμα έχει πλέον εξαλειφθεί πλήρως από τον στόλο μας.

Τι είναι το "Copy Fail";

Το CVE-2026-31431 είναι ένα σφάλμα στο κρυπτογραφικό API AF_ALG του πυρήνα. Με σύνδεση σε έναν συγκεκριμένο cipher (authencesn(hmac(sha256),cbc(aes))) και κατάχρηση του τρόπου με τον οποίο ο πυρήνας ενώνει pages σε ένα scratch buffer, ένας μη προνομιούχος τοπικός χρήστης μπορεί να γράψει αυθαίρετα τμήματα 4 byte απευθείας στο page cache αρχείων που δεν θα έπρεπε να έχει δικαίωμα να τροποποιήσει - συμπεριλαμβανομένων SUID binaries όπως το /usr/bin/su.

Μόλις το αντίγραφο του su στο page cache αντικατασταθεί με ένα μικροσκοπικό κακόβουλο ELF, η επόμενη εκτέλεσή του τρέχει τον κώδικα του επιτιθέμενου ως UID 0. Τέλος παιχνιδιού για τον host.

Για τις σκληρές τεχνικές λεπτομέρειες (shellcode disassembly, syscall traces, τα πάντα), η ανάλυση του Andrea Veri είναι εξαιρετική: CVE-2026-31431: Copy Fail vs. rootless containers. Έκανε επίσης τη δουλειά να αποδείξει - με eBPF και αποδείξεις uid_map - ακριβώς αυτό για το οποίο θα μιλήσουμε στη συνέχεια: ότι τα user namespaces εξουδετερώνουν αυτό το exploit.

Γιατί οι εφαρμογές Appbox ήταν ήδη προστατευμένες

Το exploit βασίζεται στο ότι το setuid(0) πράγματι παρέχει host root. Σε ένα container που τρέχει με ενεργοποιημένα user namespaces, δεν συμβαίνει αυτό.

Τα user namespaces αντιστοιχίζουν τον χώρο UID του container σε διαφορετικό (μη προνομιούχο) εύρος UID στον host. Έτσι, όταν το exploit πετυχαίνει μέσα στο container και το setuid(0) επιστρέφει επιτυχία, το "root" shell που προκύπτει αντιστοιχίζεται σε έναν κανονικό μη προνομιούχο χρήστη του host - όχι σε πραγματικό root. Το shellcode εκτελείται, το prompt αλλάζει σε #, αλλά στον host:

podman     27943  0.0  0.0   2984  2028 pts/1    S+   22:15   0:00 sleep 100

Αυτό είναι όλο. Καμία πρόσβαση σε αρχεία του host, κανένα /etc/shadow, κανένα host root. Το όριο του namespace του container εμποδίζει αυτό το περιστατικό να γίνει διαφυγή σε host-root.

Σε επίπεδο πλατφόρμας, κάθε Appbox αποκτά το δικό του Docker daemon που ξεκινά με ενεργοποιημένο user namespace remapping. Σε ψευδοκώδικα, μοιάζει περισσότερο με αυτό:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

Αυτή η αντιστοίχιση υποστηρίζεται από ένα αποκλειστικό subordinate UID/GID range στον host:

write "/etc/subuid" -> "<appbox-id>:<host-subuid-start>:65536"
write "/etc/subgid" -> "<appbox-id>:<host-subgid-start>:65536"

Επιπλέον, οι ορισμοί εφαρμογών μπορούν ακόμη να παρακάμπτουν ρητά το UsernsMode όταν μια εφαρμογή χρειάζεται ειδικό χειρισμό:

container_config = {
  userns_mode: app.userns_mode,
  network_mode: app.network_mode,
  ...
}

Άρα ο ακριβής τρόπος να το περιγράψουμε είναι: το user namespace remapping είναι μέρος της προεπιλογής της πλατφόρμας και οι εξαιρέσεις ανά εφαρμογή είναι ρητές. Υπάρχει ένας μικρός αριθμός εφαρμογών που χρειάζονται διαφορετικές ρυθμίσεις επειδή εκθέτουν λειτουργικότητα που απαιτεί πρόσθετες δυνατότητες, και αυτές οι περιπτώσεις αντιμετωπίζονται ξεχωριστά.

Με άλλα λόγια: για εφαρμογές που εκτελούνται με την κανονική remapped ρύθμιση, το Copy Fail δεν μπορούσε να μετατρέψει μια παραβίαση container σε host root.

Τι θέλαμε ακόμη να διορθώσουμε

Τα user namespaces σταματούν τη διαφυγή στον host, αλλά δεν εξαφανίζουν το σφάλμα μέσα στο container. Ένας επιτιθέμενος θα μπορούσε ακόμη να κλιμακώσει προνόμια σε "container root" εντός του ορίου της εφαρμογής, κάτι που, παρότι περιορισμένο, παραμένει κακή πρακτική ασφαλείας. Ο ίδιος ο πυρήνας ήταν ευάλωτος και θέλαμε αυτό να διορθωθεί.

Μόλις μάθαμε για το σφάλμα, αρχίσαμε αμέσως να αξιολογούμε την έκθεσή μας. Παρότι το user namespace remapping ήδη απέκλειε την πλευρά της διαφυγής στον host για την κανονική ρύθμιση εφαρμογών μας, εξακολουθούσαμε να θέλουμε να εξαλειφθεί το υποκείμενο σφάλμα του πυρήνα όσο το δυνατόν γρηγορότερα.

Τι κάναμε χθες

Το βράδυ της Κυριακής προγραμματίσαμε έκτακτη συντήρηση για τη Monday, May 4, 2026, το νωρίτερο παράθυρο στο οποίο μπορούσαμε να διαθέσουμε μια αναβάθμιση πυρήνα σε όλο τον στόλο.

Κατά τη διάρκεια του παραθύρου:

• Κάθε host αναβαθμίστηκε με τα επίσημα πακέτα πυρήνα Debian που περιείχαν την επιδιόρθωση του "Copy Fail".
• Ο στόχος ήταν απλός: να αφαιρέσουμε πλήρως την ευάλωτη διαδρομή του πυρήνα, όχι απλώς να βασιστούμε στην υπάρχουσα απομόνωση namespaces.

Η συντήρηση ολοκληρώθηκε. Κάθε Appbox host τρέχει πλέον διορθωμένο πυρήνα.

Τι σημαίνει αυτό για εσάς

• Δεν χρειάστηκε να κάνετε τίποτα. Οι εφαρμογές σας συνέχισαν να λειτουργούν και τυχόν σύντομες διακοπές κατά το παράθυρο συντήρησης ήταν το μόνο ορατό αποτέλεσμα για τους πελάτες.
• Ακόμη και πριν από τη χθεσινή επιδιόρθωση, το user namespace remapping σήμαινε ότι αυτό το σφάλμα δεν μπορούσε να μετατρέψει μια κανονική παραβίαση εφαρμογής σε host root. Αυτό είναι ακριβώς το είδος σεναρίου για το οποίο υπάρχει αυτό το μοντέλο απομόνωσης.
• Από εδώ και πέρα, η πολιτική μας δεν αλλάζει: τα user namespaces παραμένουν ενεργά από προεπιλογή και οι πολύ λίγες εξαιρέσεις περνούν από πρόσθετο έλεγχο ασφαλείας.

Η ευρύτερη εικόνα

Αυτό είναι ένα από εκείνα τα CVE όπου ο τίτλος ("τοπική κλιμάκωση προνομίων, δημόσιο exploit, κάθε σύγχρονος πυρήνας επηρεάζεται") ακούγεται καταστροφικός, και για πολλά περιβάλλοντα με κοινόχρηστους tenants πράγματι ήταν. Ο λόγος που δεν ήταν καταστροφικός για εμάς είναι ο ίδιος λόγος για τον οποίο πήραμε αρχιτεκτονικές αποφάσεις πριν από χρόνια που μερικές φορές μας κοστίζουν λίγη συμβατότητα: τρέχουμε τις εφαρμογές με την αρχή των ελάχιστων προνομίων ενσωματωμένη στο επίπεδο container, όχι προσαρμοσμένη εκ των υστέρων.

Η άμυνα σε βάθος πραγματικά λειτουργεί. Σφάλμα στο επίπεδο του πυρήνα; Το επίπεδο namespace το έπιασε. Σφάλμα στο επίπεδο namespace; Τα capability drops και το seccomp πιάνουν το μεγαλύτερο μέρος. Δεν προσποιούμαστε ότι οποιοδήποτε μεμονωμένο επίπεδο είναι τέλειο, απλώς φροντίζουμε να υπάρχει πάντα ένα επόμενο.

Αν έχετε οποιαδήποτε ερώτηση σχετικά με αυτό ή για το πώς είναι ρυθμισμένες οι δικές σας συγκεκριμένες εφαρμογές, επικοινωνήστε μαζί μας.

Έχετε ερωτήσεις; Επικοινωνήστε μαζί μας στο support@appbox.co ή ανοίξτε ticket στο billing.appbox.co.