Μπορεί να έχετε ακούσει για το τελευταίο ελάττωμα στην ασφάλεια των JDK 1.1 και HotJava 1.0 που ανακαλύφθηκε πρόσφατα από την ομάδα Secure Internet Programming στο Πανεπιστήμιο του Princeton (με επικεφαλής έναν από τους συγγραφείς). Αν θέλετε ολόκληρη την ιστορία, διαβάστε. Αλλά υπάρχουν περισσότερα για την ασφάλεια της Java από τις λεπτομέρειες σχετικά με αυτήν την τελευταία τρύπα ασφαλείας. Ας πάρουμε κάποια προοπτική.
Ασφάλεια Java και αντίληψη του κοινού
Όλοι γνωρίζουν ότι η ασφάλεια είναι μεγάλη υπόθεση για την Java. Κάθε φορά που ανακαλύπτεται μια τρύπα ασφαλείας, η ιστορία εκτοξεύεται στις ειδήσεις του υπολογιστή (και μερικές φορές στις επιχειρηματικές ειδήσεις) πολύ γρήγορα. Μπορεί να μην εκπλαγείτε να μάθετε ότι ο δημοφιλής τύπος παρακολουθεί comp.risks και άλλες ομάδες συζήτησης που σχετίζονται με την ασφάλεια. Διαλέγουν ιστορίες ασφαλείας για να τονίζουν φαινομενικά τυχαία, αν και δεδομένου ότι η Java είναι τόσο ζεστή αυτές τις μέρες σχεδόν πάντα εκτυπώνει ιστορίες ασφαλείας Java.
Το πρόβλημα είναι ότι οι περισσότερες ειδήσεις δεν εξηγούν καθόλου τις τρύπες. Αυτό θα μπορούσε να οδηγήσει σε ένα κλασικό πρόβλημα "λύκος κλαίματος" όπου οι άνθρωποι συνηθίζουν να βλέπουν "την ιστορία ασφαλείας αυτής της εβδομάδας" και δεν εκπαιδεύονται για τους πολύ πραγματικούς κινδύνους του εκτελέσιμου περιεχομένου. Επιπλέον, οι πωλητές τείνουν να υποτιμούν τα προβλήματα ασφαλείας τους, προκαλώντας περαιτέρω σύγχυση στα βασικά ζητήματα.
Τα καλά νέα είναι ότι η ομάδα ασφαλείας JavaSoft είναι σοβαρή για να κάνει την Java ασφαλή. Τα κακά νέα είναι ότι η πλειοψηφία των προγραμματιστών και των χρηστών της Java μπορεί να πιστεύει ότι η διαφημιστική εκστρατεία προέρχεται από γεγονότα όπως το JavaOne όπου τα προβλήματα ασφαλείας δεν έχουν πολλά airplay. Όπως είπαμε στο βιβλίο μας, Ασφάλεια Java: Εχθρικές εφαρμογές, τρύπες και αντίδοτα, Η Sun Microsystems έχει πολλά να κερδίσει αν σας κάνει να πιστεύετε ότι η Java είναι απόλυτα ασφαλής. Είναι αλήθεια ότι οι προμηθευτές έχουν καταβάλει μεγάλες προσπάθειες για να κάνουν τις εφαρμογές Java όσο το δυνατόν πιο ασφαλείς, αλλά οι προγραμματιστές δεν θέλουν προσπάθεια. θέλουν αποτελέσματα.
Δεδομένου ότι ένα πρόγραμμα περιήγησης Ιστού με δυνατότητα Java επιτρέπει την ενσωμάτωση κώδικα Java σε μια ιστοσελίδα, τη λήψη σε ολόκληρο το δίκτυο και την εκτέλεση σε τοπικό μηχάνημα, η ασφάλεια αποτελεί κρίσιμο πρόβλημα. Οι χρήστες μπορούν να κατεβάσουν Java applets με εξαιρετική ευκολία - μερικές φορές χωρίς να το γνωρίζουν. Αυτό εκθέτει τους χρήστες Java σε σημαντικό κίνδυνο.
Οι σχεδιαστές της Java γνωρίζουν πολύ καλά τους πολλούς κινδύνους που σχετίζονται με το εκτελέσιμο περιεχόμενο. Για την καταπολέμηση αυτών των κινδύνων, σχεδίασαν την Java ειδικά με γνώμονα τα ζητήματα ασφαλείας. Ο κύριος στόχος ήταν να αντιμετωπιστεί το ζήτημα της ασφάλειας κατά τρόπον ώστε οι αφελείς χρήστες (ας πούμε, η πλειοψηφία των εκατομμυρίων surfers Ιστού) να μην χρειάζεται να γίνουν εμπειρογνώμονες ασφαλείας για να μελετήσουν με ασφάλεια τον Ιστό. Αυτός είναι ένας αξιοθαύμαστος στόχος.
Τα τρία μέρη του Java sandbox
Η Java είναι μια πολύ ισχυρή γλώσσα ανάπτυξης. Τα μη αξιόπιστα μικροεφαρμογές δεν πρέπει να έχουν πρόσβαση σε όλες αυτές τις δυνατότητες. Το Java sandbox περιορίζει τις μικροεφαρμογές από την εκτέλεση πολλών δραστηριοτήτων. Το καλύτερο τεχνικό έγγραφο σχετικά με τους περιορισμούς applet είναι το "Ασφάλεια χαμηλού επιπέδου στην Java" του Frank Yellin.
Η ασφάλεια Java βασίζεται σε τρία άκρα άμυνας: το Byte Code Verifier, το Class Loader και το Security Manager. Μαζί, αυτά τα τρία άκρα εκτελούν ελέγχους φόρτωσης και χρόνου εκτέλεσης για να περιορίσουν την πρόσβαση στο σύστημα αρχείων και στο δίκτυο, καθώς και την πρόσβαση σε εσωτερικά του προγράμματος περιήγησης. Κάθε ένα από αυτά τα άκρα εξαρτάται κατά κάποιο τρόπο από τους άλλους. Για να λειτουργεί σωστά το μοντέλο ασφαλείας, κάθε μέρος πρέπει να κάνει τη δουλειά του σωστά.
Ο επαληθευτής κώδικα byte:
Το Byte Code Verifier είναι το πρώτο άκρο του μοντέλου ασφαλείας Java. Όταν ένα πρόγραμμα προέλευσης Java καταρτίζεται, μεταγλωττίζεται σε κώδικα Java byte ανεξάρτητο από πλατφόρμα. Ο κώδικας byte Java "επαληθεύεται" προτού εκτελεστεί. Αυτό το σχήμα επαλήθευσης έχει σκοπό να διασφαλίσει ότι ο κώδικας byte, ο οποίος μπορεί ή όχι να έχει δημιουργηθεί από έναν μεταγλωττιστή Java, παίζει με τους κανόνες. Σε τελική ανάλυση, ο κώδικας byte θα μπορούσε κάλλιστα να έχει δημιουργηθεί από έναν "εχθρικό μεταγλωττιστή" που συναρμολόγησε τον κώδικα byte που είχε σχεδιαστεί για να συντρίψει την εικονική μηχανή Java. Η επαλήθευση του κωδικού byte ενός applet είναι ένας τρόπος με τον οποίο η Java ελέγχει αυτόματα τον μη αξιόπιστο εξωτερικό κώδικα πριν επιτραπεί η εκτέλεση. Ο Επαληθευτής ελέγχει τον κωδικό byte σε διάφορα επίπεδα. Η απλούστερη δοκιμή διασφαλίζει ότι η μορφή ενός θραύσματος byte-code είναι σωστή. Σε λιγότερο βασικό επίπεδο, εφαρμόζεται ένας ενσωματωμένος θεώρημα prover σε κάθε τμήμα κώδικα. Ο παροιμία θεωρήματος βοηθά να βεβαιωθείτε ότι ο κώδικας byte δεν σφυρηλατεί δείκτες, παραβιάζει τους περιορισμούς πρόσβασης ή αποκτά πρόσβαση σε αντικείμενα χρησιμοποιώντας λανθασμένες πληροφορίες τύπου. Η διαδικασία επαλήθευσης, σε συνδυασμό με τα χαρακτηριστικά ασφαλείας που είναι ενσωματωμένα στη γλώσσα μέσω του μεταγλωττιστή, βοηθά στη δημιουργία ενός βασικού συνόλου εγγυήσεων ασφαλείας.
Ο φορτωτής κλάσης applet:
Το δεύτερο άκρο της άμυνας ασφαλείας είναι το Java Applet Class Loader. Όλα τα αντικείμενα Java ανήκουν σε τάξεις. Το Applet Class Loader καθορίζει πότε και πώς μια μικροεφαρμογή μπορεί να προσθέσει κλάσεις σε περιβάλλον Java που εκτελείται. Μέρος της δουλειάς της είναι να διασφαλίσει ότι σημαντικά μέρη του περιβάλλοντος χρόνου εκτέλεσης Java δεν αντικαθίστανται από κώδικα που προσπαθεί να εγκαταστήσει μια μικροεφαρμογή. Σε γενικές γραμμές, ένα τρέχον περιβάλλον Java μπορεί να έχει πολλούς Class Loaders ενεργούς, ο καθένας ορίζει το δικό του "space name". Τα κενά ονομάτων επιτρέπουν στις κλάσεις Java να διαχωρίζονται σε ξεχωριστά "είδη" ανάλογα με το πού προέρχονται. Το Applet Class Loader, το οποίο παρέχεται συνήθως από τον προμηθευτή του προγράμματος περιήγησης, φορτώνει όλες τις μικροεφαρμογές και τις τάξεις στις οποίες αναφέρονται. Όταν μια μικροεφαρμογή φορτώνει σε ολόκληρο το δίκτυο, ο Φορτωτής κλάσης Applet λαμβάνει τα δυαδικά δεδομένα και τα εγκαθιστά ως νέα κλάση.
Ο διαχειριστής ασφαλείας:
Το τρίτο άκρο του μοντέλου ασφαλείας Java είναι το Java Security Manager. Αυτό το μέρος του μοντέλου ασφαλείας περιορίζει τους τρόπους με τους οποίους μια μικροεφαρμογή μπορεί να χρησιμοποιεί ορατές διεπαφές. Έτσι, ο Διαχειριστής ασφαλείας εφαρμόζει ένα καλό μέρος ολόκληρου του μοντέλου ασφαλείας. Το Security Manager είναι μια μεμονωμένη μονάδα που μπορεί να εκτελεί ελέγχους χρόνου εκτέλεσης σε "επικίνδυνες" μεθόδους. Ο κώδικας στη βιβλιοθήκη Java συμβουλεύεται τον Διαχειριστή ασφαλείας κάθε φορά που πρόκειται να επιχειρήσει μια επικίνδυνη λειτουργία. Ο Διαχειριστής Ασφαλείας έχει την ευκαιρία να ασκήσει βέτο στη λειτουργία δημιουργώντας μια Εξαίρεση Ασφαλείας (το όφελος των προγραμματιστών Java παντού). Οι αποφάσεις που λαμβάνονται από τον Διαχειριστή ασφαλείας λαμβάνουν υπόψη ποιος Φορτωτής Κλάσης φόρτωσε την κλάση που ζητά. Τα ενσωματωμένα μαθήματα έχουν περισσότερο προνόμιο από τα μαθήματα που έχουν φορτωθεί στο διαδίκτυο.
Αξιόπιστο και εξολοθρευμένο στο sandbox
Μαζί, τα τρία μέρη του μοντέλου ασφαλείας Java αποτελούν το sandbox. Η ιδέα είναι να περιορίσετε τι μπορεί να κάνει μια μικροεφαρμογή και να βεβαιωθείτε ότι παίζει σύμφωνα με τους κανόνες. Η ιδέα του sandbox είναι ελκυστική επειδή έχει σκοπό να σας επιτρέψει να τρέξετε αναξιόπιστος κωδικοποιήστε στο μηχάνημά σας χωρίς να ανησυχείτε για αυτό. Με αυτόν τον τρόπο μπορείτε να περιηγηθείτε στον Ιστό με ατιμωρησία, εκτελώντας κάθε μικροεφαρμογή Java που συναντάτε ποτέ χωρίς προβλήματα ασφαλείας. Λοιπόν, όσο το Java sandbox δεν έχει τρύπες ασφαλείας.
Μια εναλλακτική λύση στο sandbox:
Έλεγχος ταυτότητας μέσω υπογραφής κώδικα
Το ActiveX είναι μια άλλη μορφή εκτελέσιμου περιεχομένου υψηλού προφίλ. Προωθούμενη από τη Microsoft, το ActiveX έχει επικριθεί από επαγγελματίες ασφάλειας υπολογιστών που θεωρούν ότι η προσέγγισή της στην ασφάλεια είναι ελλιπής. Σε αντίθεση με την κατάσταση ασφαλείας της Java, όπου ένα applet περιορίζεται από τον έλεγχο του λογισμικού στα διάφορα πράγματα που μπορεί να κάνει, ένα στοιχείο ελέγχου ActiveX δεν έχει περιορισμούς στη συμπεριφορά του όταν καλείται. Το αποτέλεσμα είναι ότι οι χρήστες του ActiveX πρέπει να είναι πολύ προσεκτικοί για να τρέχουν μόνο απόλυτα αξιόπιστος κωδικός. Οι χρήστες Java, από την άλλη πλευρά, έχουν την πολυτέλεια να εκτελούν αξιόπιστο κώδικα με ασφάλεια.
Η προσέγγιση ActiveX βασίζεται σε ψηφιακές υπογραφές, ένα είδος τεχνολογίας κρυπτογράφησης στην οποία τα αυθαίρετα δυαδικά αρχεία μπορούν να "υπογραφούν" από έναν προγραμματιστή ή διανομέα. Επειδή μια ψηφιακή υπογραφή έχει ειδικές μαθηματικές ιδιότητες, είναι αμετάκλητη και ανεφάρμοστη. Αυτό σημαίνει ότι ένα πρόγραμμα όπως το πρόγραμμα περιήγησής σας μπορεί να επαληθεύσει μια υπογραφή, επιτρέποντάς σας να είστε σίγουροι ποιος εγγυάται τον κωδικό. (Τουλάχιστον, αυτή είναι η θεωρία. Τα πράγματα είναι λίγο πιο διφορούμενα στην πραγματική ζωή.) Ακόμα καλύτερα, μπορείτε να δώσετε εντολή στο πρόγραμμα περιήγησής σας να δέχεται πάντα κωδικό υπογεγραμμένο από κάποιο μέρος που εμπιστεύεστε ή πάντα να απορρίπτετε κωδικό υπογεγραμμένο από κάποιο μέρος που εσείς μην εμπιστεύεσαι.
Μια ψηφιακή υπογραφή περιέχει πολλές πληροφορίες. Για παράδειγμα, μπορεί να σας πει ότι παρόλο που κάποιος κώδικας αναδιανέμεται από έναν ιστότοπο που δεν εμπιστεύεστε, αρχικά γράφτηκε από κάποιον που εμπιστεύεστε. Ή μπορεί να σας πει ότι παρόλο που ο κώδικας γράφτηκε και διανεμήθηκε από κάποιον που δεν γνωρίζετε, ο φίλος σας έχει υπογράψει τον κωδικό, βεβαιώνοντας ότι είναι ασφαλής. Ή μπορεί απλά να σας πει σε ποια από τις χιλιάδες χρήστες aol.com έγραψε τον κωδικό.
(Δείτε την πλαϊνή γραμμή για περισσότερες λεπτομέρειες σχετικά με τις ψηφιακές υπογραφές, συμπεριλαμβανομένων πέντε βασικών ιδιοτήτων.)
Το μέλλον του εκτελέσιμου περιεχομένου: Αποχώρηση από το περιβάλλον δοκιμών
Οι ψηφιακές υπογραφές καθιστούν το ActiveX πιο ελκυστικό από άποψη ασφάλειας από το Java; Δεν πιστεύουμε, ειδικά λαμβάνοντας υπόψη ότι η δυνατότητα ψηφιακής υπογραφής είναι πλέον διαθέσιμη στο JDK 1.1.1 της Java (μαζί με άλλες βελτιώσεις ασφαλείας). Αυτό σημαίνει ότι στην Java, έχετε όλα όσα κάνει το ActiveX για ασφάλεια συν τη δυνατότητα εκτέλεσης μη αξιόπιστου κώδικα με ασφάλεια. Η ασφάλεια της Java θα βελτιωθεί ακόμη περισσότερο στο μέλλον με ευέλικτο, λεπτομερή έλεγχο πρόσβασης, το οποίο, σύμφωνα με τον Li Gong, αρχιτέκτονα ασφαλείας της JavaSoft, προγραμματίζεται να κυκλοφορήσει στο JDK 1.2. Ο καλύτερος έλεγχος πρόσβασης θα περάσει επίσης στον επόμενο γύρο προγραμμάτων περιήγησης, συμπεριλαμβανομένων των Netscape Communicator και MicroSoft Internet Explorer 4.0.
Σε συνδυασμό με τον έλεγχο πρόσβασης, η υπογραφή κώδικα θα επιτρέψει στα μικροεφαρμογές να βγουν σταδιακά έξω από το κιβώτιο ασφαλείας. Για παράδειγμα, μια μικροεφαρμογή που έχει σχεδιαστεί για χρήση σε μια ρύθμιση Intranet θα μπορούσε να επιτρέπεται να διαβάζει και να γράφει σε ένα ιδιαιτερος βάση δεδομένων της εταιρείας αρκεί να υπογραφεί από τον διαχειριστή του συστήματος. Μια τέτοια χαλάρωση του μοντέλου ασφαλείας είναι σημαντική για προγραμματιστές που χτυπούν λίγο για να κάνουν τα applet τους περισσότερα. Η συγγραφή κώδικα που λειτουργεί εντός των αυστηρών περιορισμών του sandbox είναι πόνος. Το αρχικό sandbox είναι πολύ περιοριστικό.
Τελικά, οι μικροεφαρμογές θα έχουν διαφορετικά επίπεδα εμπιστοσύνης. Δεδομένου ότι αυτό απαιτεί έλεγχο πρόσβασης, οι αποχρώσεις εμπιστοσύνης δεν είναι προς το παρόν διαθέσιμες, παρόλο που η υπογραφή κώδικα είναι. Όπως ισχύει σήμερα στο JDK 1.1.1, οι μικροεφαρμογές Java είναι είτε εντελώς αξιόπιστες είτε εντελώς αξιόπιστες. Μια υπογεγραμμένη μικροεφαρμογή που έχει επισημανθεί ως αξιόπιστη επιτρέπεται να ξεφύγει εντελώς από το sandbox. Μια τέτοια μικροεφαρμογή μπορεί να κάνει οτιδήποτε και έχει χωρίς περιορισμούς ασφαλείας.
Το κύριο πρόβλημα με την προσέγγιση της Java στην ασφάλεια είναι ότι είναι περίπλοκο. Τα περίπλοκα συστήματα τείνουν να έχουν περισσότερα ελαττώματα από τα απλά συστήματα. Οι ερευνητές ασφαλείας, κυρίως η ομάδα ασφαλών διαδικτυακών προγραμμάτων του Princeton, έχουν βρει πολλά σοβαρά ελαττώματα ασφαλείας στις πρώτες εκδόσεις του sandbox. Πολλά από αυτά τα ελαττώματα ήταν σφάλματα εφαρμογής, αλλά μερικά ήταν σφάλματα προδιαγραφών. Ευτυχώς, τα JavaSoft, Netscape και Microsoft ήταν πολύ γρήγορα να επιδιορθώσουν τέτοια προβλήματα όταν ανακαλυφθούν. (Σαφείς και πλήρεις εξηγήσεις για τις τρύπες ασφαλείας της Java βρίσκονται στο Κεφάλαιο 3 του βιβλίου μας.)
Μόλις πρόσφατα, οι έμποροι της Sun (μερικές φορές ονομάζονται ευαγγελιστές) έδειξαν γρήγορα ότι δεν είχαν ανακαλυφθεί νέα ελαττώματα εδώ και αρκετό καιρό. Το έκαναν αυτό ως απόδειξη ότι η Java δεν θα υποφέρει ποτέ ξανά από προβλήματα ασφάλειας. Πηδούσαν το όπλο.
Η τρύπα υπογραφής κώδικα: Η Java ξεφλουδίζει το γόνατο
Η υπογραφή κώδικα είναι περίπλοκη. Όπως και στο αρχικό μοντέλο sandbox, υπάρχει αρκετός χώρος για λάθη στο σχεδιασμό και την εφαρμογή ενός συστήματος υπογραφής κώδικα. Η πρόσφατη τρύπα ήταν ένα αρκετά απλό πρόβλημα στην εφαρμογή των Java Τάξη τάξη, όπως εξηγείται τόσο στον ιστότοπο Princeton όσο και στον ιστότοπο ασφαλείας του JavaSoft. Συγκεκριμένα, η μέθοδος Class.getsigners () επιστρέφει έναν μεταβλητό πίνακα όλων των υπογραφών που είναι γνωστοί στο σύστημα. Είναι πιθανό για μια μικροεφαρμογή να κάνει κακή χρήση αυτών των πληροφοριών. Η επιδιόρθωση ήταν τόσο απλή όσο η επιστροφή μόνο ενός αντιγράφου του πίνακα και όχι του ίδιου του πίνακα.
Εξετάστε μια κατάσταση στην οποία ένας προγραμματιστής, η Αλίκη, δεν έχει λάβει προνόμιο ασφαλείας στο σύστημα ενός χρήστη στο Web. Στην πραγματικότητα, σε αντίθεση με αυτό που ισχυρίστηκε η αρχική δήλωση JavaSoft σχετικά με το σφάλμα, μπορεί να είναι η Αλίκη εντελώς άγνωστο στο σύστημα. Με άλλα λόγια, ο κωδικός που υπογράφεται από την Αλίκη δεν εμπιστεύεται πλέον το συνηθισμένο applet εκτός δρόμου. Εάν ο χρήστης του Ιστού (χρησιμοποιώντας το πρόγραμμα περιήγησης HotJava - επί του παρόντος το μόνο εμπορικό προϊόν που υποστηρίζει JDK 1.1.1) φορτώνει μια μικροεφαρμογή που υπογράφεται από την Αλίκη, αυτή η μικροεφαρμογή μπορεί ακόμα να βγει από το περιβάλλον δοκιμών εκμεταλλευόμενη την τρύπα.
Το γεγονός ότι το σύστημα δεν χρειάζεται να έχει το δημόσιο κλειδί της Alice στη βάση δεδομένων του είναι σημαντικό. Αυτό σημαίνει ότι η Αλίκη μπορεί να είναι οποιοσδήποτε αυθαίρετος εισβολέας που ξέρει πώς να υπογράψει μια μικροεφαρμογή με εντελώς τυχαία ταυτότητα. Η δημιουργία μιας τέτοιας ταυτότητας είναι εύκολη, όπως είναι η υπογραφή μιας μικροεφαρμογής με αυτήν την ταυτότητα. Αυτό καθιστά την τρύπα πολύ σοβαρή.
Η τρύπα επιτρέπει στην εφαρμογή της επίθεσης της Άλις να αλλάξει την ιδέα του συστήματος για το ποιος την υπέγραψε. Αυτό είναι ιδιαίτερα κακό αν δεν δοθεί στην Alice το προνόμιο να τρέξει έξω από το sandbox, αλλά ο Bob είναι. Το applet της Alice μπορεί να χρησιμοποιήσει το υποκριτές () καλέστε για να αλλάξετε το επίπεδο άδειας για να συμπεριλάβετε όλα τα προνόμια του Bob. Η μικροεφαρμογή της Alice μπορεί να αποκτήσει το μέγιστο διαθέσιμο διαθέσιμο προνόμιο κάθε υπογράφων γνωστό στο σύστημα.
Εάν παρομοιάζετε τις ταυτότητες υπογραφής / προνομίων με τα παλτά σε ένα ντουλάπι, η επίθεση της Αλίκης μπορεί να δοκιμάσει κάθε παλτό και να επιχειρήσει διάφορα απαγορευμένα πράγματα μέχρι να ανακαλύψει ποια από τα παλτά είναι «μαγικά» και να της επιτρέψει να αποκτήσει προνόμια. Εάν ανακαλυφθεί ένα μαγικό παλτό, η μικροεφαρμογή της Αλίκης μπορεί να βγει από το κουτί άμμου και να κάνει πράγματα που δεν πρέπει να επιτρέπεται να κάνει. Η δοκιμή παλτών είναι τόσο απλή όσο η προσπάθεια μιας απαγορευμένης κλήσης και η παρακολούθηση για να δείτε τι συμβαίνει.
