Σύμφωνα με ερευνητές οι επεξεργαστές της Intel κάνουν πιο σοβαρή την μόλυνση από malware

[nnn]

Ερευνητές από το πανεπιστήμιο της Καλιφόρνια, ανέπτυξαν μια μέθοδο παράκαμψης μιας από τις βασικές γραμμές προστασίας έναντι σε malware που υπάρχει σε σχεδόν κάθε λειτουργικό. Το address space layout randomization ASLR, προστατεύει ενάντια σε επιθέσεις από κακόβουλο λογισμικό, κάνοντας τις τοποθεσίες μνήμης που αποθηκεύονται κομμάτια κώδικα -τυχαίες- μειώνοντας τι συνέπειες μιας επιτυχούς μόλυνσης.

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

ASLR is an important defense deployed by all commercial Operating Systems. It is often the only line of defense that prevents an attacker from exploiting any of a wide range of attacks (those that rely on knowing the memory layout of the victim).

A weakness in the hardware that allows ASLR to be bypassed can open the door to many attacks that are stopped by ASLR. It also highlights the need for CPU designers to be aware of security as part of the design of new processors.

Εκπρόσωπος της Intel δήλωσε πως η εταιρία μελετά την εργασία των ερευνητών.

Πηγή : Arstechnica


συνημμένη η μελέτη των 3 ερευνητών

[turboirc]

Το aslr είναι software based feature και είναι πιθανό να έπεσαν σε μια περίπτωση κακής υλοποίησης...αν όντως βρήκαν πρόβλημα τότε ενδέχεται να είναι πολύ σοβαρότερο και βαθύτερο.

[zardoz]

Εγώ "τόλμησα" να διαβάσω το paper τους, και ουσιαστικά βασίζονται σε μια μεγάλη (ΤΕΡΑΣΤΙΑ)
τρύπα στο Branch Prediction Hardware της CPU. Δεν έχει να κάνει δυστυχώς με OS software.

• Οι kernel ρουτίνες, τοποθετούναι μια χαρά τυχαία στη μνήμη, για να μη μπορεί κανείς να προβλέψει που βρίσκονται και να γίνει code injection... όμως ...
• H CPU για το Branch Prediction, κρατά σε ένα πίνακα BTB χρήσιμες διευθύνσεις κώδικα που προέκυψαν από branches κατά την εκτέλεση
• Τρέχοντας μια απλή χωρίς διαχειριστικά δικαιώματα εφαρμογή, δημιουργούν "τεχνητά" branch collisions στο Branch Target Buffer (BTB) της CPU
  μια και εισάγουν branch διευθύνσεις σε αυτή (με τυχαία branch) μια και γνωρίζουν ότι ΜΟΝΟ ένα τμήμα της διεύθυνσης χρειάζεται να είναι ίδιο για
  να δημιουργήσει branch collision
• Μια άλλη απλή χωρίς διαχειριστικά δικαιώματα εφαρμογή, χρονομετρεί κλήσεις του λειτουργικού, βρίσκοντας στατιστικά ποιες καθυστέρησαν ξαφνικά
  λόγω του branch collision. Κάθε φορά που χρονομετρείται καθυστέρηση, υπάρχει επιτυχία...
• Το αποτέλεσμα είναι να βρούν που βρίσκεται ο κώδικας συγκεκριμένων processes, και μετά όλα είναι αρχαία ιστορία

Από την άλλη, μόνο κάποιοι επεξεργαστές λειτουργουν με αυτή τη Branch Prediction τεχνική, οπότε το exploit αφορά αποκλειστικά αυτούς.

[turboirc]

Εγώ "τόλμησα" να διαβάσω το paper τους, και ουσιαστικά βασίζονται σε μια μεγάλη (ΤΕΡΑΣΤΙΑ)
τρύπα στο Branch Prediction Hardware της CPU. Δεν έχει να κάνει δυστυχώς με OS software.

• Οι kernel ρουτίνες, τοποθετούναι μια χαρά τυχαία στη μνήμη, για να μη μπορεί κανείς να προβλέψει που βρίσκονται και να γίνει code injection... όμως ...
• H CPU για το Branch Prediction, κρατά σε ένα πίνακα BTB χρήσιμες διευθύνσεις κώδικα που προέκυψαν από branches κατά την εκτέλεση
• Τρέχοντας μια απλή χωρίς διαχειριστικά δικαιώματα εφαρμογή, δημιουργούν "τεχνητά" branch collisions στο Branch Target Buffer (BTB) της CPU
  μια και εισάγουν branch διευθύνσεις σε αυτή (με τυχαία branch) μια και γνωρίζουν ότι ΜΟΝΟ ένα τμήμα της διεύθυνσης χρειάζεται να είναι ίδιο για
  να δημιουργήσει branch collision
• Μια άλλη απλή χωρίς διαχειριστικά δικαιώματα εφαρμογή, χρονομετρεί κλήσεις του λειτουργικού, βρίσκοντας στατιστικά ποιες καθυστέρησαν ξαφνικά
  λόγω του branch collision. Κάθε φορά που χρονομετρείται καθυστέρηση, υπάρχει επιτυχία...
• Το αποτέλεσμα είναι να βρούν που βρίσκεται ο κώδικας συγκεκριμένων processes, και μετά όλα είναι αρχαία ιστορία

Από την άλλη, μόνο κάποιοι επεξεργαστές λειτουργουν με αυτή τη Branch Prediction τεχνική, οπότε το exploit αφορά αποκλειστικά αυτούς.

Άρα καλά μύρισα ότι είναι σοβαρό, αλλά ποιοι επεξεργαστές έχουν το πρόβλημα;

[DVader]

Εγώ "τόλμησα" να διαβάσω το paper τους, και ουσιαστικά βασίζονται σε μια μεγάλη (ΤΕΡΑΣΤΙΑ)
τρύπα στο Branch Prediction Hardware της CPU. Δεν έχει να κάνει δυστυχώς με OS software.

• Οι kernel ρουτίνες, τοποθετούναι μια χαρά τυχαία στη μνήμη, για να μη μπορεί κανείς να προβλέψει που βρίσκονται και να γίνει code injection... όμως ...
• H CPU για το Branch Prediction, κρατά σε ένα πίνακα BTB χρήσιμες διευθύνσεις κώδικα που προέκυψαν από branches κατά την εκτέλεση
• Τρέχοντας μια απλή χωρίς διαχειριστικά δικαιώματα εφαρμογή, δημιουργούν "τεχνητά" branch collisions στο Branch Target Buffer (BTB) της CPU
  μια και εισάγουν branch διευθύνσεις σε αυτή (με τυχαία branch) μια και γνωρίζουν ότι ΜΟΝΟ ένα τμήμα της διεύθυνσης χρειάζεται να είναι ίδιο για
  να δημιουργήσει branch collision
• Μια άλλη απλή χωρίς διαχειριστικά δικαιώματα εφαρμογή, χρονομετρεί κλήσεις του λειτουργικού, βρίσκοντας στατιστικά ποιες καθυστέρησαν ξαφνικά
  λόγω του branch collision. Κάθε φορά που χρονομετρείται καθυστέρηση, υπάρχει επιτυχία...
• Το αποτέλεσμα είναι να βρούν που βρίσκεται ο κώδικας συγκεκριμένων processes, και μετά όλα είναι αρχαία ιστορία

Από την άλλη, μόνο κάποιοι επεξεργαστές λειτουργουν με αυτή τη Branch Prediction τεχνική, οπότε το exploit αφορά αποκλειστικά αυτούς.

ΟΚ ! Δεκτά αυτά που λές..Ετσι είναι για το διάβασα και εγώ... Η απορία μου όμως είναι η εξής...Για να τρέξει το όποιο exploit πρέπει να έχεις πρόσβαση στο μηχάνημα .... με κάποιο τρόπο ...ώστε να τρέξεις το exploit ! Έστω και remote ... execution ...

Γενικά δεν είναι τόσο εύκολο να συμβεί αυτό !

[zardoz]

ΟΚ ! Δεκτά αυτά που λές..Ετσι είναι για το διάβασα και εγώ... Η απορία μου όμως είναι η εξής...Για να τρέξει το όποιο exploit πρέπει να έχεις πρόσβαση στο μηχάνημα .... με κάποιο τρόπο ...ώστε να τρέξεις το exploit ! Έστω και remote ... execution ...

Γενικά δεν είναι τόσο εύκολο να συμβεί αυτό !

Eχεις δίκιο, πρεπει να τρέξεις κώδικα έστω και δίχως διαχειριστικά δικαιώματα,
να ξέρεις ΑΚΡΙΒΩΣ ποιά έκδοση kernel τρέχει και να είσαι "έτοιμος" για exploit σε αυτή.

Το ζήτημα είναι όμως ότι, με ένα καλο-οργανωμένο πρόγραμμα, δοκιμασμένο σε αρκετές
εκδόσεις του kernel, μπορείς να κάνεις priviledge elevation, με λίγα λόγια να τρέξεις κώδικα
root/admin ενώ δεν είσαι.

Ακόμα χειρότερα (λένε μέσα) και τα data segments του kernel βρίσκονται σχετικά κοντά
οπότε μπορείς να τσιμπίσεις διάφορα security tokens και να τα στείλεις προς κίνα μεριά.

[turboirc]

Eχεις δίκιο, πρεπει να τρέξεις κώδικα έστω και δίχως διαχειριστικά δικαιώματα,
να ξέρεις ΑΚΡΙΒΩΣ ποιά έκδοση kernel τρέχει και να είσαι "έτοιμος" για exploit σε αυτή.

Το ζήτημα είναι όμως ότι, με ένα καλο-οργανωμένο πρόγραμμα, δοκιμασμένο σε αρκετές
εκδόσεις του kernel, μπορείς να κάνεις priviledge elevation, με λίγα λόγια να τρέξεις κώδικα
root/admin ενώ δεν είσαι.

Ακόμα χειρότερα (λένε μέσα) και τα data segments του kernel βρίσκονται σχετικά κοντά
οπότε μπορείς να τσιμπίσεις διάφορα security tokens και να τα στείλεις προς κίνα μεριά.

Πως προκυπτει το γεγονος οτι ξεροντας την διευθυνση του χ process μπορεις να κανεις escalation.
Δεν αρκει μονο αυτο. Θες και buffer overrun.

[keysmith]

^ το οποίο buffer overrun (or buffer overflow) είναι ακριβώς αυτό που κάνει το exploit που θα σε κάνει escalate.
Παλαιότερα που δεν είχαμε ASLR έτσι δούλευαν τα exploits που έκαναν ότι έκανα (πχ escalation ή ξέρω γω add έναν user κτλ). Αυτά τα κόλπα σταματήσαν να δουλεύουν ή περιορίστηκαν χάριν του ASLR. Αυτό διότι ακόμα και να ήταν γνωστή η αδυναμία (vulnerability) στο κώδικα κάποια ρουτίνας πχ του λειτουργικού δεν μπορούσες να φτιάξεις expoit αν για να πετύχει το buffer overflow έπρεπε να ξέρεις καλά την στήβα τι είναι που (και χάριν του ASLR δεν ξέρεις). Τώρα με την παράκαμψη του "γνωρίζεις" κάτι (πχ μία ρουτίνα) που ακριβώς είναι στη μνήμη (αν κατάλαβα καλά) όλα αυτά τα παλιά κόλπα των exploits με buffer overflows ξανα-αρχίζουν να ξανα-δουλεύουν..

[turboirc]

^ το οποίο buffer overrun (or buffer overflow) είναι ακριβώς αυτό που κάνει το exploit που θα σε κάνει escalate.
Παλαιότερα που δεν είχαμε ASLR έτσι δούλευαν τα exploits που έκαναν ότι έκανα (πχ escalation ή ξέρω γω add έναν user κτλ). Αυτά τα κόλπα σταματήσαν να δουλεύουν ή περιορίστηκαν χάριν του ASLR. Αυτό διότι ακόμα και να ήταν γνωστή η αδυναμία (vulnerability) στο κώδικα κάποια ρουτίνας πχ του λειτουργικού δεν μπορούσες να φτιάξεις expoit αν για να πετύχει το buffer overflow έπρεπε να ξέρεις καλά την στήβα τι είναι που (και χάριν του ASLR δεν ξέρεις). Τώρα με την παράκαμψη του "γνωρίζεις" κάτι (πχ μία ρουτίνα) που ακριβώς είναι στη μνήμη (αν κατάλαβα καλά) όλα αυτά τα παλιά κόλπα των exploits με buffer overflows ξανα-αρχίζουν να ξανα-δουλεύουν..

Σε επιπεδο λειτουργικου δεν εχει νοημα πλεον. Ακομα και να βρεις vulnerability ειναι σχεδον σιγουρο οτι θα φτιαχτει γρηγορα.

Το προβλημα ειναι να βρεις το overrun και αυτο ειναι ολοενα και πιο δυσκολο με το πολυ καλυτερο επιπεδο προγραμματισμου που εχουμε σημερα.

[keysmith]

το ότι το λειτουργικό θα "φτιαχτεί" σύντομα δεν προκύπτει. Υπάρχουν vulnerabilities που όταν τα ανακαλύπτει η κοινότητα αυτά υπήρχαν για χρόνια. Όλα αυτά τα χρόνια μπορεί κάποιοι να τα γνώριζαν (οι μυστικές υπηρεσίες και αρκετοί hackers δεν δουλεύουν με "γνωστά" vulnerabilities) και να τα χρησιμοποιούσαν. Έχουν ανακαλυφθεί πολλές τέτοιες περιπτώσεις κατόπιν εορτής. Πολλά vulnerabilities που μπορεί να ήταν γνωστά σε υπηρεσίες και "κακούς" crackers δεν ήταν δυνατόν να τα αξιοποιήσουν λόγο ASLR αλλά τώρα ίσως θα μπορούν.

[zardoz]

το ότι το λειτουργικό θα "φτιαχτεί" σύντομα δεν προκύπτει. Υπάρχουν vulnerabilities που όταν τα ανακαλύπτει η κοινότητα αυτά υπήρχαν για χρόνια.

Ακριβώς αλλά τα πράγματα εδώ είναι ακόμα χειρότερα...

Το άρθρο ουσιαστικά δείχνει ότι δεν χρειάζεται ΚΑΝ να ψάξεις για vulnerabilities. Από τη στιγμή που καταφέρνεις έστω και με αυτό τον "δύσκολο" τρόπο να ξεπεράσεις το ASLR, θα βρείς τρόπο να τρέξεις ή να πάρεις κομμάτια από πολύ καλογραμμένο και χωρίς vulnerabilities κώδικα, που απλά πρίν δεν ήξερες που ήταν. Δεν χρειάζεται να εκμεταλευτείς buffer overrun κλπ ούτε το DEP βοηθά γιατί οι κακοί χρησιμοποιούν ROPs από κώδικα και μάλιστα άλλων εφαρμογών, εδώ και καιρό και όχι από data.

Η τρύπα που πρέπει να κλείσει αυτή τη στιγμή είναι η τρύπα του Branch Collision Table, γιατί μπορεί αυτή τη στιγμή κάπου στην Κίνα κάποια κρατική υπηρεσία ίσως έχει ήδη έτοιμο το πακέτο

Έτσι κι αλλιώς Intel/AMD εδώ και καιρό κάνουν silent cpu microcode updates, μάλλον πρέπει να το δουν και αυτό.

[turboirc]

το ότι το λειτουργικό θα "φτιαχτεί" σύντομα δεν προκύπτει. Υπάρχουν vulnerabilities που όταν τα ανακαλύπτει η κοινότητα αυτά υπήρχαν για χρόνια. Όλα αυτά τα χρόνια μπορεί κάποιοι να τα γνώριζαν (οι μυστικές υπηρεσίες και αρκετοί hackers δεν δουλεύουν με "γνωστά" vulnerabilities) και να τα χρησιμοποιούσαν. Έχουν ανακαλυφθεί πολλές τέτοιες περιπτώσεις κατόπιν εορτής. Πολλά vulnerabilities που μπορεί να ήταν γνωστά σε υπηρεσίες και "κακούς" crackers δεν ήταν δυνατόν να τα αξιοποιήσουν λόγο ASLR αλλά τώρα ίσως θα μπορούν.

Εννοουσα οταν ανακοινωθει.

[Helene]

πακέτο