CVE-2026-97631: το κενό στο UEFI που χτυπά τους servers πριν ξεκινήσει το λειτουργικό

Είδα ένα σύντομο βίντεο του UFD Tech που λέει ότι, όπως έγινε με την PHP, έτσι μπορεί τώρα να συμβεί και στα data centers: ένα κενό 9,5 στα 10 στο firmware των servers, που κανονικά θα έβγαινε στη δημοσιότητα τον Ιανουάριο του 2027, έγινε γνωστό νωρίτερα, και τώρα υπάρχει αγώνας δρόμου να ενημερωθούν οι servers πριν προλάβουν οι επιτιθέμενοι.

Το βίντεο έχει δίκιο στο βασικό. Έψαξα όμως τις πηγές, και η εικόνα έχει περισσότερες αποχρώσεις: το πρόβλημα είναι σοβαρό, αλλά δεν αφορά κάθε server κάθε στιγμή. Το βίντεο μιλά για δημοφιλή «μάρκα» BIOS, όμως δεν πρόκειται για μάρκα. Πρόκειται για κοινό κώδικα ανοιχτού λογισμικού, που είναι κι ο λόγος που το θέμα απλώνεται τόσο.

Τι βρέθηκε

Το κενό είναι το CVE-2026-97631, με βαθμολογία 9,5 στα 10 (CVSS 4.0), και περιγράφεται στην επίσημη ανακοίνωση του TianoCore της 22ας Οκτωβρίου. Βρίσκεται στο EDK II, τον ανοιχτό κώδικα που χρησιμοποιούν οι κατασκευαστές για να φτιάξουν το UEFI firmware, δηλαδή ό,τι τρέχει πρώτο όταν ανοίγει ένα μηχάνημα. Πάνω του χτίζουν οι AMI, Insyde και Phoenix, αλλά και το Project Mu της Microsoft.

Το πρόβλημα είναι στον driver του PXE, της εκκίνησης μέσω δικτύου. Όσο ένα μηχάνημα κάνει PXE boot, περιμένει μηνύματα σφάλματος ICMP και τα αντιγράφει σε ένα σταθερό πεδίο 504 byte. Ο έλεγχος μεγέθους είναι λάθος, και στο IPv4 και στο IPv6, οπότε ένα μεγαλύτερο μήνυμα γράφει πέρα από το πεδίο, με περιεχόμενο που διαλέγει ο επιτιθέμενος.

Το αποτέλεσμα, σύμφωνα με την ανακοίνωση, είναι ένα από τα δύο:

• Κόλλημα της εκκίνησης, οπότε το μηχάνημα δεν φτάνει ποτέ στην εγκατάσταση ή στην ανάκτηση.
• Εκτέλεση κώδικα στο υψηλότερο επίπεδο δικαιωμάτων, αν ο επιτιθέμενος γνωρίζει το ακριβές firmware του στόχου.

Το δεύτερο είναι που τρομάζει, γιατί συμβαίνει πριν το Secure Boot ή το measured boot ελέγξουν οτιδήποτε από το λειτουργικό. Κανένα antivirus και κανένα EDR δεν τρέχει ακόμα εκείνη την ώρα. Το ίδιο το payload δεν μένει μόνιμα, τρέχει μία φορά, αλλά όπως γράφει το Ars Technica αφήνει ανοιχτό δρόμο για να εγκατασταθεί κάτι άλλο που θα τρέχει νωρίς σε κάθε εκκίνηση. Ο HD Moore της Dragos είπε ότι αυτό θα μπορούσε να χρησιμοποιηθεί για να σπάσει η κρυπτογράφηση δίσκου σε περιπτώσεις όπου ο επιτιθέμενος έχει σύντομη πρόσβαση στο δίκτυο.

Πως έγινε γνωστό νωρίτερα

Το κενό το βρήκαν ο Alex Matrosov (Anthropic) και ο Dan Holmes-Mitra (Google), και η δημοσιοποίηση είχε προγραμματιστεί για τον Ιανουάριο του 2027, ώστε να προλάβουν οι κατασκευαστές. Τον Σεπτέμβριο όμως μια δημόσια αλλαγή κώδικα, υπογεγραμμένη από μηχανικό της AMI, ανέφερε το CVE και περιείχε τη διόρθωση. Από εκεί και πέρα το μυστικό είχε χαθεί:

Ημερομηνία	Τι έγινε
Σεπτέμβριος	Δημόσια αλλαγή κώδικα από την AMI
15 Οκτωβρίου	Η διόρθωση μπαίνει στον κώδικα του EDK II
22 Οκτωβρίου	Ανακοίνωση του TianoCore
26 Οκτωβρίου	Το Project Mu βγάζει builds με τη διόρθωση
Ιανουάριος 2027	Η αρχικά προγραμματισμένη δημοσιοποίηση

Έρχεται λίγες μέρες μετά το PHP2Shell, όπου επίσης οι λεπτομέρειες βγήκαν νωρίτερα από το σχέδιο.

Ποιους αφορά πραγματικά

Ο τίτλος του Ars Technica, που φαίνεται και στο βίντεο, μιλά για τους περισσότερους servers του πλανήτη. Αυτό περιγράφει πόσο διαδεδομένος είναι ο κώδικας, όχι πόσα μηχανήματα μπορούν να δεχτούν επίθεση σήμερα. Οι περιορισμοί είναι πραγματικοί:

• Χρειάζεται PXE boot σε εξέλιξη. Τα μηχανήματα που ξεκινούν μόνο από τοπικό δίσκο δεν επηρεάζονται. Το παράθυρο κρατά όσο κρατά η εκκίνηση.
• Χρειάζεται προσαρμογή. Ένα exploit πρέπει να ταιριάζει στο firmware και τη διαμόρφωση του στόχου.
• Δεν είναι ξεκάθαρο ποια συστήματα επηρεάζονται. Η Intel λέει ότι δεν γνωρίζει επηρεαζόμενο προϊόν της στα υποστηριζόμενα εμπορικά, αλλά οι κατασκευαστές συσκευών μπορεί να έχουν προσθέσει τον κώδικα. Η Arm λέει ότι δεν αφορά άμεσα τα προϊόντα της.

Υπάρχει και μία πραγματική ασάφεια. Η ανακοίνωση του TianoCore λέει ότι το μήνυμα μπορεί να έρθει «από οποιαδήποτε απόσταση στο δίκτυο», ενώ οι Red Hat και SUSE το βαθμολογούν ως εκμεταλλεύσιμο από γειτονικό δίκτυο. Εγώ θα σχεδίαζα με βάση το χειρότερο από τα δύο.

Οι πιο εκτεθειμένοι είναι όσοι στήνουν ή ανακτούν μηχανήματα μέσω δικτύου: data centers, hosting, μεγάλα εταιρικά δίκτυα. Στην πράξη, ο πιο ρεαλιστικός κίνδυνος είναι κάποιος που έχει ήδη μπει στο δίκτυο και θέλει να μείνει κρυμμένος κάτω από το λειτουργικό.

Στις πηγές που διάβασα δεν αναφέρεται ενεργή εκμετάλλευση, και στις 27 Οκτωβρίου το κενό δεν ήταν στη λίστα της CISA. Αυτό μπορεί να αλλάξει, αφού η διόρθωση είναι δημόσια και δείχνει πού να κοιτάξει κανείς.

Γιατί θα αργήσει η ενημέρωση

Ο κώδικας της διόρθωσης είναι απλός: ο Jesse Michael της Eclypsium λέει ότι λύνεται με μια βασική αλλαγή, χωρίς ανάκληση κλειδιών. Το δύσκολο είναι η διαδρομή. Η διόρθωση πρέπει να περάσει από το EDK II στους προμηθευτές firmware, μετά στους κατασκευαστές, και τέλος στον καθένα που θα περάσει BIOS σε κάθε μηχάνημα, συνήθως με επανεκκίνηση. Μέχρι τις 28 Οκτωβρίου δεν υπήρχε σταθερή έκδοση του EDK II με τη διόρθωση, και οι Red Hat, SUSE και Debian έδειχναν τα πακέτα τους ως επηρεαζόμενα και αδιόρθωτα. Κάποιοι παλιοί servers ίσως δεν πάρουν ποτέ ενημέρωση.

Τι κάνετε τώρα

1. Κλείστε το PXE όπου δεν το χρειάζεστε. Αυτό είναι το σημαντικότερο βήμα και δεν κοστίζει σχεδόν τίποτα. Αφαιρέστε τις καταχωρήσεις δικτύου από τη σειρά εκκίνησης στο BIOS. Σε Linux, το efibootmgr -v δείχνει τι υπάρχει.
2. Όπου το χρειάζεστε, απομονώστε το. Το δίκτυο provisioning σε ξεχωριστό VLAN, με αυστηρούς κανόνες για το ποιος φτάνει εκεί. Αυτό είναι δική μου σύσταση, όχι κάτι που γράφει η ανακοίνωση, που δεν δίνει προσωρινή λύση.
3. Ρωτήστε τον κατασκευαστή. Dell, HPE, Lenovo, Supermicro ή όποιον έχετε, και παρακολουθήστε τις ανακοινώσεις του. Μην υποθέτετε ούτε ότι επηρεάζεστε ούτε ότι όχι.
4. Μην ξεχνάτε τις εικονικές μηχανές. Τα πακέτα edk2 των διανομών είναι το firmware που χρησιμοποιούν VMs με UEFI, άρα ενημερώστε τα μόλις βγουν, ειδικά αν κάνουν network boot.
5. Φτιάξτε λίστα με ό,τι εκκινεί από δίκτυο. Όταν έρθει το firmware, θα ξέρετε από πού να ξεκινήσετε.

Αν έχετε ένα VPS ή ένα site σε hosting, δεν μπορείτε να κάνετε κάτι μόνοι σας: το firmware είναι ευθύνη του παρόχου. Το μόνο που μπορείτε είναι να τον ρωτήσετε.

Πηγές

• TianoCore: GHSA-99cj-7hg9-mp4m
• The Next Web: η διαρροή και η κατάσταση των διορθώσεων
• Techzine: τι επηρεάζεται και τι όχι
• Ars Technica, μέσω Slashdot
• Βίντεο: UFD Tech, «Motherboard Vulnerabilities»