Βρέθηκε τεράστια τρύπα ασφαλείας σε Debian Linux διανομές

[astrofos]

Huge Hole in Open Source Software Found, Leaves Millions Vulnerable

 

Debian, the Linux variant used largely by security professionals, and Ubuntu, the variant most commonly used by home users are both affected. Furthermore, Windows servers may be compromised as well if they are using keys generated on Linux systems.

 

Ironically the bug originated from an automated tool known as Valgrind which is supposed to reduce programming bugs which lead to security vulnerabilities. It found that a block memory was not being properly initialized, meaning that it would contain random information. The automated tool politely inserted code to clean up the block of memory making it all zeros. The only problem was that the system was intentionally using the block's unknown to get randomness to generate the keys. The library also gets randomness from mouse movements, keystroke timings, network packet arrival timings, and even microvariations in hard drive speed.

 

The Valgrind code caused errors, so the programmers simply commented out all the code, including the other methods of generating randomness on accident. Only the code which utilized the process ID, an integer ranging from 0 to 32,767, remained to provide randomness. It turns out the "fix" turned grievous error was not the work of the OpenSSL programmers themselves, but of the Debian team, known for their security expertise.

 

OpenSSL developer Ben Laurie raged, "Never fix a bug you don't understand! Had Debian [sent the bug to us] in this case, we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was. But no, it seems that every vendor wants to 'add value' by getting in between the user of the software and its author."

 

Σε ένα προηγούμενο thread είχα αμφισβητίσει αυτό το μοντέλο που ακολουθείται από τις διανομές Linux.

 

 

 

Φίλε apoikos αυτό είναι για σένα

Τελικά διαφωνώ και στο άλλο, οτι ο X maintainer της διανομής Y έχει καλύτερη γνώση του κώδικά ΜΟΥ και μπορεί να κάνει μετατροπές σε αυτόν ωστε να δουλεύει καλύτερα από ΕΜΕΝΑ. Ο κώδικας είναι πολύ δυσκολότερο να διαβάστεί και να κατανοηθεί από το να γραφτεί. Χειροπιαστά παραδείγματα έχω προσωπικα πετύχει ουκ ολίγες φορές και στο internet και προσωπικά.

 

Απάντηση: Κατ' αρχάς το πόσο καλά θα δουλεύει ο κώδικάς σου σε ένα σύστημα δεν εξαρτάται μόνο από τον ίδιο τον κώδικα, αλλά και από το build system. Επιπλέον, τον κώδικά σου τον έχεις αναπτύξει στο σύστημά σου, με συγκεκριμένες εκδόσεις βιβλιοθηκών και συγκεκριμένο API. Το θέμα είναι ότι ο maintainer μιας σοβαρής διανομής συνήθως *ξέρει* καλύτερα από το μέσο προγραμματιστή τι χρειάζεται ένα πρόγραμμα για να παίξει σωστά. Είναι η δουλειά του να ξέρει απ' έξω τα χαρακτηριστικά της πλατφόρμας πολύ καλύτερα από έναν προγραμματιστή. Γι' αυτό και βλέπεις projects όπως το debian ή το gentoo και στέλνουν αβέρτα patches «upstream», στους αρχικούς συγγραφείς δηλαδή.

 

Πίστεψέ με πάντως, στα (κοντά διφήφια) χρόνια ενασχόλησης με το GNU/Linux, έχω δει άπειρες φορές ακόμα και σοβαρά projects να έχουν σημαντικά λάθη στο build system τους. Φυσικά στα συστήματα των developers έκαναν build, αλλά όχι στο δικό μου ή στου δίπλα, χωρίς να φταίει το δικό μου setup. Ναι, οι άνθρωποι είναι πολύ καλοί προγραμματιστές, αλλά δεν είναι η δουλειά τους να ξέρουν κάθε φορά τι θα γίνει αν αλλάξει μια από τις εκατοντάδες παραμέτρους σε ένα σύστημα.

Μια ερώτηση μόνο. Οταν θα έχω την ευθύνη να μια σημαντική εγκατάσταση της MySQL, πιον θα εμπιστευθώ περισσότερο, τον εαυτό μου να κάνει compile από το source, τον X maintainer της Y διανομής, ή την certified pre-compiled από την ίδια την MySQL;

 

Απάντηση: προσωπικά εμπιστεύομαι τους maintainers του debian. Χρόνια τώρα δεν έχω συναντήσει ποτέ πρόβλημα και τρέχω αρκετά mission-critical συστήματα.

 

[antonl]

Αναστάτωση στην κοινότητα ανοιχτού λογισμικού

[chek2fire]

Ηδη την έχουν διορθώσει εδώ και κάτι μέρες

[Cntrl+X]

astrofos,

Ο apoikos είπε πως δεν έχει συναντήσει ποτέ πρόβλημα ασφαλείας σε Debian.

Είναι διαφορετικό πράγμα ένα δομικό πρόβλημα (π.χ. κακός κώδικας) και άλλο πράγμα λειτουργικό πρόβλημα (πρακτικά προβλήματα συνεπεία των κενών ασφαλείας).

Όσον αφορά το πρώτο δε νομίζω πως ισχυρίζεται κανείς σοβαρά ότι το GNU/Linux δε χρήζει τακτικών ενημερώσεων/βελτιώσεων σε έναν κώδικα που συνεχώς εξελίσσεται και που προφανώς υπάρχουν κενά ασφαλείας, μικρά ή μεγάλα.

Για το δεύτερο όμως, την άποψη του apoikos συνυπογράφουν οι χρήστες GNU/Linux που έχουν πρακτικά ξεχάσει τι θα πει viruses/spyware/malware, services του ίδιου του λειτουργικού συστήματος για τα οποία καμία βεβαιότητα δεν υπάρχει ότι σέβονται τα προσωπικά δεδομένα του χρήστη. Το "μαύρο κουτί" του κώδικα των windows δυστυχώς δεν αποκαλύπτει πάντα τα μυστικά του μετά από ατύχημα κι αυτό παρά μόνο σε ελάχιστους "εκλεκτούς". Στο Debian τουλάχιστον γνωστοποιήθηκε εγκαίρως. Εκτός κι αν παραπονέθηκε κάποιος ότι "έχασε τα κλειδιά του" και δεν το πήρα χαμπάρι.

[apoikos]

astrofos:

 

Η πηγή που παραθέτεις είναι από τις χειρότερες περιγραφές του γεγονότος που έχω διαβάσει. Για αρχή, συνέβησαν τα εξής:

 

1. Ο debian developer έτρεξε το valgrind για να δει αν υπάρχουν memory leaks στο openssh. Ο valgrind παραπονέθηκε ότι η OpenSSL χρησιμοποιεί μη-αρχικοποιημένη μνήμη, πράγμα το οποίο είναι εκτός προδιαγραφών της C και μπορούσε να οδηγήσει μέχρι και τον compiler να γράψει λάθος κώδικα.
   
2. O developer εντόπισε ως εστία του προβλήματος μια γραμμή κώδικα και (νόμιζε) μια δεύτερη ακριβώς ίδια.
   
3. Έστειλε e-mail στην openssl-dev, τη λίστα που επίσημα είναι για ερωτήσεις ανάπτυξης της openssl, ρωτώντας συγκεκριμένα αν βγάζοντας τις δύο αυτές γραμμές θα είχε πρόβλημα ο random number generator.
   
4. 3 developers της openssl του λένε "no problem", οπότε τις κάνει comment out και ο valgrind σταματάει να παραπονιέται
   
5. Τελικά αποκαλύπτεται (δεν ξέρουμε πως) ότι μόνο η μια γραμμή έφταιγε, και η άλλη πρακτικά έβαζε όλη την εντροπία στη δεξαμενή εντροπίας του συστήματος.
   

Εδώ το πρόβλημα είναι πολλαπλό: ο developer φταίει σε ένα βαθμό γιατί πάτσαρε κάτι που δεν καταλάβαινε πλήρως. Όμως ρώτησε, και η απάντηση που πήρε από τους ίδιους τους developers ήταν θετική. Προσωπικά έκατσα και διάβασα τον κώδικα όταν βγήκε το κενό (πριν 2 βδομάδες δηλαδή) και μπορώ να πω ότι ο κώδικας της OpenSSL ήταν απαράδεκτος σε εκείνο το σημείο, μη παρέχοντας κανένα σχόλιο για το τι κάνει. Επιπλέον, ο Ben Laurie βγήκε στο blog του και άρχισε να βρίζει αριστερά-δεξιά και να επικαλείται μια mailing-list (openssl-team) η οποία δεν υπάρχει πουθενά στη σελίδα της OpenSSL. Αντ' αυτής στη σελίδα της openssl πάντα έλεγε να χρησιμοποιείται η openssl-dev για επικοινωνία με τους developers.

 

Συμπέρασμα: για μένα φταίνε και οι δύο, και ίσως σε μεγαλύτερο βαθμό η OpenSSL και η οργάνωσή της. Το ιστορικό ασφαλείας του debian είναι πολύ καλό και εξακολουθώ να πιστεύω στην ορθότητα του μοντέλου που ακολουθεί, χωρίς αυτό να σημαίνει ότι δεν υπάρχουν ποτέ περιθώρια για σφάλματα. Για να μην ξεχνιόμαστε δε, αντίστοιχα σφάλματα έχουν κάνει και οι ίδιοι οι openssl developers στο παρελθόν, οδηγώντας σε αδύναμη κρυπτογράφηση.

 

Τέλος, σου το είχα πει και στο προηγούμενο thread: αν δε σου αρέσει αυτό το μοντέλο, κανείς δε σε αναγκάζει να το ενστερνιστείς και να το χρησιμοποιήσεις.

[DIMITRISG]

Τελικά αυτη η ειδηση ενδιαφερει τους λατρεις του κλειστού κώδικα, της microsoft, και των μισητων του linux, περισσότερο κι' απο τους χρηστες linux.

[astrofos]

@apoikos

 

Καλά τώρα η μια πλευρά μπορεί να ρίχνει την ευθύνη στην άλλη με αποτέλεσμα να μη βγαίνει άκρη και να χάνεται το ζουμί IMHO.

 

Το θέμα είναι οτι ανάμεσα στον δημιουργό και τον χρήστη μπήκε ένας τρίτος, έβαλε το χεράκι του και τα έκανε μαντάρα. Μπορεί αυτός ο τρίτος να είναι ο καλύτερος προγραμματιστής, δεν το αμφισβητώ. Το θέμα είναι οτι δεν μπορεί να έχει καλύτερη αντίληψη για την υλοποίση ενος προγράμματος από αυτόν που την έγραψε αρχικά. Αυτό συμβαίνει γιατί αντικειμενικά δεν έχει έρθει αντιμέτοπος με όλα τα προβλήματα που συνάντησε ο δημιουργός σε όλη την διάρκεια της ανάπτυξης του προγράμματος. Ένα (φαινομενικά) λάθος στα μάτια του τρίτου μπορεί να έχει συγκεκριμένο λόγο ύπαρξης από τον δημιουργό - όπως ακριβώς και έγινε.

 

Τέλος, σου το είχα πει και στο προηγούμενο thread: αν δε σου αρέσει αυτό το μοντέλο, κανείς δε σε αναγκάζει να το ενστερνιστείς και να το χρησιμοποιήσεις.

Νομίζω οτι είναι προφανές οτι δεν το ενστερνίζομαι Οσα εργαλεία χρησιμοποιώ και βασίζεται η δουλεία μου σε αυτά τα κατεβάζω πάντα από την πηγή προέλευσης.

[apoikos]

Δεν πετάω κανένα μπαλάκι πουθενά. Είναι προφανές ότι υπάρχει ένα πρόβλημα, αλλιώς δε θα ήμασταν εδώ να το συζητάμε. Στο παρελθόν οι διανομείς έχουν βρει και διορθώσει κρισιμότατα bugs στο software, πράγμα που δε θα είχε γίνει αν το software από το δημιουργό πήγαινε στον τελικό χρήστη. Το θέμα είναι πάντα πως συνεργάζεται ο διανομέας με το δημιουργό και εκεί πρόεκυψε το τρέχον ζήτημα, αφού η συνεννόηση με την OpenSSL δε δούλεψε σωστά.

 

Κατά δεύτερον, υπάρχει μια αρχή στον κόσμο του ανοιχτού λογισμικού που λέει ότι ο κώδικας πρέπει να είναι αυτο-τεκμηριωμένος, ώστε να μπορεί κάποιος να τον διαβάσει και να τον τροποποιήσει εύκολα σε περίπτωση που πατήσει τον δημιουργό το τρένο ας πούμε. Στην προκειμένη περίπτωση ένα σχόλιο μισής γραμμής του στυλ:

 

>
/* Add entropy to the PRNG pool - very important */

 

θα είχε αποκλείσει το ενδεχόμενο να γίνει αυτό που έγινε.

 

Τέλος οι παραλληλισμοί με τα αυτοκίνητα είναι μάλλον άστοχοι. Το software έχει πολύ ευρύτερο πεδίο χρήσης από ένα αυτοκίνητο, η χρήση του οποίου κατά 99,9% γίνεται σε περιβάλλον με γνωστές συνθήκες και για συγκεκριμένους λόγους. Όταν όμως θες να πας π.χ. στο βόρειο πόλο, θα πάρεις το αυτοκίνητο και θα το μετασκευάσεις ειδικά για να κάνει αυτό που θες, γιατί οι παραδοχές που έχει χρησιμοποιήσει ο κατασκευαστής δε σε καλύπτουν.

[gtroza]

ειδικά αν είναι mini !

.

[astrofos]

Δεν πετάω κανένα μπαλάκι πουθενά.

Δεν εννούσα εμάς αλλά τους εμπλεκόμενους στο bug μεταξύ OpenSSL <-> Debian

 

Τέλος οι παραλληλισμοί με τα αυτοκίνητα είναι μάλλον άστοχοι.

Συμφωνώ οτι δεν ήταν καλός ο παραλληλισμός γιαυτό και το έσβησα από το post.