>>86569
Ειδα το strace.
BCC, θέλω να ξεκαθαρίσω κάποια πράγματα σχετικα με το qubes/xen. Είμαι αρκετα έμπειρος με θεματα ασφαλειας, οπότε ελπίζω να με ακούσετε, αν ενδιαφερεστε για την ασφαλεια σας....
Ξέρω ότι πολλοί απο σας το χρησημοποιουν, καποιοι(?) ομως εχουν φτασει σε σημείο να μην ενδιαφέρονται καθολου για ασφαλεια και γινανε πρεζακια... για το threat model που τo θελετε, ουσιαστικα, ειναι ανασφαλές. Θα εξηγήσω γιατί. Δεν είναι τοσο δύσκολο να αποδρασεις από ένα app VM. Το πρόβλημα δεν είναι στο concept. Το concept του purpose-oriented isolation της δραστηριότητας του χρηστη ειναι καλό. Το πρόβλημα ειναι στo implementation. Υπάρχουν αρκετα issues με το Qubes, αλλά το μεγαλύτερο πρόβλημα ειναι στο Xen....
oταν το qubes δημιουργηθηκε σαν concept, το xen είχε τη φήμη πως είναι ακλόνητο. Τα τελευταία δύο χρόνια, αυτη η φήμη έχει καταρρεύσει, ειδικά μεταξύ ερευνητών ασφάλειας, και αυτων που ξερουν απο ασφάλεια σε γενικές γραμμές (και δεν εννοώ "ξέρω λίγα πράγματα για διανομές ασφαλείας", αλλά "εν μέρει τουλάχιστον, ειμαι εξοικειωμένος με τις εσωτερικές λειτουργίες του πυρήνα του Linux, το μοντελο ELF, μοντέλα ελέγχου πρόσβασης κλπ), είναι γνωστό πως εχει αρκετα προβληματα. Ενώ έχει το potential να βελτιωθει, στην κατασταση που ειναι τωρα, είναι λιγότερο ασφαλες από vanilla linux kernel όταν πρόκειται για παραβίαση φραγμών ασφαλείας. Τα τελευταία δύο χρόνια τουλάχιστον, υπηρξαν πιο σοβαρα vm escape στο xen σε σχεση με vanilla linux. Αυτό σημαίνει πως το qubes ειναι πιο εύκολο να παραβιαστει σε σχεση με πχ, fedora με SELinux, ή debian με apparmor. Και τάξεις μεγέθους πιο εύκολο να παραβιαστει συγκριτικα με distros με grsecurity hardened πυρήνα Linux, slackware ή gentoo, η διανομές σε alpha σταδιο ανάπτυξης, πχ subgraph.
Καπου εδω τα πράγματα γίνονται ακομα χειρότερα, η εξάρτηση του qubes πανω στο xen για την ασφάλεια του έχει ως αποτέλεσμα να μην εχεις καμια απολύτως άμυνα σε επίπεδα, το οποίο αποτελει βασική αρχή της ασφάλειας. Από προεπιλογή, δίνει στα appvm πρόσβαση root μέσω sudoers nopassword. Αυτό σημαίνει οτι το appvm σου μπορεί ανά πάσα στιγμή, να πάρει root! το μοντέλο ασφάλειας του Qubes υποθέτει πως αυτό δεν αποτελει προβλημα, γιατί το Xen δεν μπορεί να παραβιαστει. Υπαρχουν πολλα προσφατα xen exploits που επιτρεπουν στον εισβολέα να παρει kernel mode πρόσβαση, σε περιπτωση που ο εισβολέας έχει root :)
οποτε καταλαβαινεις πως υπάρχει σοβαρο ζήτημα με το βασικό μοντέλο ασφάλειας του qubes, λείπει μια βασική αρχή ασφαλείας, με αποτέλεσμα να έχει πολλά τρωτά σημεία. Και δεν είμαι μόνο εγω υπαρχουν ένα σωρό άλλοι που παρατηρήσαν σοβαρες ελλειψεις proactive ασφαλειας στο xen. Προτεινω να χρησημοποιησετε KVM σε hardened kernel.
Επισης, υπάρχουν και άλλα προβληματα με το qubes, αν και δεν είναι τόσο σοβαρα οπως ολικα break-out. Eπιθέσεις side-channel όπως prime/probe, flush/reload, flush/flush είναι εφικτες, και υπάρχουν διαθεσιμα PοC... δουλευουν σε όλα τα x86 και (νομιζω) ARM συστηματα. Μπορούν να χρησιμοποιηθούν για αποκλοπή πληροφοριών, πχ αυτα που πληκτρολογούνται σε ένα πρόγραμμα περιήγησης, ακόμα και cross-vm. Το μοντέλο ασφάλειας του qubes το αγνοεί αυτό! μόνο σε sandbox με λειτουργία 1sseccomp έχεις τη δυνατότητα να το αντιμετωπισεις, απενεργοποιωντας το TSC insruction (επισης θα μπορούσες να το απενεργοποιήσεις με prctl call, αλλά αυτό μπορεί να αναιρεθεί με διάφορους τρόπους χωρίς seccomp). Το Qubes δεν εχει τη δυνατοτητα να το αντιμετωπισει αυτο, επειδή υποθέτει πως όλες οι επιθέσεις μπορουν να αντιμετωπιστουν απο το xen...
Επισης, ενα αλλο θεμα που έχει επισημανθεί απο το δημιουργό του grsecurity. Για διάφορους "τεχνικούς λόγους", καποιοι kick-in μηχανισμοί αυτοάμυνας πυρηνα του xen σε αποτρέπουν να χρησημοποιησεις grsecurity. Αυτό μειώνει την ασφάλεια τόσο του host οσο και του guest.
Τουλάχιστον υπάρχει κατι που το qubes είναι αρκετά καλο, ακόμη και αν λαβουμε υποψη τις (αν)ασφάλειες του xen. Λόγω χρήσης driver domains, τουλάχιστον σε συστήματα με IOMMU που υποστηρίζουν remapping interrupt (για intel τουλάχιστον, sandy bridge και νεότερες CPUs), hardware exploit για το PCH δεν οδηγει απαραίτητα σε επιτυχημένη επίθεση DMA για το υπόλοιπο συστήμα. Ωστόσο, αυτο αποτελει προβλημα μονο οταν το σύστημά είναι κλειδωμένο και κάποιος συνδέσει κακόβουλη συσκευή USB που μπορεί να εκμεταλλευτεί το ριζικό διανομέα USB, ο οποίος είναι hardware!!! hardware exploit δίνει απευθειας πρόσβαση στην PCH, η οποία έχει άμεση πρόσβαση στη μνήμη. Κανοντας το isolate με το IOMMU περιορίζει τη ζημιά που μπορεί να γίνει. Εννοειται αυτο ισχύει μόνο για τη φυσικούς εισβολείς, απλα συνδέουν εναν in-target probe JTAG debugger στη μητρική και pwnαρουν όλοκληρο το συστημα, Αν η CPU σου δεν εκθέτει το JTAG, τότε μπορει να γινει μεσω GPU (δεν υπαρχει driver domain). H θα μπορούσαν να επιτεθούν στο superio, ή να κανουν τιποτα μαγικα acpi bytecode. Αλλά αν το μόνο που διαθετουν ειναι ενα USB roothub zero-day και έχουν μονο φυσική πρόσβαση, και το σύστημα είναι κλειδωμένο, τότε οι domain drivers του Xen είναι επαρκεις.