UEFI flaw που απειλεί «τους περισσότερους servers του πλανήτη»

Η ουσία σε μία παράγραφο

Ο reference κώδικας EDK II είναι η βάση πάνω στην οποία χτίζουν firmware οι AMI, Insyde, Phoenix, το Microsoft Project Mu και, μέσω αυτών, μεγάλο μέρος των server vendors και των cloud/virtualization stacks (συμπεριλαμβανομένου του OVMF). Μέσα στο NetworkPkg/UefiPxeBcDxe, οι handlers σφαλμάτων ICMP αντιγράφουν μηνύματα μεγαλύτερα από ένα buffer 504 bytes. Αποτέλεσμα: out-of-bounds write στη μνήμη της φάσης DXE.

Η φράση «οι περισσότεροι servers του πλανήτη» περιγράφει τη διάδοση του κώδικα, όχι ένα internet-wide RCE σε κάθε αναμμένο μηχάνημα. Το παράθυρο είναι στενό: το θύμα πρέπει να βρίσκεται σε PXE / network boot και ο επιτιθέμενος να μπορεί να του στείλει ICMP error στο τοπικό δίκτυο.

Διάνυσμα CVSS 4.0

AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Το 9.5 μένει ψηλά παρά το AT:P, επειδή το subsequent-system impact βαθμολογείται High: όποιος γράφει κώδικα πριν το OS μπορεί να δηλητηριάσει την αλυσίδα εμπιστοσύνης.

DXE Heap Layout & Pool Corruption

Στη φάση DXE (Driver Execution Environment), το UEFI διαχειρίζεται τη μνήμη μέσω των BootServices->AllocatePool() και FreePool(). Η μνήμη οργανώνεται σε δυαδικό heap/pool χωρίς την απομόνωση σελίδων (paging isolation) που προσφέρει ένα σύγχρονο OS.

Όταν ο UefiPxeBcDxe γράφει πέρα από το buffer των 504 bytes, η εγγραφή εισβάλλει απευθείας σε γειτονικά pool head/tail headers ή παρακείμενες δομές όπως τα Protocol Interfaces (π.χ. EFI_PXE_BASE_CODE_PROTOCOL).

Μια αλλοίωση στους Function Pointers αυτών των protocols επιτρέπει την εκτροπή της ροής εκτέλεσης (Control Flow Hijacking) μόλις ο επόμενος driver καλέσει οποιοδήποτε UEFI service, οδηγώντας σε άμεση εκτέλεση payload στο Ring 0 / SMM επίπεδο, παράκαμψη των OS-level protections και πλήρη αλλοίωση της μνήμης.

Περιορισμοί Compiler Mitigations στο EDK II

Σε αντίθεση με τα σύγχρονα Operating Systems, η φάση DXE του UEFI firmware τρέχει σε ένα εξαιρετικά "bare-metal" περιβάλλον με σημαντικούς περιορισμούς στα compiler mitigations:

• Απουσία Stack Canaries (GS/fstack-protector): Πολλοί OEM drivers μεταγλωττίζονται χωρίς ενεργά stack cookies για λόγους μεγέθους execution image και επιδόσεων.
• Περιορισμένο ASLR: Το firmware image φορτώνεται σε προβλέψιμες βάσεις διευθύνσεων (fixed base addresses) κατά το boot cycle, καθιστώντας τα ROP/JOP gadgets εξαιρετικά σταθερά για συγκεκριμένα BIOS builds.
• Μη ενεργό DEP/NX σε παλαιότερες υλοποιήσεις: Σε παλαιότερες DXE υλοποιήσεις, τα data pages του heap παραμένουν executable, επιτρέποντας την απευθείας εκτέλεση shellcode μέσα από το overflowed buffer.

Τι μπορεί να πετύχει

• Boot hang — το πιο αξιόπιστο. Χρήσιμο για άρνηση provisioning σε datacenter που κάνουν μαζικά PXE installs.
• Αυθαίρετος κώδικας pre-OS — ανάγνωση/εγγραφή στη μνήμη firmware της συνεδρίας, πιθανή παράκαμψη της υπόθεσης ότι το measured boot ξεκινά από καθαρή κατάσταση.
• Υπονόμευση TPM / attestation — όχι επειδή «σβήνεται» το TPM, αλλά επειδή μετρήσεις και πολιτικές που εμπιστεύονται το firmware πριν το OS ξεκινούν από ήδη αλλοιωμένο περιβάλλον.
• Εμφύτευση επόμενου σταδίου — οι δημόσιες αναλύσεις λένε ότι το ίδιο το payload δεν είναι persistent από μόνο του. Η επιμονή θα απαιτούσε δεύτερο βήμα (π.χ. αλλοίωση boot path, ESP, ή firmware region), που είναι ξεχωριστό και δυσκολότερο.

Τι δεν μπορεί, απ’ ό,τι ξέρουμε

• Δεν είναι απομακρυσμένο RCE από το internet σε server που bootάρει από τοπικό δίσκο.
• Δεν δίνει από μόνο του αρχική πρόσβαση σε κλειστό δίκτυο. Χρειάζεται ήδη θέση από όπου φτάνουν ICMP errors στον client την ώρα του PXE.
• Δεν υπάρχει, έως 28/10/2026, δημόσιο exploit ή καταχώρηση στο CISA KEV.
• Δεν απαιτεί, σύμφωνα με τις αναφορές, μαζική ανάκληση κλειδιών Secure Boot / ενημέρωση dbx. Η διόρθωση είναι firmware update, όχι rotation του PK/KEK.
• Τα συστήματα σπιτιού και μικρού γραφείου που bootάρουν μόνο από SSD/NVMe είναι εκτός παραθύρου.

Υψηλή πρακτική έκθεση

Datacenters και labs με PXE ενεργό σε κοινό L2/L3 με μη έμπιστους hosts: bare-metal provisioning, HPC, VDI rebuilds, installer networks, disaster-recovery boot.

Hypervisors που σηκώνουν guests με OVMF / EDK II (QEMU, Proxmox, ορισμένα KVM images) όταν το guest κάνει network boot και το virtual NIC είναι προσβάσιμο από άλλους tenants ή από το υπόλοιπο LAN.

Δυνητικά, όχι αυτόματα

Οτιδήποτε ενσωματώνει EDK II ή fork του: AMI Aptio, Insyde, Phoenix, Microsoft Project Mu, firmware clouds και OEMs. Intel και Arm έχουν δηλώσει ότι τα δικά τους εμπορικά προϊόντα δεν επηρεάζονται άμεσα — τα οικοσυστήματα όμως καταναλώνουν EDK II μέσω τρίτων.

Αν το PXE είναι disabled στο setup και δεν υπάρχει network boot path, το vulnerable code μπορεί να κάθεται στο image χωρίς να εκτελείται.

Χαμηλή / εκτός

Λαπτοπ και desktops που bootάρουν μόνο από τοπικό μέσο, με network stack του firmware ανενεργό.

Απομονωμένα provisioning VLANs όπου μόνο ο DHCP/TFTP server μιλάει στους clients και τα ICMP errors φιλτράρονται.

Firmware Forensics & Εργαλεία Ελέγχου (Tooling)

Για να διαπιστώσετε αν ένα BIOS image (ROM/Capsule) περιέχει τον ανεπαρκώς ελεγμένο driver πριν την έκδοση patch από τον OEM, μπορούν να χρησιμοποιηθούν τα εξής εργαλεία:

• UEFITool: Ανοίξτε το .bin / capsule αρχείο και αναζητήστε το GUID του UefiPxeBcDxe module. Κάντε extract το PE32 section για static analysis σε Disassembler (IDA Pro / Ghidra).
• CHIPSEC Framework: Εκτελέστε το Chipsec στο host σύστημα για να αναλύσετε τα UEFI binary modules και τις ρυθμίσεις ασφαλείας της πλατφόρμας:
  chipsec_main -m common.uefi.scan_capsules
• Ghidra / IDA Pro Analysis: Ελέγξτε τη συνάρτηση PxeBcIcmpError() για την παρουσία bounds check πριν την κλήση CopyMem() στο ICMP payload.

Measured Boot & TPM PCR Integrity Validation

Παρότι το Secure Boot δεν εμποδίζει την εκτέλεση εντός του DXE, το Measured Boot καταγράφει την ακεραιότητα των drivers στα Platform Configuration Registers (PCRs) του TPM:

• PCR 0 / PCR 2: Περιέχουν τις μετρήσεις των CRTM, BIOS code, και των DXE Drivers / Option ROMs.
• TPM Event Log Audit: Σε περίπτωση εκμετάλλευσης, η αλλοίωση της μνήμης ή η injection επιπλέον DXE code αλλάζει τα hashes που υποβάλλονται στο TPM, οδηγώντας σε ασυμφωνία στο Event Log (TCG Event Log anomaly).
• Remote Attestation: Συστήματα με ενεργό Remote Attestation (π.χ. Keylime, OpenAttestation) θα αποτύχουν να περάσουν το quote validation, εμποδίζοντας την παροχή secrets/keys στο προσβεβλημένο OS.

Γιατί τα firmware bugs «καίγονται» αργά

Ένα patch στο GitHub του TianoCore δεν φτάνει στη μητρική. Η διαδρομή είναι: upstream → IBV (AMI/Insyde/Phoenix) → OEM/ODM → πιστοποίηση πλατφόρμας → εργαλείο ενημέρωσης BIOS → αλλαγή παράθυρο συντήρησης. Σε servers με υπογεγραμμένο capsule update και διπλό bank firmware, το rollout μετριέται σε εβδομάδες ή μήνες, όχι σε ώρες.

Γι’ αυτό η σωστή άμεση κίνηση δεν είναι «περίμενε το CVE scanner». Είναι μείωση του παραθύρου PXE μέχρι να υπάρξει vendor BIOS που ρητά αναφέρει το CVE ή το GHSA.

Σημείωση: το CVE-2026-97631 είναι διαφορετικό από θέματα UEFI Shell / SPI flash που κυκλοφόρησαν την ίδια περίοδο (π.χ. αναφορές CERT/CC και Cisco UCS). Μην τα συγχωνεύεις σε ένα incident.

Σειρά ενεργειών

1. Απογραφή. Πού είναι ενεργό το PXE, HTTP boot, ή network boot σε BIOS/UEFI setup, σε NIC option ROM και σε OVMF guests. Συμπεριέλαβε IPMI/BMC reinstall flows και cluster provisioning (MAAS, Foreman, Ironic, Autounattend, iPXE).
2. Σβήσε ό,τι δεν χρησιμεύει. Η πιο δυνατή προσωρινή αντιστάθμιση: disable network boot / PXE στο setup και στο boot order. Άφησέ το μόνο σε αφιερωμένο VLAN.
3. Κλείσε το δίκτυο provisioning. Ξεχωριστό L2, χωρίς πρόσβαση από corporate ή guest. DHCP/TFTP/HTTP boot μόνο από γνωστούς servers. Περιόρισε ICMP errors προς τους clients όσο το επιτρέπει ο σχεδιασμός (προσοχή: τυφλό block όλου του ICMP μπορεί να σπάσει PMTU).
4. Σύναψε το παράθυρο. Μην αφήνεις μηχανήματα να κάθονται σε PXE retry loop. Timeout σύντομο, μετά fallback σε δίσκο ή power-off.
5. Πάρε ρητό statement από OEM. Μοντέλο, BIOS revision, αν το image βασίζεται σε EDK II ≤ stable202608 και αν το capsule που δίνουν περιέχει το PR #13302 ή ισοδύναμο IBV fix. Το «τρέχουμε AMI» δεν αρκεί.
6. Virtualization. Παρακολούθησε πακέτα edk2 / OVMF της διανομής. Μέχρι να περάσουν σε stable, μην εκθέτεις PXE guests σε κοινό δίκτυο με μη έμπιστους γείτονες.
7. Κράτα Secure Boot και TPM. Δεν σταματούν αυτό το bug, αλλά περιορίζουν το τι μπορεί να φυτέψει ένας επιτιθέμενος στο επόμενο στάδιο και βοηθούν στον εντοπισμό αποκλίσεων attestation.
8. Μην κυνηγάς dbx revocations για αυτό το CVE, εκτός αν ο κατασκευαστής το ζητήσει ρητά. Λάθος μαζικό dbx κάνει πιο ζημιά από το ίδιο το παράθυρο.

Checklist βάρδιας

• Έγινε inventory PXE/HTTP boot σε φυσικά μηχανήματα και OVMF/Proxmox/KVM.
• PXE σβηστό όπου δεν είναι επιχειρησιακά απαραίτητο.
• Provisioning VLAN απομονωμένο· πρόσβαση μόνο σε γνωστούς boot servers.
• ICMP προς PXE clients περιορισμένο ή υπό παρακολούθηση στο παράθυρο εγκατάστασης.
• Αίτημα advisory προς OEM/IBV με ρητή αναφορά CVE-2026-97631 / GHSA-99cj-7hg9-mp4m.
• Πλάνο capsule update + rollback (dual BIOS / previous revision φυλαγμένο).
• Παρακολούθηση edk2/OVMF packages στις διανομές που φιλοξενούν guests.
• Καμία υπόθεση ότι το Secure Boot «καλύπτει» pre-boot DXE bugs.

0 / 8 ολοκληρωμένα

«Είναι worm στο internet»

Όχι. Θέλει PXE σε εξέλιξη και δυνατότητα αποστολής ICMP error στον client. Δεν σαρώνει το δημόσιο IPv4 από μόνο του.

«Το Secure Boot το σταματά»

Όχι αυτό το στάδιο. Το Secure Boot επαληθεύει bootloaders. Εδώ η εκτέλεση, αν επιτευχθεί, είναι ήδη μέσα στο firmware.

«Κάθε server είναι RCE απόψε»

Όχι. Το DoS στο PXE είναι το σταθερό αποτέλεσμα. Το RCE εξαρτάται από το build. Χωρίς PXE, το bug κοιμάται.

«Θέλει νέο dbx άμεσα»

Οι ως τώρα αναφορές λένε πως όχι. Λάθος revocation κλειδιών μπλοκάρει νόμιμα boot πιο σίγουρα απ’ ό,τι αυτό το CVE.

«Ίδιο με τα UEFI Shell bugs»

Όχι. Ξεχωριστή οικογένεια θεμάτων SPI/Shell κυκλοφορεί παράλληλα. Άλλο component, άλλο mitigation.

«Αφού δεν είναι στο KEV, αγνόησέ το»

Το KEV καταγράφει γνωστή εκμετάλλευση, όχι θεωρητικό κίνδυνο. Εδώ το asset είναι το firmware supply chain και το παράθυρο είναι ήδη δημόσιο λόγω του diff.