Ο Kees Cook, πρώην CSO του kernel.org και επικεφαλής της Ομάδας Ασφαλείας του Ubuntu, ο οποίος τώρα εργάζεται για την Google για την ασφάλεια του Android και του ChromeOS, εξέφρασε την ανησυχία του για την τρέχουσα διαδικασία διόρθωσης σφαλμάτων στα σταθερά κλαδιά του πυρήνα. Κάθε εβδομάδα, περίπου εκατό επιδιορθώσεις περιλαμβάνονται σε σταθερούς κλάδους και μετά το κλείσιμο του παραθύρου για αποδοχή αλλαγών στην επόμενη έκδοση, πλησιάζει τις χίλιες (οι συντηρητές κρατούν διορθώσεις μέχρι να κλείσει το παράθυρο και μετά το σχηματισμό του "-rc1" δημοσιεύστε τα συσσωρευμένα ταυτόχρονα), κάτι που είναι πάρα πολύ και απαιτεί πολλή εργασία για προϊόντα συντήρησης που βασίζονται στον πυρήνα του Linux.
Σύμφωνα με τον Keys, δεν δίνεται η δέουσα προσοχή στη διαδικασία εργασίας με σφάλματα στον πυρήνα και στον πυρήνα λείπουν τουλάχιστον 100 επιπλέον προγραμματιστές για συντονισμένη εργασία σε αυτόν τον τομέα. Οι προγραμματιστές πυρήνα του πυρήνα διορθώνουν σφάλματα σε τακτική βάση, αλλά δεν υπάρχει καμία εγγύηση ότι αυτές οι διορθώσεις θα μεταφερθούν σε παραλλαγές του πυρήνα που χρησιμοποιούνται από τρίτα μέρη. Οι χρήστες διαφόρων προϊόντων που βασίζονται στον πυρήνα Linux δεν έχουν επίσης τρόπο να ελέγξουν ποια σφάλματα διορθώνονται και ποιος πυρήνας χρησιμοποιείται στις συσκευές τους. Οι πωλητές είναι τελικά υπεύθυνοι για την ασφάλεια των προϊόντων τους, αλλά με πολύ υψηλό ποσοστό επιδιόρθωσης στους σταθερούς κλάδους του πυρήνα, βρέθηκαν αντιμέτωποι με την επιλογή μεταξύ του backport όλων των patches, της επιλεκτικής μεταφοράς των πιο σημαντικών ή της παράβλεψης όλων των patches.
Η βέλτιστη λύση θα ήταν η μετεγκατάσταση μόνο των πιο σημαντικών επιδιορθώσεων και τρωτών σημείων, αλλά η απομόνωση τέτοιων σφαλμάτων από τη γενική ροή είναι το κύριο πρόβλημα. Τα περισσότερα από τα προβλήματα που εμφανίζονται οφείλονται στη χρήση της γλώσσας C, η οποία απαιτεί μεγάλη προσοχή όταν ασχολείστε με τη μνήμη και τους δείκτες. Για να γίνουν τα πράγματα χειρότερα, πολλές πιθανές επιδιορθώσεις ευπάθειας δεν παρέχονται με αναγνωριστικά CVE ή λαμβάνουν ένα τέτοιο αναγνωριστικό λίγο καιρό μετά τη δημοσίευση της ενημέρωσης κώδικα. Κάτω από τέτοιες συνθήκες, είναι πολύ δύσκολο για τους κατασκευαστές να διαχωρίσουν τις δευτερεύουσες επιδιορθώσεις από τα μεγάλα ζητήματα ασφαλείας. Σύμφωνα με στατιστικά στοιχεία, πάνω από το 40% των ευπαθειών επιδιορθώνονται πριν από την εκχώρηση ενός CVE και η μέση καθυστέρηση μεταξύ της έκδοσης μιας ενημέρωσης κώδικα και της εκχώρησης ενός CVE είναι τρεις μήνες (δηλαδή, στην αρχή, η ενημέρωση κώδικα γίνεται αντιληπτή ως κοινή σφάλμα, αλλά μόνο μετά από λίγους μήνες γίνεται σαφές ότι η ευπάθεια έχει διορθωθεί).
Ως αποτέλεσμα, χωρίς να υπάρχει ξεχωριστός κλάδος με διορθώσεις για τρωτά σημεία και χωρίς να λαμβάνουν πληροφορίες σχετικά με τη σύνδεση ασφαλείας ενός συγκεκριμένου προβλήματος, οι κατασκευαστές προϊόντων που βασίζονται στον πυρήνα του Linux αφήνονται να μεταφέρουν συνεχώς όλες τις επιδιορθώσεις από φρέσκα σταθερά υποκαταστήματα. Αλλά αυτή η εργασία απαιτεί πολλή εργασία και συναντά αντίσταση στις εταιρείες λόγω του φόβου οπισθοδρομικών αλλαγών που μπορεί να διαταράξουν την κανονική λειτουργία του προϊόντος.
Θυμηθείτε ότι, σύμφωνα με τον Linus Torvalds, όλα τα σφάλματα είναι σημαντικά και τα τρωτά σημεία δεν πρέπει να διαχωρίζονται από άλλους τύπους σφαλμάτων και να κατανέμονται σε μια ξεχωριστή κατηγορία υψηλότερης προτεραιότητας. Αυτή η γνώμη εξηγείται από το γεγονός ότι για έναν συνηθισμένο προγραμματιστή που δεν ειδικεύεται σε θέματα ασφάλειας, η σύνδεση μεταξύ μιας επιδιόρθωσης και μιας πιθανής ευπάθειας δεν είναι προφανής (για πολλές επιδιορθώσεις, μόνο ένας ξεχωριστός έλεγχος σάς επιτρέπει να κατανοήσετε ότι σχετίζονται με την ασφάλεια ). Σύμφωνα με τον Linus, εναπόκειται στις ομάδες ασφαλείας των ομάδων που είναι υπεύθυνες για τη διατήρηση των πακέτων πυρήνα σε διανομές Linux να απομονώσουν πιθανά τρωτά σημεία από τη γενική ροή ενημερώσεων κώδικα.
Ο Kees Cook πιστεύει ότι η μόνη λύση για να διατηρηθεί ο πυρήνας ασφαλής με λογικό μακροπρόθεσμο κόστος είναι οι εταιρείες να μετακινήσουν τους μηχανικούς που εμπλέκονται στη μεταφορά ενημερώσεων κώδικα σε τοπικές εκδόσεις πυρήνα για να εργαστούν συλλογικά και συντονισμένα για να διατηρήσουν τα patches και τα τρωτά σημεία στον upstream πυρήνα. Στην τρέχουσα μορφή του, πολλοί κατασκευαστές δεν χρησιμοποιούν μόνοι τους την πιο πρόσφατη έκδοση πυρήνα στα προϊόντα τους και διορθώσεις backport, π.χ. αποδεικνύεται ότι μηχανικοί σε διαφορετικές εταιρείες αντιγράφουν τη δουλειά του άλλου, λύνοντας το ίδιο πρόβλημα.
Για παράδειγμα, εάν 10 εταιρείες, η καθεμία με έναν μηχανικό που υποστηρίζει τις ίδιες διορθώσεις, ανακατευθύνουν αυτούς τους μηχανικούς για να διορθώσουν σφάλματα ανάντη, τότε αντί να μεταφέρουν μία επιδιόρθωση, θα μπορούσαν να διορθώσουν 10 διαφορετικά σφάλματα για το κοινό καλό ή να συμμετάσχουν στην αναθεώρηση των προτεινόμενων αλλαγών. και αποτρέψτε τον κώδικα buggy να συμπεριληφθεί στον πυρήνα. Οι πόροι θα μπορούσαν επίσης να αφιερωθούν στη δημιουργία νέων εργαλείων για δοκιμές και ανάλυση κώδικα, τα οποία θα επέτρεπαν σε πρώιμο στάδιο να εντοπίζονται αυτόματα τυπικές κατηγορίες σφαλμάτων που εμφανίζονται ξανά και ξανά.
Η Kees Cook προτείνει επίσης πιο ενεργή χρήση αυτοματοποιημένων και ασαφούς δοκιμών απευθείας στη διαδικασία ανάπτυξης πυρήνα, τη χρήση συστημάτων συνεχούς ενοποίησης και την εγκατάλειψη της αρχαϊκής διαχείρισης ανάπτυξης μέσω email. Επί του παρόντος, η αποτελεσματική δοκιμή παρεμποδίζεται από το γεγονός ότι οι κύριες διαδικασίες δοκιμών διαχωρίζονται από την ανάπτυξη και συμβαίνουν μετά το σχηματισμό των εκδόσεων. Τα κλειδιά συνιστούν επίσης τη χρήση πιο ασφαλών γλωσσών, όπως η Rust, για τη μείωση των σφαλμάτων.
Πηγή: opennet.ru