H ετήσια αναφορά του για το 2020, το Github , με την ονομασία «The 2020 State of the Octoverse» , είναι χωρισμένη σε τρεις τομείς ενδιαφέροντος: παραγωγικότητα, κοινότητα και ασφάλεια. Δε θα σχολιάσω εκτενώς τους δύο πρώτους αλλά θα εστιάσω κυρίως στον τελευταίο, ο οποίος αφορά το επίπεδο της ασφάλειας των έργων ανοιχτού κώδικα που αναπτύσσονται σε αποθετήρια της πλατφόρμας. O σχετικός σύνδεσμος θα είναι διαθέσιμος στο τέλος του άρθρου.
Διαβάζοντας την ενότητα της αναφοράς που τιτλοφορείται «Securing the world’s software» (ελλ. «Ασφαλίζοντας το λογισμικό του κόσμου»), αντλούμε σημαντικές πληροφορίες για την πραγματική κατάσταση της ασφάλειας του λογισμικού ανοιχτού κώδικα. Σαφέστατα, το GitHub δε φιλοξενεί το σύνολο αυτού του λογισμικού. Περιέχει, όμως, μακράν τον μεγαλύτερο αριθμό τέτοιων έργων, και έτσι μπορούμε να πούμε με σχετική βεβαιότητα ότι τα στοιχεία που παρέχονται αντικατοπτρίζουν σε πολύ μεγάλο βαθμό τη γενικότερη εικόνα.
Ο κώδικας του κόσμου
Πιθανότατα, είναι λιγότερο γνωστό από όσο οι ίδιοι οι χρήστες του (θέλουμε να) πιστεύουμε αλλά ο ανοιχτός κώδικας κινεί τον κόσμο στον οποίο ζούμε και βρίσκεται παντού. Με αυτό ως δεδομένο, είναι εύκολα αντιληπτό ότι η ασφάλεια αποτελεί κρίσιμο κομμάτι και το ίδιο επισημαίνει η εισαγωγή της ενότητας.
Πολλές από τις υπηρεσίες και την τεχνολογία στην οποία βασιζόμαστε όλοι, από τις τράπεζες έως την υγειονομική περίθαλψη, βασίζονται επίσης σε λογισμικό ανοιχτού κώδικα.
Όπως χαρακτηριστικά αναφέρεται, «τα τεχνουργήματα του ανοιχτού κώδικα χρησιμεύουν ως κρίσιμη υποδομή για μεγάλο μέρος της παγκόσμιας οικονομίας, καθιστώντας την ασφάλεια του λογισμικού ανοιχτού κώδικα ζωτικής σημασίας για τον κόσμο».
Συνηθίζουμε να υπερηφανευόμαστε ότι ο ανοιχτός κώδικας χαρακτηρίζεται από υψηλά ποσοστά ασφάλειας και, μάλιστα, αναπαράγουμε τον περίφημο «νόμο του Linus» (σ.σ. ονομάστηκε έτσι προς τιμήν του Linus Torvalds αλλά η φράση αποδίδεται στον Eric S. Raymond) σε διάφορες εκφάνσεις για να το τονίσουμε: «με αρκετά μάτια, όλα τα σφάλματα είναι εντοπίσιμα».
Μήπως, όμως, επαναπαυόμαστε σε μια επίπλαστη πραγματικότητα και σε όσα κάνουν ή νομίζουμε ότι κάνουν κάποιοι άλλοι για εμάς, αμελώντας τη δική μας συνεισφορά και προσοχή; Και τι γίνεται αν τα μάτια που επιβλέπουν τον ανοιχτό κώδικα δεν είναι αρκετά;
Αν ο προαναφερθείς «νόμος» ίσχυε στο έπακρο, θα ήταν αδύνατο να προκύψουν περιπτώσεις όπως αυτή του «Heartbleed Bug». Ακόμα και η σκέψη ύπαρξης σοβαρού κενού ασφάλειας σε ένα τόσο κρίσιμο συστατικό για την παγκόσμια υποδομή, όπως είναι το OpenSSL, θα μας φαινόταν παράλογη. Εντούτοις, όχι μόνο υπήρξε ένα τέτοιο κενό αλλά παρέμεινε ανοιχτό για σημαντικό χρονικό διάστημα. Γιατί; Διότι, πολύ απλά, «κανένας» δεν κοιτούσε τον κώδικα.
Η ασφάλεια των δημοφιλών ανοιχτών οικοσυστημάτων
Επιστρέφοντας στην αναφορά του GitHub, θα εμβαθύνουμε στα στατιστικά και τις πληροφορίες που μας παρέχονται για ορισμένα δημοφιλή οικοσυστήματα πακέτων ανοιχτού κώδικα και τους αντίστοιχους διαχειριστές αυτών. Εικάζω ότι επέλεξαν να επικεντρωθούν στα συγκεκριμένα ακριβώς γιατί είναι δημοφιλή και χρησιμοποιούνται σε τεράστιο αριθμό έργων ανοιχτού κώδικα. Κρατήστε το αυτό το τελευταίο και θα καταλάβετε το γιατί στη συνέχεια του άρθρου.
Τα οικοσυστήματα πακέτων που εξετάστηκαν είναι τα εξής:
- Composer (PHP)
- Maven (Java)
- npm (JavaScript)
- NuGet (.NET)
- PyPi (Python)
- RubyGems (Ruby)
Είμαι βέβαιος ότι όσοι ασχολείστε με τον προγραμματισμό αναγνωρίσατε αμέσως τους διαχειριστές πακέτων και τις αντίστοιχες γλώσσες, ενώ οι υπόλοιποι κάπου θα έχετε δει να αναφέρονται· η δημοφιλία που λέγαμε.
Από την αναφορά του GitHub πληροφορούμαστε ότι τα ενεργά αποθετήρια αυτών των οικοσυστημάτων εμφανίζουν πιθανότητες 59% να λάβουν μια προειδοποίηση ασφάλειας μέσα στους επόμενους 12 μήνες. Πιο απλά, είναι πολύ πιθανό να εντοπιστεί σε αυτά τουλάχιστον μία ευπάθεια, και αυτό είναι δηλωτικό της συχνότητας με την οποία εμφανίζουν κενά ασφάλειας —όχι της αμεσότητας εντοπισμού αυτών.
Διόλου τυχαία, οι δύο γλώσσες προγραμματισμού που συγκεντρώνουν υπεραυξημένες πιθανότητες (JavaScript και Ruby, με 73% και 81%, αντίστοιχα) συμπεριλαμβάνονται στην πρώτη δεκάδα των γλωσσών που έχουν ζήτηση και χρησιμοποιούνται σε πλήθος υλοποιήσεων, ενώ η πρώτη παρουσιάζει ιδιαίτερα ανοδική τάση τα τελευταία χρόνια.
Συνεχίζοντας, μαθαίνουμε ότι οι ευπάθειες ασφάλειας συχνά περνούν απαρατήρητες για περισσότερα από τέσσερα χρόνια μέχρι να αποκαλυφθούν επίσημα. Υπενθυμίζω εδώ ότι πρόκειται για δημοφιλή συστατικά ανοιχτού κώδικα, με χιλιάδες χρήστες ανά τον κόσμο. Συνεπώς, είτε τα μάτια που αναλύουν τον κώδικα δε βλέπουν αρκετά καλά είτε δεν υπάρχουν καθόλου. Σε κάθε περίπτωση, αυτό κάτι σημαίνει για την ασφάλεια και για την εξάρτησή μας από κάποιους απροσδιόριστους «άλλους».
Όσον αφορά τον μέσο χρόνο αντίδρασης στην αποκατάσταση των ευπαθειών, και εδώ η κατάσταση δεν είναι ακριβώς ρόδινη. Από τη στιγμή που θα εντοπιστεί ένα κενό στην ασφάλεια του λογισμικού, απαιτούνται περισσότερες από τέσσερις εβδομάδες έως ότου προκύψει ο κώδικας της επιδιόρθωσης. Διάστημα έκθεσης σε δυνητικό κίνδυνο μεγαλύτερο του ενός μήνα, δηλαδή, για λογισμικό που μπορεί να τρέχει σε καθημερινή βάση και να αποτελεί θεμέλιο λίθο κάποιας υποδομής —μάλλον δεν εμπνέει και τόση ηρεμία, δε νομίζετε;
Σαν να μην έφτανε αυτό, ακόμα και με διαθέσιμο τον κώδικα που επιδιορθώνει κάποια ευπάθεια, χρειάζονται άλλες δέκα εβδομάδες μέχρι να ειδοποιηθούν χρήστες και προγραμματιστές για τη διαθεσιμότητά του, στις οποίες προστίθεται επιπλέον μία εβδομάδα ως να υλοποιήσουν τη σχετική ενημέρωση.
Συνολικά, απαιτούνται κάτα μέσο όρο περισσότεροι από 3,5 μήνες για την οριστική(;) αποκατάσταση μιας ευπάθειας. Θα υπενθυμίσω ξανά ότι πρόκειται όχι απλά για ανοιχτό κώδικα -με τα θεωρητικά «πολλά» μάτια να τον κοιτούν- αλλά και για δημοφιλή προγραμματιστικά οικοσυστήματα αυτού.
Ανοιχτός κώδικας σημαίνει ότι ο κώδικας είναι διαθέσιμος για αξιολόγηση ασφάλειας, όχι ότι έχει αξιολογηθεί απαραίτητα από κανέναν. Αυτή είναι μια σημαντική διάκριση.
Όλα τα παραπάνω ώθησαν τον γνωστό ειδικό στην ασφάλεια των υπολογιστών Bruce Schneier να τονίσει για ακόμα μια φορά αυτό που τείνουμε να λησμονούμε στην καθημερινότητα, πως ο ανοιχτός κώδικας δε συνεπάγεται την ασφάλεια.
Εξαρτήσεις στον κώδικα και η δουλειά των άλλων
Η ειρωνεία στην όλη υπόθεση είναι το γεγονός πως η πηγή των δεινών στον τομέα της ασφάλειας για τον ανοιχτό κώδικα είναι ταυτόχρονα και ένα από τα εξέχοντα χαρακτηριστικά του: η ίδια η ανοιχτότητα και το ότι είναι διαθέσιμος προς χρήση χωρίς ιδιαίτερους περιορισμούς. Αυτό επιτρέπει στους προγραμματιστές να μην επινοούν εκ νέου τον τροχό αλλά να ενσωματώνουν στα έργα τους τμήματα κώδικα που έχουν δημιουργηθεί από άλλους.
Έτσι, όμως, προκαλείται σχέση εξάρτησης με τις δημιουργίες των «άλλων» (σ.σ. δεν είναι τυχαία η λέξη «εξαρτήσεις» που επιλέχθηκε για τη διαδικασία του πακεταρίσματος) και εισάγονται επιπλέον πεδία δυνητικών κενών ασφάλειας, στα οποία δεν έχουμε κανέναν έλεγχο.
Ακόμα και αν υποθέσουμε ότι ο δημιουργός μιας εφαρμογής, λόγου χάρη, φροντίζει επισταμένως για την ασφάλεια του κώδικα που γράφει, δεν υπάρχει τίποτα που να βεβαιώνει ότι το ίδιο κάνουν και οι αντίστοιχοι προγραμματιστές των επιμέρους τμημάτων κώδικα που ενσωμάτωσε στην εφαρμογή του με τη μορφή των εξαρτήσεων.
Το GitHub περιγράφει αυτό το φαινόμενο στην αναφορά του, ενημερώνοντας πως περίπου το 80% του κώδικα στις περισσότερες σύγχρονες εφαρμογές προέρχεται από εξαρτήσεις. Νωρίτερα αναφέρθηκε πως οι γλώσσες JavaScript και Ruby εμφανίζουν στατιστικά τις μεγαλύτερες πιθανότητες να προκύψει σε αυτές ένα κενό ασφάλειας μέσα στον επόμενο έναν χρόνο. Εδώ βλέπουμε ότι τα έργα που δημιουργούνται με αυτές έχουν και αυξημένα ποσοστά εξάρτησης από άλλα έργα ανοιχτού κώδικα (94% και 90.2%).
Ειδικότερα στην περίπτωση της JavaScript, όπως δείχνουν και τα στατιστικά, οι προγραμματιστές συνηθίζουν να γράφουν λιγότερο κώδικα, τον οποίο βασίζουν σε άλλα δημιουργήματα. Δεν ξέρω αν αυτό θα έπρεπε να αποδοθεί στην αναζήτηση της «ευκολίας» ή σε μειωμένες ικανότητες. Όμως, αυτή η τόσο στενή αλληλεξάρτηση είναι χαρακτηριστικό της γλώσσας και της χρήσης του npm. Μάλιστα, δεν είναι καν η πρώτη φορά που προκαλεί σοβαρό πρόβλημα. Θυμάστε τότε που «έσπασε το Internet» για μόλις 11 γραμμές κώδικα;
Ψευδής εφησυχασμός ως απόρροια της χαμηλής κρισιμότητας
Ένα ακόμα στοιχείο που καταγράφεται στην αναφορά, αυτήν τη φορά εστιάζοντας στον (υπερ)δημοφιλή npm της JavaScript, είναι πως τα περισσότερο χρησιμοποιούμενα πακέτα του εμφάνισαν ευπάθειες χαμηλής ή μέτριας κρισιμότητας. Θα ήταν, όμως, λάθος να σκεφτούμε πως η κρισιμότητα είναι αντιστρόφως ανάλογη της δημοφιλίας και ότι τα «γνωστά» πακέτα κώδικα επιθεωρούνται τακτικά.
Είναι εξίσου εύκολο για μια ευπάθεια κρίσιμης σοβαρότητας να περάσει από την αναθεώρηση κώδικα όπως και για μια χαμηλής σοβαρότητας.
Αυτό έρχεται να επιβεβαιώσει η περίπτωση του Composer (PHP), που είχε σοβαρές ευπάθειες σχετικές με την ασφάλεια σε πακέτα που χρησιμοποιούνται από μεγάλο αριθμό έργων. Ενδεχομένως, κάποιοι θα βιαστούν να αναπαραγάγουν τις γνωστές απόψεις για το επίπεδο ασφάλειας της συγκεκριμένης γλώσσας προγραμματισμού. Οι οποίες, όμως, είναι κενές νοήματος.
Το ίδιο το GitHub φροντίζει να επισημάνει ότι σοβαρή υποψηφιότητα για το πιο επιδραστικό σφάλμα (ασφάλειας, πάντα) του 2020 έχει το CVE-2020-8203 που αφορά τη βιβλιοθήκη lodash της JavaScript, η οποία διανέμεται μέσω του npm. Ανατρέξτε μόλις δύο παραγράφους παραπάνω για να καταλάβετε γιατί η δημοφιλία του κώδικα δεν επιφέρει αυτόματα και αυξημένη προσοχή στον έλεγχο της ασφάλειάς του.
Συνδυάζοντας, λοιπόν, αυτά τα στοιχεία, επακολουθεί το συμπέρασμα πως όσο περισσότερο εξαρτάται ένα έργο ανοιχτού κώδικα από άλλα, τόσο αυξάνονται οι πιθανότητες να εμφανίσει προβληματικά σημεία στην ασφάλειά του. Με μια διαφορετική ερμηνεία, τα επιβλέποντα μάτια που φροντίζουν για την ανάλυση των επιμέρους τμημάτων κώδικα δε φαίνεται να υπάρχουν, παρά μόνο στη θεωρία.
Επιπρόσθετα, ο σχετικά μικρός αριθμός σφαλμάτων υψηλής κρισιμότητας δε σημαίνει απολύτως τίποτα. Όπως αποδεικνύεται, υπάρχουν πολλά και μεγάλα κομμάτια ανοιχτού κώδικα που δεν επιθεωρούνται συχνά ή και καθόλου, ώστε να γνωρίζουμε με βεβαιότητα ότι δεν υφίστανται άλλα σοβαρά κενά. Επιπλέον, αρκεί μόνο μία σημαντική ευπάθεια -που θα μεταδοθεί μέσω των εξαρτήσεων- για να κάνει ζημιά.
Οπότε, θα ήταν φρόνιμο να πάψουμε να ισχυριζόμαστε ότι ο ανοιχτός κώδικας είναι ασφαλής απλά επειδή μπορεί οποιοσδήποτε να τον αναλύσει, εφόσον οι αριθμοί δείχνουν ότι αυτό δεν αποτελεί γενικευμένη πρακτική.
Ας φροντίσουμε για την πραγματική ασφάλεια του ανοιχτού κώδικα
Ελπίζω αυτό το άρθρο να δώσει μια διαφορετική οπτική στη γενικότερη θεώρηση για την ασφάλεια του ανοιχτού κώδικα. Νομίζω, είναι εμφανές πως η βασικότερη υπόθεση που κάνουμε περί αυτού -πως, δηλαδή, υπάρχουν κάποιοι «άλλοι» που επιθεωρούν τον κώδικα- σε πολλές περιπτώσεις αποδεικνύεται αβάσιμη.
Η ασφάλεια του λογισμικού είναι δουλειά όλων.
Το ίδιο ισχύει και για τους χρόνους αντίδρασης και την αμεσότητα στην αποκατάσταση των ευπαθειών. Τα τέσσερα και πλέον χρόνια κατά τα οποία μπορεί ένα κενό στην ασφάλεια του λογισμικού να περάσει απαρατήρητο, καθώς και οι 3,5 μήνες που απαιτούνται έπειτα, διαψεύδουν κατηγορηματικά τις διαδεδομένες πεποιθήσεις.
Υπάρχουν πολλά σημεία, από τις πρακτικές παραγωγής του κώδικα -με τον υπερβολικό βαθμό αλληλεξάρτησης- και την αναθεώρηση αυτού μέχρι τους τρόπους διάθεσης των επιδιορθώσεων και ενημέρωσης των χρηστών, που χρήζουν άμεσης βελτίωσης.
Δεν πρέπει να επαναπαυόμαστε αλλά, αντίθετα, χρειάζεται να φροντίζουμε όλοι μας ενεργά για την ασφάλεια του λογισμικού που χρησιμοποιούμε. Τίποτα δεν είναι ασφαλές εξ ορισμού και η υπεροχή των έργων ανοιχτού κώδικα στον τομέα της ασφάλειας είναι, μάλλον, περισσότερο θεωρητική.
Διαβάστε την αναφορά του Github εδώ
Πηγή άρθρου: https://osarena.net