Μια σοβαρή αλυσίδα εκμετάλλευσης που αποκαλύφθηκε στο GitLab συνδυάζει δύο παλιά σφάλματα ασφάλειας στην βιβλιοθήκη Oj (ένας αναλυτής JSON για Ruby) με αποτέλεσμα την απομακρυσμένη εκτέλεση κώδικα. Ο κίνδυνος είναι πραγματικός για εγκαταστάσεις GitLab που διαχειρίζονται οι ίδιες· ακόμα και ένας απλός χρήστης με δικαίωμα push σε ένα έργο θα μπορούσε να πολιορκήσει ολόκληρο το σύστημα.
- Δύο παρασιωπημένα σφάλματα στη βιβλιοθήκη Oj JSON κρύβονταν για σχεδόν πέντε χρόνια και μπορούν να συνδυαστούν για απεριόριστη εκτέλεση κώδικα στο GitLab.
- Οποιοσδήποτε χρήστης με δικαίωμα push και δυνατότητα προβολής διαφορών commits μπορεί να ενεργοποιήσει την αλυσίδα, χωρίς να χρειάζονται δικαιώματα διαχειριστή ή πρόσβαση στο CI/CD.
- Οι αυτοδιαχειριζόμενες εγκαταστάσεις που τρέχουν GitLab 15.2.0 ή μεταγενέστερη πρέπει να αναβαθμιστούν άμεσα στις σταθερές εκδόσεις (18.10.8, 18.11.5, 19.0.2 ή νεότερη).
Πώς συγχωνεύονται τα δύο σφάλματα σε επίθεση
Τα δύο ίδια σφάλματα στην Oj είναι μεμονωμένα αθώα. Το πρώτο επιτρέπει να γραφεί ένα ενιαίο byte σε λάθος θέση της στοίβας. Το δεύτερο δεν κάνει τίποτα περισσότερο από το να διαρρεύσει 29 bytes μνήμης. Εντελώς ανώδυνα, φαινομενικά.
Όμως μαζί, με προσεκτική διαχείριση του τρόπου με τον οποίο ο διακομιστής κατανέμει τη μνήμη, ο επιτιθέμενος αποκτά πρόσβαση σε έναν δείκτη επανάκλησης (callback pointer) — ουσιαστικά μια διεύθυνση που λέει στον υπολογιστή να εκτελέσει κώδικα όπου πεις εσύ. Και τότε χρησιμοποιεί το δεύτερο σφάλμα για να “δει” πού βρίσκεται η βασική βιβλιοθήκη libc στη μνήμη, καταργώντας έτσι τις άμυνες ASLR (Address Space Layout Randomization — το τρικ ασφάλειας που κάνει τις διευθύνσεις τυχαίες κάθε φορά).
Το αποτέλεσμα: ο επιτιθέμενος έχει πλήρη ελεγχο της εκτέλεσης κώδικα ως χρήστης “git”, που είναι αυτός που τρέχει τον Puma web server του GitLab.
Το αρχικό σημείο έπειτα: η ανάλυση των Jupyter Notebooks
Το GitLab έχει μια χρήσιμη δυνατότητα: μπορεί να δείξει διαφορές (diffs) σε αρχεία Jupyter Notebook σε ανθρώπινη μορφή. Για να το κάνει, χρησιμοποιεί ένα gem (εφαρμογή Ruby) που ονομάζεται ipynbdiff, το οποίο παίρνει κάθε αναθεώρηση σημειωματάριου και την αναλύει χρησιμοποιώντας την Oj για να βεβαιωθεί ότι είναι έγκυρο JSON.
Εδώ είναι το πρόβλημα: ένας χρήστης με δικαίωμα push — δηλαδή, κάποιος που μπορεί να στείλει κώδικα στο αποθετήριο — μπορεί να εισάγει ένα κακόβουλα δημιουργημένο αρχείο σημειωματάριου. Όταν κάποιος δει τη διαφορά του commit, ενεργοποιείται η αλυσίδα εκμετάλλευσης.
Δεν χρειάζονται ειδικές άδειες. Δεν χρειάζεται ο διαχειριστής να κάνει τίποτα. Δεν χρειάζεται CI/CD pipeline. Ο επιτιθέμενος δεν χρειάζεται καν να αλληλεπιδράσει με το θύμα — απλώς ανεβάζει το αρχείο και περιμένει κάποιον να πατήσει “view diff”.
Ποιες εκδόσεις είναι επικίνδυνες
Αν τρέχεις αυτοδιαχειριζόμενο GitLab, είσαι επικίνδυνος αν χρησιμοποιείς:
- GitLab 15.2.0 έως 18.10.7 → αναβάθμιση σε 18.10.8 ή νεότερη
- GitLab 18.11.0 έως 18.11.4 → αναβάθμιση σε 18.11.5
- GitLab 19.0.0 ή 19.0.1 → αναβάθμιση σε 19.0.2
Το GitLab.com (η cloud υπηρεσία που χρησιμοποιούν πολλοί) ήταν ήδη επιδιορθωμένο όταν αποκαλύφθηκε η επίθεση, οπότε δεν χρειάζεται να κάνεις τίποτα αν χρησιμοποιείς το δημόσιο GitLab.
Ο ευάλωτος κώδικας της Oj συγχωνεύτηκε στον Αύγουστο του 2021 — πριν περισσότερο από τέσσερα χρόνια. Παρέμεινε σιωπηλός για 1.753 ημέρες πριν αποκαλυφθεί. Το GitLab ξεκίνησε να χρησιμοποιεί την επικίνδυνη κλήση ανάλυσης τον Ιούλιο του 2022.
Τι χρειάζεται να κάνεις τώρα
Αν διαχειρίζεσαι εγκατάσταση GitLab που είναι προσβάσιμη από το δίκτυό σας ή από το διαδίκτυο:
- Έλεγχος έκδοσης — Πήγαινε στο Admin → System Information (ή /admin) και δες την τρέχουσα έκδοσή σου.
- Άμεση αναβάθμιση — Αν είσαι σε κάποια από τις εύρεση που αναφέρθηκαν παραπάνω, αναβάθμισε αμέσως. Αυτό δεν είναι προσθήκη νέας δυνατότητας — είναι κρίσιμη διορθωμένη.
- Έλεγχος αναβάθμισης — Μετά την αναβάθμιση, επιβεβαίωσε ότι το ipynbdiff gem ενημερώθηκε τουλάχιστον στο 3.17.3.
Αν τρέχεις ένα shared ή multi-tenant GitLab (περισσότερες από μία ομάδες, περισσότεροι από έναν πελάτης), η προτεραιότητα είναι ακόμα υψηλότερη — ένας εχθρικός χρήστης θα μπορούσε να προσβάλει άλλους ενοικιαστές.
Γιατί η βάση της επίθεσης είναι τόσο αποτελεσματική
Η αλυσίδα αυτή δείχνει κάτι που μας ανησυχεί στο TechNoid: όταν χρησιμοποιείς μια βιβλιοθήκη C/C++ από Ruby (ή Python, ή oποιαδήποτε ασφαλής-για-μνήμη γλώσσα), ένα ενιαίο σφάλμα μνήμης στο σύστημα C μπορεί να κομπρομιτάρει ολόκληρη τη στοίβα εφαρμογής. Η ασφάλεια μνήμης του Ruby δεν σημαίνει τίποτα αν καλείς έναν ανασφαλές C addon που κρύβει σφάλματα για χρόνια.
Προηγούμενες επιθέσεις RCE στο GitLab έχαν να κάνουν με SSRF (Server-Side Request Forgery) — δηλαδή, ζητούσαν από τον διακομιστή να επισκεφθεί εσωτερικές υπηρεσίες Redis. Αυτή η επίθεση παρακάμπτει όλες εκείνες τις άμυνες επειδή είναι απολύτως τοπική, μεσα στο ίδιο νήμα του web server.
Τέλος, σημείωση για τις ομάδες που διαχειρίζονται Ruby repositories: ο ερευνητής ανακάλυψε εννέα επιπλέον CVE στην Oj πέρα από τα δύο που χρησιμοποιούνται εδώ — buffer overflows, integer overflows, unsafe memcpy. Αυτό υπογραμμίζει πόσο βαθιά μπορούν να κρύβονται τα προβλήματα σε εγγενείς επεκτάσεις. Θα πρέπει να ελέγξεις τα Ruby gemfiles σας για όλες τις εγγενείς επεκτάσεις C και να δοκιμάσεις εάν υπάρχουν νεότερες εκδόσεις.
Συχνές Ερωτήσεις για την Ασφάλεια του GitLab και τη Βιβλιοθήκη Oj
Χρησιμοποιώ GitLab.com (το δημόσιο cloud). Είμαι επικίνδυνος;
Όχι. Το GitLab.com ήταν ήδη επιδιορθωμένο όταν αποκαλύφθηκε η επίθεση. Αν χρησιμοποιείς το δημόσιο GitLab (gitlab.com), δεν χρειάζεται να κάνεις τίποτα.
Είναι πραγματικά τόσο εύκολη η ενεργοποίηση; Χρειάζεται ο επιτιθέμενος admin rights;
Όχι, δεν χρειάζονται admin rights. Χρειάζεται μόνο δικαίωμα push σε ένα έργο και δυνατότητα να δει κάποιος τη διαφορά του commit. Για κοινόχρηστες ή multi-tenant εγκαταστάσεις, αυτό κάνει την επίθεση ιδιαίτερα επικίνδυνη.
Τι χρειάζεται να κάνει ένας χρήστης για να ενεργοποιήσει την αλυσίδα;
Δύο πράγματα: (1) να ανεβάσει δύο ειδικά δημιουργημένα αρχεία Jupyter Notebook σε ένα commit, και (2) να δει ή να προκαλέσει κάποιον άλλον να δει τη διαφορά. Δεν χρειάζεται CI/CD pipeline, δεν χρειάζεται script, δεν χρειάζεται κάτι άλλο.
Πόσο καιρό ήταν τα σφάλματα κρυμμένα;
Τα δύο κύρια σφάλματα στην Oj κρύβονταν για 1.753 ημέρες — περισσότερο από 4,8 χρόνια. Το πρώτο ήταν σιωπηλό ακόμα και μετά την αποκάλυψη, επειδή δεν είχε καν CVE για αυτό έως ότου δημοσιοποιήθηκε η αλυσίδα.
Αν αναβαθμίσω μόνο το GitLab, αρκεί;
Κατά κανόνα ναι, αλλά ελέγχθηκε ότι το gem ipynbdiff αναβαθμίστηκε επίσης σε τουλάχιστον 3.17.3. Εάν για κάποιο λόγο χρησιμοποιείς παλιότερη έκδοση του ipynbdiff, θα πρέπει να την αναβαθμίσεις χειροκίνητα.
Υπάρχει δημόσιο exploit code;
Όχι δημόσιο PoC (Proof of Concept) που μπορεί να τρέξει κάποιος αμέσως. Ωστόσο, ο ερευνητής δημοσίευσε λεπτομέρειες και video επίδειξης, που σημαίνει ότι είναι τεχνικά εφικτό να δημιουργηθεί. Επομένως, η αναβάθμιση δεν πρέπει να καθυστερήσει.
Τι άλλο θα μπορούσε να έχει προσβάσει ο επιτιθέμενος;
Εκτελώντας κώδικα ως χρήστη “git”, θα μπορούσε να: (1) διαβάσει τον πηγαίο κώδικα οποιουδήποτε repository που τρέχει το GitLab, (2) κλέψει μυστικά Rails και διαπιστευτήρια, (3) αποκτήσει πρόσβαση σε εσωτερικές υπηρεσίες που είναι προσβάσιμες από τον κεντρικό υπολογιστή, (4) μετατρέψει τον κώδικα, (5) επεκταθεί σε άλλα συστήματα (lateral movement).
Γιατί αυτό δεν ήταν ευδιάκριτο για πολύ καιρό;
Επειδή κάθε σφάλμα μεμονωμένα ήταν “άσχετο” — το πρώτο γράφει μόνο ένα byte, το δεύτερο δεν κάνει παρά να διαρρεύσει 29 bytes. Κανένας δεν περίμενε ότι θα μπορούσαν να συνδυαστούν. Αυτό υπενθυμίζει ότι μικρά σφάλματα μνήμης συχνά παραβλέπονται — αλλά όταν έρχεται ένας έξυπνος επιτιθέμενος, μπορούν να γίνουν μοιραία.
