Fork bombs και άλλα τέρατα

[apoikos]

@alkisg: πράγματι, δεν το είχα σκεφτεί ότι από operand μπορεί να γίνει opcode απλά και μόνο γιατί οι εντολες δεν είναι aligned. Ωστόσο χρησιμοποιείς real mode assembly, οπότε προφανώς το συγκεκριμένο παράδειγμα δε θα λειτουργήσει, αφού, μεταξύ άλλων, το Linux δεν κάνει καν setup interrupt handler για το 0x13 (μόνο το dosemu το κάνει AFAIK). Για την ακρίβεια νομίζω ότι το μόνο software interrupt που χρησιμοποιείται στα *NIX συστήματα είναι το 0x80, για το syscall interface. Ωστόσο προφανώς μπορούν να συμβούν αντίστοιχα πράγματα σε protected mode, αν και υπάρχει μια "extra" δικλείδα του hardware protection. Σε κάθε περίπτωση, μια λάθος κλήση του int 0x80 μπορεί κάλλιστα να περάσει ένα call για την unlink για παράδειγμα, η οποία όμως θα «φιλτραριστεί» μέσα από permissions, capabilities, κλπ.

 

Συνοπτικά, σαφώς και υπάρχει κίνδυνος, αλλά το όλο σύστημα είναι τελικά τόσο πολύπλοκο που είναι δύσκολο να εκτιμήσεις τι μπορεί να πάει στραβά και πόσο πιθανό είναι αυτό. Σε κάθε περίπτωση υποθέτω ότι το πιο επικίνδυνο απ' όλα είναι να γίνει corruption σε κομμάτι του κώδικα του πυρήνα, το οποίο τρέχει σε Ring 0 και μπορεί να κάνει πρακτικά οτιδήποτε.

 

@firewalker: και 'γω. Πάμε σε πολύ esoteric καταστάσεις

[firewalker]

Κάτι που κάναμε παλιά σε DOS των win98 και πήγαινε άκλαυτο...

 

Μέσω debug σαν απλοί χρήστες (λες και υπάρχουν άλλου είδους...). Πριν βγουν οι bios write protections τα ξέσκιζες σχετικά άνετα με το debug... Αν και ο παρακάτω κώδικας δεν πειράζει το bios.

 

mov dx,9000

mov es,dx

xor bx.bx

mov cx,001

mov dx,0080

mov ax,0301

int 13

int 20

 

Σε *nix μάλλον δεν θα γίνεται...

[alkisg]

Sorry, δεν είχα πρόχειρο 32bit assembler και βολεύτηκα με το debug. Και το παράδειγμα σε protected mode θα ήταν πολύ πιο δυσνόητο, και επίσης θα έπρεπε να ξεσκονίσω και μερικά βιβλία από το χρονοντούλαπο...

 

Εντωμεταξύ αν γεμίσει το interrupt vector table με μηδενικά, δεν θα παίζει κανένα ρόλο τι interrupts είχε κάνει setup προηγουμένως το λειτουργικό, όποιο interrupt και να εκτελεστεί στη συνέχεια ο PC θα γίνει 0000000 και θα αρχίσει να εκτελεί ό,τι βρει από την αρχή της RAM και μετά...

 

Συγκεκριμένα για το Linux, δεν έχω ιδέα τι κάνει με τα protected mode rings και τα λοιπά ενδότερα. Π.χ. ο κώδικας που τρέχει ο root, έχει δικαίωμα να κάνει απευθείας jump ή call σε οποιαδήποτε θέση του kernel, ή η μνήμη του kernel είναι σε διαφορετικό address space και χρησιμοποιεί gates με ενδιάμεσο κώδικα σε protected memory space? (οπότε θα είναι λίγο πιο απίθανο, θα πρέπει να γίνει το κατάλληλο call, ή ένα jmp στον ενδιάμεσο κώδικα χειρισμού της πύλης, και όχι ένα οποιοδήποτε jmp στη μέση του kernel code).

 

Πάντως για να υπολογίσει κάποιος έστω και στο περίπου την πιθανότητα κάτι να πάει στραβά, θα χρειαστεί χρόνια!!! Πιο εύκολα θα βγει με δοκιμές... Επομένως όποιος θέλει, μπορεί να το δοκιμάσει μερικές εκατοντάδες φορές και να μας πει στις πόσες έχασε το δίσκο!!! :D

[apoikos]

Συγκεκριμένα για το Linux, δεν έχω ιδέα τι κάνει με τα protected mode rings και τα λοιπά ενδότερα. Π.χ. ο κώδικας που τρέχει ο root, έχει δικαίωμα να κάνει απευθείας jump ή call σε οποιαδήποτε θέση του kernel, ή η μνήμη του kernel είναι σε διαφορετικό address space και χρησιμοποιεί gates με ενδιάμεσο κώδικα σε protected memory space? (οπότε θα είναι λίγο πιο απίθανο, θα πρέπει να γίνει το κατάλληλο call, ή ένα jmp στον ενδιάμεσο κώδικα χειρισμού της πύλης, και όχι ένα οποιοδήποτε jmp στη μέση του kernel code).

AFAIK χρησιμοποιεί το Ring 0 για τον πυρήνα και το Ring 3 για τον userspace κώδικα. Το transition γίνεται με το interrupt 0x80, κατά το οποίο ο eax έχει την τιμή της syscall προς εκτέλεση, o ebx το 1ο όρισμα, o ecx το δεύτερο, o edx το τρίτο κλπ. Κατά την εκτέλεση της system call μόνο νομίζω ότι τρέχει σε Ring 0, οπότε ο κώδικας της syscall μπορεί να κάνει jmp οπουδήποτε (δεν ξέρω τι παίζει με το segmentation σε αυτήν την περίπτωση βέβαια). Όμως ο userspace κώδικας που τρέχει ο root υπόκειται στους ίδιους περιορισμούς με αυτόν των απλών χρηστών, δηλαδή τρέχει σε Ring 3. Γι' αυτό και υπάρχει το /dev/mem, ώστε μέσω του syscall interface (read/write), να μπορεί ένα privileged (euid root ή egid kmem) process να διαβάσει/γράψει οπουδήποτε στη μνήμη, κάτι που δεν μπορεί να κάνει από το userspace.

[alkisg]

Εντωμεταξύ υπάρχει και η περίπτωση οι τυχαίες εντολές που θα εκτελεστούν να αποτελούν ένα νέο λειτουργικό σύστημα, με το οποίο ο υπολογιστής θα αυτο-εξελίσσεται, θα αυτο-διορθώνεται κτλ, οπότε ίσως αν το δοκιμάσουμε 2^12345678 φορές να γίνει ο Η/Υ πιο έξυπνος από εμάς και να αρχίσει η επέλαση των μηχανών...

 

Προσέξτε!!!

 

(βέβαια οι εκατομμύρια πίθηκοι που βαράμε τυχαία πλήκτρα στο Internet κάθε μέρα ακόμα δεν έχουμε γράψει τα έργα του Σέξπηρ... Ίσως τελικά η πιθανότητα να είναι 2^123456789).

 

Ουφ... μόλις μου κάηκε μια οθόνη (όχι από λάθος εντολές, don't worry), οπότε back to work.

edit: Apoikos, θα δω αργότερα αυτά που έγραψες κι αν βρω χρόνο θα ρίξω μια ματιά και στα ενδότερα του Linux.

[firewalker]

Δεν είναι γαμάτα όλα αυτά;

[apoikos]

Είναι, είναι...

 

Έχω χαθεί εδώ και 2 ώρες, διαβάζω κώδικα του πυρήνα. Οι νέοι πυρήνες έχουν 2 τρόπους να καλούν system calls: τον κλασσικό με software interrupt (int 0x80), και τον νεότερο (pentium II+) με τις sysenter/sysexit instructions. Και το καλύτερο είναι ότι αυτό γίνεται διαφανώς, κατά την εκτέλεση, ανάλογα με το αν το υποστηρίζει το μηχάνημα ή όχι.

[gtroza]

κύριε

γράφω την εντολή που είπε το παιδί απ'την άλλη τάξη*

Δεν είναι γαμάτα όλα αυτά;

πατάω enter

αλλά ο υπολογιστής μου δεν κολλάει !

 

μήπως να βγάλω την μπρίζα ;:mrgreen:

 

*τον αναστενάρη εννοώ, όχι τον κύριο alkisg !

.

[poscaman]

poscaman, η RAΜ εκτός από διάφορα άλλα έχει και τον κώδικα των προγραμμάτων. Αν γράψεις τυχαία δεδομένα στη RAM, θα εκτελεστούν τυχαίες εντολές. Μια από αυτές μπορεί να είναι η rm -rf /

:P

 

ΟΚ, πέρα από την απλουστευμένη έκδοση, δεν είναι και τόσο απίθανο να εκτελεστεί κάτι ριζικά άσχημο για τον Η/Υ.

Π.χ. μια κλήση int 13 του BIOS για το δίσκο είναι 2 bytes, δηλαδή 1/65536 πιθανότητα να εκτελεστεί. Με τόσες εντολές που εκτελεί ο Η/Υ το δευτερόλεπτο δεν είναι και απίθανο να εκτελεστεί κάποια τέτοια. Πολλαπλασιάζεις επί την πιθανότητα ο ax να έχει τις τάδε τιμές που χρειάζεται για να φορμάρεις ή να γράψεις κάποιον sector, και βρίσκεις την πιθανότητα να κάνεις μόνιμη ζημιά σε κάποιον sector του δίσκου.

Εχμ, αυτά όταν επιτρέπονται BIOS κλήσεις, δηλαδή όταν υπάρχει το real mode interrupt vector table. Σε Windows/Linux υπάρχουν τα system calls, με λίγο πιο "απίθανες" πιθανότητες επειδή το far call είναι 3 bytes.

Το PCI configuration space μπορεί άνετα να πειραχτεί, αλλά απ' όσο ξέρω θα ξαναδημιουργηθεί στην επόμενη επανεκκίνηση (apoikos correct me if I'm wrong). Όμως επίσης δεν είναι απίθανο να τρέξει κώδικας που να πειράζει το firmware κάποιας συσκευής, με μόνιμες βλάβες.

 

Φυσικά πιθανό είναι και σε κάποια στιγμή να πέσει σε άπειρο loop ο random κώδικας, οπότε να μην υπάρχει πιθανότητα σφάλματος από εκεί και πέρα.

 

Όποιος είναι γερός στα μαθηματικά μπορεί να μας υπολογίσει την ακριβή πιθανότητα να πάθει μόνιμη ζημιά ο Η/Υ όταν τρέχει random εντολές επί Χ ώρα, εγώ για σιγουριά τέτοιες δοκιμές δεν κάνω!

 

poscaman:

Το filesystem, όπως και κάθε τι άλλο, έχει ένα running image στη μνήμη. Αφενός έχει το κομμάτι κώδικα που το χειρίζεται, αφετέρου έχει buffers, caches κλπ. Γενικώς δύο τινά μπορεί να συμβούν:

• Επειδή με την εντολή αυτή θα κρασάρει γερά ο υπολογιστής, θα υπάρχουν πράγματα στα buffers που δε θα έχουν προλάβει να γραφτούν στο δίσκο. Είναι βασικά ό,τι συμβαίνει και όταν κάνεις hard reset: θα χρειαστεί journal replay ή fsck για non-journaled filesystems
  
• Εκτός από το παραπάνω, υπάρχει η μικρή πιθανότητα να προλάβει να αλλοιωθεί η μνήμη που αντιστοιχεί είτε στον κώδικα του filesystem είτε στα buffers. Στην περίπτωση αυτή η συμπεριφορά είναι απρόβλεπτη και μπορεί να οδηγήσει σε ολικό corruption του filesystem

Γενικά η εντολή αυτή (dd) μάλλον δε θα προλάβει να τερματίσει, γιατί πρώτα θα έχει αλλοιωθεί ένα σημαντικό κομμάτι της μνήμης που αργά ή γρήγορα θα οδηγήσει σε κάποιο exception, στην καταστροφή του scheduler, στο άνοιγμα πύλης για τη διάσταση X κλπ. Επειδή όμως ουσιαστικά το μόνο persistent πράγμα που υπάρχει είναι το filesystem (και το BIOS και οι διάφορες EEPROMS), είναι και το μόνο πράγμα που μπορεί να πάθει ζημιά όπως περιέγραψα παραπάνω.

 

edit: με πρόλαβε ο alkisg, και τα είπε αναλυτικότερα απ' ότι βαριόμουν να τα γράψω εγώ ;-)

Πάντως alkisg, μιλάμε για το /dev/zero, οπότε μόνο προσθέσεις θα έκανε η CPU. Οι κίνδυνοι αυτοί είναι σαφώς σημαντικότεροι με το /dev/random, όπως είπες. Όσον αφορά στο PCI configuration space, πράγματτι νομιζω ότι αναδημιουργείται, αλλά αναφερόμουν σε ακριβώς αυτήν την περίπτωση που πεις σε κάποιο περιφερειακό να κανει κάτι ηλίθιο εκείνη τη στιγμή.

 

ευχαριστω πολυ για τις απαντησεις.Λειτουργικα ακομα δεν εχουμε κανει στη σχολη οποτε δυστυχως εχω αρκετα κενα (εως το απολυτο κενο!) σε αυτα τα πραγματα.

 

παντως εχω μεινει εντελως με το στομα ανοιχτο.Μπραβο παιδια για τις γνωσεις σας.

[alkisg]

Χμμμ... τελικά με τις sysenter/syscall είναι πιο απίθανη η περίπτωση βλάβης.

 

Προφανώς με τυχαίες εντολές μπορεί να τρέξει ο,τιδήποτε, δηλαδή το sudo rm -rf / πάντα θα είναι πιθανό, έστω και με μικροσκοπικά μικρή πιθανότητα.

 

Αυτό που ήθελα να δω όμως είναι αν γίνεται να καλέσουμε μια εντολή στη μέση του πυρήνα. Αυτό, αν δεν είχαμε "κακές προθέσεις", θα είχε απλά σαν αποτέλεσμα το πλήρες χάος.

Από την άλλη, κάποιοι με κακές προθέσεις θα μπορούσαν να βρουν έναν κατάλληλο συνδυασμό opcodes κάπου στη μέση του κώδικα του τάδε πυρήνα, να πειράξουν κάποια από τις sysenter / syscall / int 80 (linux) / int 2e (windows) / int 82 (virtualization) ώστε να κάνει jmp απευθείας εκεί και να αποκτήσουν πρόσβαση για να εκτελέσουν κώδικα σε ring 0.

Αν αυτό μπορούσε να γίνει, τότε θα είχαμε σοβαρά προβλήματα ασφάλειας, αφού ο κάθε hacker θα μπορούσε... να τρέξει το δικό του λειτουργικό σύστημα στον Η/Υ μας.

 

Ευτυχώς από Pentium II και μετά υπάρχει hardware προστασία για τέτοια. Η syscall κάνει πάντα jump σε μια συγκεκριμένη θέση του πυρήνα, η οποία έχει οριστεί κατά την εκκίνηση του λειτουργικού με την εντολή wrmsr.

Από userspace (ring 3) η εντολή wrmsr δεν επιτρέπεται να κληθεί για να αλλαχθεί η θέση του jump της syscall, και επομένως δεν γίνεται να αποκτήσουμε πρόσβαση σε ring 0 με ...απλά πηδηματάκια.

 

Αν και δεν το κοίταξα, υποθέτω ότι κάτι παρόμοιο συμβαίνει και με όλες τις περιπτώσεις GPF / hardware interrupts κτλ.

 

Επομένως θεωρητικά οποιοσδήποτε χαμός κι αν γίνεται στο userspace, ο kernel θα συνεχίσει να τρέχει. Πρακτικά βέβαια υπάρχουν και bugs στα προγράμματα που τρέχουν σε ring 0, αλλά αυτό είναι άλλο θέμα.

 

Ένα νέο ερώτημα που μου ήρθε τώρα στο νου: έστω ότι έχει γίνει χαμός στο userspace και ο kernel τρέχει κανονικά. Είναι (;; καλύτερο να κλείσουμε τον Η/Υ με SysRq+REISUB για να αδειάσει τους buffers, ή παίρνουμε μεγαλύτερο ρίσκο να γραφούν σκουπίδια στο δίσκο;

[NullScan]

Σε κάθε περίπτωση (θεωρώ οτι) είναι καλύτερα να κάνεις flush τους buffers στο δίσκο ακόμα και αν υπάρχει μεγάλη πιθανότητα να είναι σκουπίδια. Το σημαντικότερο μετά από ένα τέτοιο system crash είναι να βρείς γιατί έγινε οπότε αυτά τα "logs" ίσως να είναι το μοναδικό στοιχείο που έχεις.

Άλλωστε γι αυτό οι σωστοί sys admins φροντίζουν να παίρνουν συχνά backups από αυτά τα συστήματα και τα system logs να μην είναι στο ίδιο partition με τα υπόλοιπα data, ιδανικά να μην είναι καν στο ίδιο σύστημα.