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

[poscaman]

μμμ ενδιαφερον.

 

υποθετω γεμιζει την μνημη με μηδενικα;

 

επισης πρεπει να τρεξει σαν root.δυσκολο...

[soturin]

ποσο νομιμη ειναι μια fork bomb?

 

συνδεομαι σε εναν σερβερ σαν χρηστης και του τρεχω μια fork bomb.ειμαι παρανομος;

 

poscaman: δεν ξέρω πως μπορεί να σχετιστεί με τη «νομιμότητα» κάτι τέτοιο. Είναι όσο νόμιμο είναι το να σβήσεις το /bin ας πούμε και σε καμία περίπτωση δε συνιστά ορθή χρήση των πόρων που σου διατίθενται. Κάνεις denial of service και προσωπικά θα σου διέγραφα το account κατ' ελάχιστον, ασχέτως παρανομίας ή όχι.

 

αυτό το topic έπρεπε να υπάρχει ήδη όταν επισκέφθηκα το linux lab στο "μέτσοβο"

[firewalker]

Ποια μνήμη όμως; Δάσκαλε εξήγησε...

[poscaman]

Ποια μνήμη όμως; Δάσκαλε εξήγησε...

/dev/zero

 

/dev/mem την ιδια σου την RAM αγαπητε μου (man mem για περισσοτερα)

[gtroza]

http://kerneltrap.org/node/3950

 

?

[suser]

Τι κάνει αυτό firewalker τελικά;

[NullScan]

Αυτό κάνει το σύστημα να νομίζει οτι η μνήμη σου είναι γεμάτη μηδενικά εάν φροντίσεις τα majon και minor του device να είναι ίδια με αυτά του mem

[suser]

Και γιατί ο firewalker μας είπε να μην το δοκιμάσουμε?

[firewalker]

Γιατί μπορεί να πειραχτεί και το file system (τραβηγμένο ίσως).

[apoikos]

Εκτός από το filesystem μπορεί να πειραχτούν και άλλα πράγματα, όπως το PCI configuration space, με απρόβλεπτες συνέπειες.

[poscaman]

μμ το δοκιμασα στον φορητο.μεχρι τωρα δεν εδειξε κατι το περιεργο

 

ερωτηση προς το δασκαλο.Εφοσον τo /dev/mem ειναι ram τι σχεση εχει το filesystem να πειραχτει;

[alkisg]

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 εντολές επί Χ ώρα, εγώ για σιγουριά τέτοιες δοκιμές δεν κάνω!

[apoikos]

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]

Πάντως alkisg, μιλάμε για το /dev/zero, οπότε μόνο προσθέσεις θα έκανε η CPU.

 

Άμα δεν γεμίσει ΟΛΗ η μνήμη με μηδενικά παρά μόνο ένα μέρος της,

τότε άνετα μπορούν να εκτελεστούν random εντολές.

 

Παράδειγμα, έστω ότι στη θέση 100 υπάρχει ο παρακάτω κώδικας ενός προγράμματος, που καλεί μια διαδικασία:

>
-u 100
0B39:0100 BB12B4        MOV     BX,B412
0B39:0103 05CD13        ADD     AX,13CD
0B39:0106 E874E4        CALL    E57D

 

Ας γράψουμε 2 μηδενικά στις θέσεις 100 και 101 να δούμε τι θα γίνει:

>
-e 101
0B39:0101  12.00-
0B39:0100  BB.00
-u 100
0B39:0100 0000          ADD     [bX+SI],AL
0B39:0102 B405          MOV     AH,05
0B39:0104 CD13          INT     13

 

Εχμ, μια ακίνδυνη πρόσθεση, και μια ...όχι και τόσο ακίνδυνη κλήση format tracks με το INT 13.

 

Ο κώδικας άλλαξε τελείως επειδή άλλαξε το μέγεθος της πρώτης εντολής, από 3 bytes σε 2 bytes, οπότε όλες οι υπόλοιπες εντολές από εκεί και κάτω ουσιαστικά (μπορεί να) είναι random.

 

Το ίδιο μπορεί να γίνει και με ένα μόνο λανθασμένο jump ή call σε κώδικα, αν πέσει στο μέσο εντολής τότε αλλάζει το νόημα όλων των επόμενων εντολών.

[firewalker]

Γουστάρω...