Καλώς ορίσατε στο dotNETZone.gr - Σύνδεση | Εγγραφή | Βοήθεια
σε

 

Αρχική σελίδα Ιστολόγια Συζητήσεις Εκθέσεις Φωτογραφιών Αρχειοθήκες

Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

Îåêßíçóå áðü ôï ìÝëïò Thiseas. Τελευταία δημοσίευση από το μέλος Thiseas στις 04-06-2007, 21:27. Υπάρχουν 17 απαντήσεις.
Σελίδα 1 από 2 (18 εγγραφές)   1 2 >
Ταξινόμηση Δημοσιεύσεων: Προηγούμενο Επόμενο
  •  02-06-2007, 00:03 32481

    Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

    Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα πριν την κατανόηση του Buffer Overflow.

    Το συγκεκριμένο post είναι αναδημοσίευση στα Ελληνικά ενός άρθρου που είχα γράψει παλιά στο HellboundHackers και μετά στο secFreaks.gr.

    Δεν πρόκειται για ένα buffer overflow exploit, αλλά για το απαιτούμενο υπόβαθρο που θα βοηθήσει κάποιον να καταλάβει κάποια σύνθετα ζητήματα, όπως το buffer overflow. Θα προυσιαστεί, με παραδείγματα, πως επικοινωνούν η CPU, η μνήμη κατά την εκτέλεση ενός προγράμματος.

     

    Επειδή δεν υπήρχε αντίστοιχο SECTION και δεν ήξερα που να βάλω το post αυτό, αποφάσισα να το βάλω εδώ, μαζί με το "Επίθεση & Άμυνα". Αν εχω κάνει λάθος, ζητω συγγνώμη,.... που θα "χώσω" κάποιον mod να το μετφέρει.... Smile


    Έχω διαβάσει πολλά άρθρα για το περίφημο 'buffer overflow'. Τα περισσότερα ξεκινούν από ένα σημείο το οποίο απαιτεί γνώσεις που δεν τις έχουν όλοι.

    Αυτό το μικρό tutorial προσπαθεί να καλύψει το έλλειμα και να οδηγήσει κάποιον (ελπίζω) σ’ αυτό το σημείο.

    Αν στο τέλος του άρθρου αυτού θα αισθάνεστε πιο... «άνετα» με μερικές έννοιες όπως CALL, RETN καθώς και πως καλείται μια function() στην μνήμη (buffer, stack, κλπ) θα αισθάνομαι οτι το αρθράκι μου πέτυχε το στόχο του.

    Πρώτα απ’ όλα θα ήθελα να σημειώσω πως οτιδήποτε θα πω θα αναφέρομαι για την οικογένεια επεξεργαστών xx86. Επίσης οι διευθύνεις μνήμης θα αναφέρονται στο δεκαδικό σύστημα για λόγους ευκολίας αυτών που δεν έχουν συνηθίσει το δεκαεξαδικό σύστημα που συνήθως χρησιμοποιείται.

    Απαιτήσεις για να διαβάσει κάποιος το άρθρο:
    1.Στοιχειώδεις γνώσεις assembly.
    2.Στοιχειώδεις γνώσεις C.
    3.Να ξέρει τι σημαίνει υπολογιστής.
    4.Να γνωρίζει να διαβάζει Ελληνικά.
    5.Μα τίποτα από τα παραπάνω!! Απλά ανοιχτό μυαλό, φαντασία και... όρεξη.

    Εντάξει,.. εντάξει (έξυπνοι!!)... ίσως το 4 και 5 είναι απαραίτητα (αν και το ένα αναιρεί το άλλο).

    Σας ακούω να λέτε...: "Άντε ρε λαμέρι πολλά λές... θα ξεκινήσεις επιτέλους!!"

    Ok Ok . . . λοιπόν:

    Για κάθε πρόγραμμα που καλείται στη μνήμη για να εκτελεστεί, το λειτουργικό σύστημα του δημιουργεί 3 βασικά μέρη (Segments):
    -Code Segment
    -Data Segment (το γνωστό BSS)
    -Stack Segment

    CODE SEGMENT
    Σ’ αυτό το κομμάτι μνήμης υπάρχουν όλες οι εντολές του προγράμματος. Κανένας (κανένας?... τεσπα σχεδόν κανένας) δεν μπορεί να γράψει σ’ αυτό το κομμάτι της μνήμης. Ονομάζεται μνήμη μόνο για διάβασμα (ReadOnlyΜνήμη Segment) – Μην την μπερδεύετε με τη ROM (ReadOnlyΜνήμη) του υπολογιστή που είναι τελείως διαφορετικό πράγμα.

    Για παράδειγμα
    Όλες οι εντολές assembly (εδω σε κώδικα C) θα τοποθετηθούν στο Code Segment.

    /* Ολες οι τιμές της 1ης διαγωνίου του πίνακα να γινουν 1, τα άλλα 0 */
    for (i = 0; i < 100; i++)
       for (j = 0; j < 100; j++)
          if (i<>j)
             a[ i][j]
    = 0
          else
             a[ i][j]
    = 1; // sorry για το space στο [ i] αλλά το ρημάδι... αν το αφησω χωρις space μεταλάσεται σε ... ΛΑΜΠΑ Idea
    Τα σχόλια φυσικά δεν πρόκειται να μεταφερθουν στο CodeSegment γιατί απλά κανένας compiler που γνωρίζω δεν μεταφράζει και τα... σχόλια.


    DATASEGMENT
    Εδώ τοποθετούνται όλες οι αρχικοποιημένενες γενικές μεταβλητές (globalvariables). Πρόκειται για ένα κομμάτι μνήμης που επιτρέπεται το γράψιμο πάνω σ’ αυτό.
    Για παράδειγμα ο παρακάτω C κώδικας θα τοποθετηθεί στο DataSegment:
    int i=1;
    char cp=65;
    int a[10]={1,2,3,4,5,6,7,8,9,10};
    char p[10]={“Heloooo!”}

    STACK SEGMENT
    Όλες οι μεταβλητές των συναρτήσεων (functions), οι διευθύνεις των συναρτήσεων τοποθετούνται σε αυτό το κομμάτι μνήμης.

    Αυτό το κομμάτι είναι μια δομή στοίβας (γνωστή σ’ αυτούς που έχουν παρακολουθήσει κάποιο μάθημα βασικών αρχών δομών δεδομένων). Δηλαδή οι μεταβλητές τοποθετοτούνται στην μνήμη, η μία «επάνω» στην άλλη φτιάχνοντας μια στοίβα. Έτσι, η μεταβλητή που μπήκε τελευταία θα είναι και αυτή που θα βγεί πρώτη από τη στοίβα (περίπτωση LIFO – Last In First Out).

    Στον επεξεργαστή μας υπάρχουν μεταβλητές που χρησιμοποιούνται για να «φιλοξενούν» τιμές σχετικές με την τρέχουσα εργασία που κάνει ο επεξεργαστής. Οι μεταβλητές αυτές ονομάζονται καταχωρητές (registers). Υπάρχουν αρκετοί καταχωρητές που περιέχουν πληροφορίες για αρκετά πράγματα, δεν θα τα αναφέρω ένα προς ένα γιατί θα χάσουμε την.. μπάλ... εεε sorry, τονστόχο!

    Ένας καταχωρητής ονομάζεται ESP (Extended Stack Pointer – Δείκτης της Στοιβας) περιέχει κάθε φορά την διεύθυνση που βρίσκεται το τελευταίο στοιχείο που μπήκε στη Στοίβα. Δηλαδή, είναι αυτό που θα βγεί πρώτο από αυτή.

    Στη στοίβα, έχουμε την δυνατότητα να εισάγουμε τιμές (PUSH) ή να εξάγουμε (POP).
    Οι εντολές PUSH και POP είναι εντολές της γλώσσας assembly που κάνουν αυτή τη δουλειά.

    Εδώ πρέπει να αναφέρω 2 μικρά μυστικά:
    [1] Οι εντολές PUSH και POP πραγματοποιούν πράξεις στην μνήμη σε «κομμάτια» των τεσσάρων bytes, εξ’ αιτίας της συγκεκριμένης αρχιτεκτονικής των επεξεργαστών της οικογένειας xx86.
    [2] Η στοίβα μεγαλώνει «προς τα κάτω», δηλαδή αν SP=256, μετά από μιά εντολή “PUSH”, ο SP θα είναι 252.

    Παράδειγμα:

     STACK
    Διευ.      Μνήμη
      ---- ------------------
      256  |   xy          |
      252  |               |
      248  |               |
      244  |               |
      ...  .................
      (ESP=256)
      
      Εντολή > PUSH EAX  ; πχ. EAX = 34
      
      STACK
      256  |   xy          |
      252  |   34          |
      248  |               |
      244  |               |
      ...  .................
      (ESP=252)
      
      Εντολή > POP EAX  
      STACK
      256  |   xy          |
      252  |   34          |
      248  |               |
      244  |               |
      ...  .................
      (ESP=256)
      
      
      Εντολή > PUSH 15   ; remark: suppose EAX = 15
      Εντολή > PUSH 16   ; remark: suppose EBX = 16
      
      STACK
      256  |   xy          |
      252  |   15          |
      248  |   16          |
      244  |               |
      ...  .................
      (ESP=248)



    Τι βρίσκεται πίσω από μια κλήση συνάρτησης
    Πριν εξηγήσουμε τι γίνεται πρέπει να πουμε μερικά πράγματα για άλλον ένα καταχωρητή του επεξεργαστή: Το Δείκτη Εντολής EIP (Extended Instruction Pointer ή 'Instruction pointer'). Αυτός ο καταχωργητής περιέχει την διεύθυνση της εντολής που θα εκτελεστή από το πρόγραμμα μας. Δηλαδή αναφέρεται στο κομμάτι μνήμης Code Segment.

    Κάθε φορά που ο επεξεργαστής εκτελεί μια εντολή καταχωρεί στον EIP την επόμενη προς εκτέλεση εντολή.
    Πώς όμως η επεξεργαστης μας βρίκει ποια θα είναι η επόμενη εντολή;
    Χμ... εδώ πρέπει να διακρίνουμε 2 περιπτώσεις:
    1.Θα εκτελεστεί η επόμενη εντολή στη επόμενη θέση μνήμης στο code segment.
    2.Θα εκτελεστεί μια απομακτυσμένη εντολή εξ’ αιτίας μια εντολής JUMP (πήδα... χε χε) σε μια άλλη διεύθυνση! Π.χ. αν ο επεξεργαστης συναντήσει την εντολή «JMP 345» θα βάλει στον EIP την τιμή 345. Άρα η επόμενη εντολή που θα εκτελεστεί θα είναι αυτή στην διεύθυνση 345.

    Στην περίπτωση 1 η διεύθυνση υπολογίζεται απλά προσθέτοντας το μήκος της τρέχουσας εντολής στη τρέχουσα τιμή του EIP.
    Παράδειγμα:

    Έστω οτι έχουμε τις ακόλουθες 2 εντολές στις διευθύνσεις 100 κι 101:

    100 push EDX
    101 mov  ESP 0

    Έστω οτι το παραπάνω μικρό μας πρόγραμμα ξεκινάει από την διεύθυνση 100. Δηλαδή EIP=100.
    1.Ο επεξεργαστής εκτελεί την εντολή στην διεύθυνση 100.
    2.Ο επεξεργαστής θέλει να [άει στην επόμενη εντολή στη σειρά, άρα ελέγχει:
    Η τρέχουσα εντολή (pushEDX) είναι εντολή JMP? Όχι, άρα υπολόγισε το μήκος της: Ο επεξεργστής «γνωρίζει» οτι η εντολή push έχει μήκος 1 byte.
    Οπότε:


      EIP = EIP + size(push EDX) =>
      EIP = 100 + 1 =>
      EIP = 101

    Οπότε θα εκτελέσει την εντολή που βρισκεται στην διεύθυνση 101.

    Στην περίπτωση 2, έχουμε JMP... εδώ τα πράγματα είναι λίγο πιο σύνθετα.
    Για την ακρίβεια ακριβώς πριν το JMP σε μια άλλη διεύθυνση (δηλαδή μια κλήση συνάρτησης), ο επεξεργαστής πρέπει να κρατήσει την διεύθυνση της εντολής που θα εκτελεστεί όταν επιστρέψουμε από την συνάρτηση. Αυτή η διεύθυνση θα φυλαχθεί σε έναν προσωρινό καταχωρητή, ας πούμε τον EDX, οπότε μόλις εκτελεστούν όλες οι εντολές της συνάρτησης, θα θέσουμε EIP=EDX

    Στην γλώσσα assembly χρησιμοποιούνται οι εντολές CALL και RETN για τον υπολογισμό της παραπάνω διεύθυνσης.
    ΗCALL κάνει 2 πραγματάκια:
    1.Κρατάει την εντολή που θα εκτελεστεί όταν τελειώσουμε με τις εντολές της συνάρτησης (βάζοντας τη διεύθυνση της εντολής αυτής στη στοίβα – στο STACK).
    2.Καταχωρεί στον EIP την διεύθυνση της συνάρτησης έτσι ώστε να εκτελεστεί.

    Η εντολή RETN θα κλειθεί στο τέλος της συνάρτησης:
    Θα κάνει POP (θα ανακτήσει) την διεύθυνση εκείνη που καταχώρησς η CALLστο βήματος 1 (λίγο πριν): Είναι η διεύθυνση της εντολής που θα εκτελεστεί μετά το τέλος της συνάρτησης.


    Base pointer (EBP) (θα το δυσκολέψουμε λίγο τώρα....sorry)
    Κάθε συνάρτηση σε κάθε πρόγραμμα (ακόμα και η main() σε ένα πρόγραμμα C) έχει το δικό της χώρο μεταβλητών στο stack. Αυτός ο χώρος ονομάζεται Stack Frame (θεωρώ οτι είναι άσκοπο να προσπαθήσω να μεταφράσω τέτοιες λέξεις εφόσων θεωρούνται πια ορισμοί). Το stack frame είναι μια λογική ομάδα από θέσεις μνήμης στο stack που κρατούνται όλες οι διευθύνσεις των μεταβλητών που ανήκουν στη συνάρτηση που εκτελείται εκείνη τη στιγμή.

    Κάθε διεύθυση μέσα στο stack frame είναι σχετική διεύθυνση με βάση το τρέχων stack frame. Και που θα ξέρουμε πιο είναι το τρέχον stack frame? Αυτό καταχωρείται στον καταχωρητή EBP (στον base pointer).

    Όποτε καλείται μια συνάρτηση ο επεξεργαστής κάνει PUSH τον παλιό ESP στο stack και βάζει στον EBP την διεύθνση της συνάρτηση έτσι ώστε να αναφέρεται στις μεταβλητές της με βάση τον EBP.
    Θα προσπαθήσω να το ξεκαιαρίσω αυτό με ένα αληθινό παράδειγμα σε C.

    Ακολουθεί αληθινό Παράδειγμα σε C



    void function1(int , int , int );
    void main()
    {
       function1 (1, 2, 3);
    }

    void function1 (int a, int b, int c)
    {
       char z[4];
      
    Έκανα compile/link το παραπάνω πρόγραμμα σε Dos command και μπήκα με ollydebugger να δω τι... γίνεται:
    Αδιαφορώντας για τις εντολές του λειτουργικού συστήματος (που καταλαμβάνουν το 90% του κώδικα!!) απομόνωσα το κομμάτι που αντιστοιχεί στο παραπάνω μικρό και βλαμένο πρόγραμμα (χε χε χε,... το βρίζω γιατί δεν κάνει τίποτα σαν πρόγραμμα, απλά τρώει mμνήμη) :

    Έχουμε λοιπόν:

    0040123C  /. 55             PUSH EBP
    0040123D  |. 8BEC           MOV EBP,ESP
    0040123F  |. 6A 03          PUSH 3                ; /Arg3 = 00000003
    00401241  |. 6A 02          PUSH 2                ; |Arg2 = 00000002
    00401243  |. 6A 01          PUSH 1                ; |Arg1 = 00000001
    00401245  |. E8 05000000    CALL bo1.0040124F     ; \bo1.0040124F
    0040124A  |. 83C4 0C        ADD ESP,0C
    0040124D  |. 5D             POP EBP
    0040124E  \. C3             RETN
      
    0040124F  /$ 55             PUSH EBP
    00401250  |. 8BEC           MOV EBP,ESP
    00401252  |. 51             PUSH ECX
    00401253  |. 59             POP ECX
    00401254  |. 5D             POP EBP
    00401255  \.
    C3             RETN

    ΑΝΑΛΥΣΗ:
    Αναγκαστικά εδώ θα μιλάμε πια με 16δικές διευθύσεις μνήμης εφόσων μιλαμε για ένα αληθινό παράδειγμα!

    Στις διευνύσεις από 0040123Cέως 0040124Eείναι η συνάρτηση main().
    Στις διευνύσεις από 0040124Fέως 00401255 είναι η συνάρτηση function1().

    Η εντολή:
    0040123C  /. 55             PUSH EBP

    Φυλαέι τον παλιό stack pointer στο STACK

    Η εντολή:
     0040123D  |. 8BEC           MOV EBP,ESP

    Αντιγράφει τον παλιό stackpointer στον καταχωρητή EBP.
    Από εδώ και πέρα θα αναφερόμαστε στις μεταβλητές της συνάρτησης function1 με βάση τον EBP.
    Οι 2 παραπάνω εντολές ονομάζονται "ProcedurePrologue".

    Τώρα το stack θα έχει:

     [ebp]
      STACK
      256  |   [ebp]       |
      ...  .................
      
    (ESP=256)
     

    Η εντολές:

    0040123F  |. 6A 03          PUSH 3 ; /Arg3 = 00000003
    00401241  |. 6A 02          PUSH 2 ; |Arg2 = 00000002
    00401243  |.
    6A 01          PUSH 1 ; |Arg1 = 00000001
      

    Εδώ μπαίνουνε στο stack οι παράμετροι της συνάρτησης function1.

    Μετά τις παραπάνω εντολές το stack θα είναι

      STACK
      256  |   [ebp]       |
      252  |     3         |
      248  |     2         |
      244  |     1         |
      ...  .................
      (ESP=244)
     

    Η εντολή:

      00401245  |. E8 05000000 CALL bo1.0040124F ; \bo1.0040124F
     

    Καλεί τη συνάρτηση στη διεύθυνση 0040124F. bo1 είναι το όνομα του προγράμματος μου.

    Τώρα
    το stack θα έχει:

      STACK
      256  |   [ebp]       |
      252  |     3         |
      248  |     2         |
      244  |     1         |
      240  |  0040124A     | <- the return address when the function1 ends.
      ...  .................
      
    (ESP=240)
     
    Ας ακολουθήσουμε την εκτέλεση,... δηλαδή ας πάμε στη διεύθυνση 0040124F (της function1):

    0040124F  /$ 55             PUSH EBP
    00401250  |. 8BEC           MOV EBP,ESP
     Χμμ... εδώ έχουμε πάλι την "ProcedurePrologue" της συνάρτησης (μην ξεχνάτε αυτή πρέπει να υπάρχει ηια κάθε function... ευτυχώς). Ο καταχωρητής EBP δείχνει στο stackframe της συνάρτησης main(). Αυτή η τιμή πρέπει να φυλαχθεί, οπότε ο EBP γίνεται PUSH στο stack. Μετά, το περιεσόμενα του του ESP μεταφέρετε στον EBP. Αυτό σημαίνει οτι οι παράμετροι της συνάρτησης θα καταχωρηθούν στο stack σαν offset (με σημείο αναφοράς) τον EBP. Επίσης «ελευθυερώνεται» και ο ESP να κάνει χρησιμοποιηθεί για τις επόμενες εντολές.


    Τώρα το stack θα έχει:


      STACK
       256  |   [ebp]       |
       252  |     3         |
       248  |     2         |
       244  |     1         |
       240  |  0040124A     | <- Η return address όταν η function τελειώνει.
       236  |  <main’s EBP> | <- Ο ESP=EBP έχει την return address.
       ...  .................
       (ESP=236)

     

    Η εντολές:

      00401253  |. 59             POP ECX
      00401254  |. 5D             POP EBP
     

    Μετά τα 2 τελευταία POPs το STACK θα είναι:

      STACK
      256  |   [ebp]       |
      252  |     3         |
      248  |     2         |
      244  |     1         |
      ...  .................
      (ESP=244)
    Τελειώνοντας
     
      00401255  \. C3             RETN
     

    Η συνάρτηση τελειώνει και επιστρέφει στη 0040124A (θυμάστε τον ορισμό της εντολής RET?)


      0040124A  |. 83C4 0C        ADD ESP,0C
     
    Αφού επιστρέψει η συνάρτηση, γίνεται μια πράξη: Πρόσθεση.
    Προσθέτουμε 12 (ή 0C δεκαεξαδικό) στο stackpointer (ESP). Εφόσων βάλαμε 3 παραμέτρους στο stack (4 byteso καθένας). Αυξάνοντας τον ESP στην πραγματικότητα μειώνουμε το stack (αν θυμόσαστε από πριν γεμίζουμε το stack από τις υψηλές προς χαμηλές διευθύνσεις μνήμης) δηλαδή ESP = 244 + 12 = 256).


      STACK
      256  |   [ebp]       |
      ...  .................
      (ESP=256)
     
    Έτσι ο ESP έχει πάλι την τιμή που είχε πριν την κλήση της συνάρτησης.

    Ελπίζω να πήρατε μια αρχική γεύση για την χρήση του stack, των καταχωρητών και της γλώσσας assembly.

    Αυτές οι γνώσεις μπορούν να χρησιμοποιηθούν (οπως είπαμε στην αρχή) και για την κατανόηση...  πονηρών πραγμάτων όπως ενός bufferoverflow. Για παράδειγμα, τι θα λέγατε εάν μπορούσαμε να γράψουμε επάνω στο stack (στη διεύθυνση 240 στο παράδειγμα μας). Δηλαδή να γράφαμε επάνω στον EIP μια διεύθυνση... δική μας.. χε χε χε.

    Τεσπα... αυτά σε επόμενο... tut.

    Επειδή έχω γράψει κι άλλα tutorials στη ζωή μου μπορείται να είστε όσο αγενείς γουστάρετε στην κριτική σας. Έτσι κι αλλιώς δεν δίνω δεκάρα για το τι λέτε!!!!
    Big Smile χε χε λέμε και καμία ....@@.... να περάσει η ώρα!! 


     

    Λοιπον Σοβαρα τώρα. . .

    Σας προτέινω να δοκιμάστε το χαζό προγραμματάκι μου σε C και να κάνετε τα δικά σας tests. Test, Check, Review, Test, Check, Review etc etc.!!
    Θεωρώ οτι κάθε προγραμματιστής που θέλει να αποκαλείτε προγραμματιστής και όχι κωδικογράφος.... οφείλει να γνωρίζει τα παραπάνω ως στοιχειώδη γνώση!!

    Happy Programming !!

    Αναφορές:
    [1] BUFFER OVERFLOWS DEMYSTIFIED by
    [email protected]
    [2] C Function Call Conventions and the Stack (UMBC CMSC 313, Computer Organization & Assembly Language, Spring 2002, Section 0101)
    [3] The Assembly Language Book for IBM PC by Peter Norton (ISBN 960-209-028-6)
    [4] Analysis of Buffer Overflow Attacks from
    http://www.windowsecurity.com/articles/Analysis_of_Buffer_Overflow_Attacks.html
    [5] 8088 8086 Programming and Applications for IBM PC/XT & Compatibles by Nikos Nasoufis


     

     


    Nothing to declare...
  •  03-06-2007, 03:39 32508 σε απάντηση της 32481

    Απ: Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

    πολύ γ@μ&τοοο!!!!!

    (
    κατέχω το νούμερο 3,4 και 5..
    και κατέχω και βασηκές γνώσεις C++...
    δηλαδή τώρα εγώ που δεν το κατάλαβα.. ειμαι κοδικογράφος? w*t&f....)

    CC Calculator -newest version: 1.6-

    Επισκευθήτε το blog μου :)

  •  03-06-2007, 13:43 32523 σε απάντηση της 32481

    Απ: Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

    Thiseas:


    Για κάθε πρόγραμμα που καλείται στη μνήμη για να εκτελεστεί, το λειτουργικό σύστημα του δημιουργεί 3 βασικά μέρη (Segments):
    -Code Segment
    -Data Segment (το γνωστό BSS)
    -Stack Segment

    Αν δεν κάνω λάθος, αυτό είναι ιδιαίτερο χαρακτηριστικό της οικογένειας επεξεργαστών 80x86 της Intel. Ο Ζ80 της Ziloc (? θυμάμαι καλά το όνομα;) και η σειρά 68000 της Motorola μέχρι και τον 68050 που είχα διαβάσει το intraction set, δεν λειτουργούν έτσι. Είναι όλα χύμα. Και στους 80x86 αυτο ισχύει μόνο για τα .exe προγράμματα. Tα .com προγράμματα έχουν μόνο ένα segment, το Code Segment. Στις αρχές του '90 έχει γίνει λόγος, για τις εταιρείες που υποστήριζαν την IBM PC compatible αρχιτεκτονική, ότι είχαν κάνει λάθος που είχαν υποστηρίξει τους επεξεργαστές της Intel, μιας και ένα segment μπορούσε να "δει" μέχρι 64ΚΒ μνήμης. Αυτό θα αποτελούσε πρόβλημα για την εξέλιξη της πληροφορικής, σε αντίθεση με άλλους επεξεργαστές PowerPC, Motorola που δεν είχαν τέτοιους περιορισμούς.

    Αυτού του είδους η επίθεση μάλλον είναι αδύνατο να γίνει πλέον, στα Windows XP SP2 και νεότερα λειτουργικά για τους client, και Windows 2003 SP1 και νεότερα λειτουργικά για τους server. Αυτό έχει να κάνει με την υποστήριξη του DEP (Data Execution Prevention) στο core των Windows. Οι νεότεροι επεξεργαστές της Intel και της AMD έχουν ενσωματωμένο αυτό το χαρακτηριστικό και μέσα στον επεξεργαστή για να μην χρειάζεται να υπάρχει η software λειτουργία στο λειτουργικό σύστημα που όσο και να είναι, καθυστερεί τον υπολογιστή. Αυτός είναι και ο κύριος λόγος που πολλά προγράμματα DOS έπαψαν να λειτουργούν όταν βγήκε το SP2 των Windows XP.

     

    George J.


    George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας
    w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias
    dotNETZone.gr News
  •  03-06-2007, 17:21 32529 σε απάντηση της 32523

    Απ: Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

    George J. Capnias:
    Αν δεν κάνω λάθος, αυτό είναι ιδιαίτερο χαρακτηριστικό της οικογένειας επεξεργαστών 80x86 της Intel. Ο Ζ80 της Ziloc (? θυμάμαι καλά το όνομα;) και η σειρά 68000 της Motorola μέχρι και τον 68050 που είχα διαβάσει το intraction set, δεν λειτουργούν έτσι. Είναι όλα χύμα. Και στους 80x86 αυτο ισχύει μόνο για τα .exe προγράμματα. Tα .com προγράμματα έχουν μόνο ένα segment, το Code Segment.

    Ακριβώς Γιώργο!
    Συγκεκριμένα, το αναφέρω κι εγώ και στη 7η παράγραφο του κειμένου μου.... Wink

    Thiseas:
    Πρώτα απ’ όλα θα ήθελα να σημειώσω πως οτιδήποτε θα πω θα αναφέρομαι για την οικογένεια επεξεργαστών xx86.

    Όσο αφορά στα .COM πάλι έχεις δίκιο: Το Code και το Data Sement είναι ένα και δεν μπορεί να ξεπερνάει τα 64kb.

    Όλα ξεκίνησαν από τον τρόπο που χαρακτηρίζει την μνήμη ο επεξεργαστής της Intel (από τον 8088):
    Π.χ. στο 8088 ίσχυε:
    Όλα τα bytes στην μνήμη έχουν μια ετικέτα που έχει έναν αύξοντα αριθμό, ξεκινώντας από το 0h (το 0 δεκαεξαδικό). Αλλά κάθε τέτοιος αριθμός έχει μόνο 4 ψηφία μήκος. Από 0000 έως FFFF.
    Το δεκαεξαδικό FFFF είναι το δεκαδικό 65535. Δηλαδή 65536 θέσεις ή 1024 * 64 = 65536 ή 64kbytes!
    Αυτό είναι και ένα τμήμα της μνήμης!
    Δηλαδή!!!
    Δεν μπορούμε να δουλέψουμε με μνήμη, παραπάνω από ένα τμήμα?
    Πάνω από 64kb....Αν αυτό το ανέφερες σε έναν προγραμματιστή στις αρχές ης δεκετίας του 80 θα σε έπαιρνε στο ψιλό!! Μα όταν πρωτοβγήκε το DOS δεν χρειαζότανε τόσο "τεράστια" μνήμη...Cool

    Αν θέλουμε όμως μπορούμε να χρησιμποιήσουμε πάνω από 1 segment?
    Η απάντηση είναι οτι το κάνουμε με το λεγόμενο segmentation:
    Αυτή η τεχνική χρησιμοποιεί 2 segments για να αριθμήσει την μνήμη:
    segment : offset
    Το ένα για να δείξει τον αριθμό του segment και το άλλο για να δείξει τον σχετικό αριθμό της διεύθυνσης της μνήμης μέσα στο τρέχον segment. Για αυτό και οι αυτές οι διευθύνσεις σναφέρονται και σαν σχετικές διεθυύνσεις.

    Η παραπάνω κατάσταση είναι πράγματι πονοκέφαλος για όλους: Σχεδιαστές του Επεξεργαστή, Προγραμματιστές Συστήματος, Προγραμματιστές Εφαρμογών, .... εκτός από τους χρήστες που δεν τους νοιάζει!!!Cool

    Θα θυμάστε (οι πιο παλαιοί) τα memory models : Small, Medium, Large, Huge με τους μεταγλωτιστές της C (Borland + Microsoft)...
    Αν θυμαμαι καλά η Borland σου πρόσφερε κι το μοντέλο : tiny....
    Τεσπα.... μεγάλη κουβέντα ανοίγουμε... και πολύ ενδιαφέρουσα!!

    George J. Capnias:
    Αυτού του είδους η επίθεση μάλλον είναι αδύνατο να γίνει πλέον, στα Windows XP SP2 και νεότερα λειτουργικά για τους client, και Windows 2003 SP1 και νεότερα λειτουργικά για τους server. Αυτό έχει να κάνει με την υποστήριξη του DEP (Data Execution Prevention) στο core των Windows.

    Σε ποιά επίθεση αναφέρεσε? Μάλλον για code injection (http://support.microsoft.com/kb/875352), αλλά δεν μπορώ να το συνδέσω με την segmentation.... ?Indifferent

    To segmentation αντιμετωπίστηκε από το ίδιο το λειτουργικό από την έκδοση των Windows NT 3.1 και μετά (http://en.wikipedia.org/wiki/Windows_NT)

     

     


    Nothing to declare...
  •  03-06-2007, 20:34 32534 σε απάντηση της 32529

    Απ: Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

    Thiseas:
    Σε ποιά επίθεση αναφέρεσε? Μάλλον για code injection (http://support.microsoft.com/kb/875352), αλλά δεν μπορώ να το συνδέσω με την segmentation.... ?Indifferent

    Σίγουρα κάτι "έφαγα" στην απάντησή μου - ναι, για στο code injection αναφέρομαι.

     

    George J.


    George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας
    w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias
    dotNETZone.gr News
  •  03-06-2007, 21:13 32542 σε απάντηση της 32534

    Απ: Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

    Για αρχή, να πω οτι οκ, ωραίο το "άρθρο" που έγραψες/μετέφρασες/αντέγραψες (όποιο και να ισχύει δεν παίζει και τόσο σημασία εν τέλει).
    Δεν μπορώ όμως να καταλάβω πως ακριβώς ταιριάζει με την όλη φιλοσοφία του φορουμ εδώ. Εννοώ δεν μας ενδιαφέρει και πολύ όλη αυτή η ιστορία περι buffer overflow, heap corruption, κλπ κλπ, καθώς έτσι κι αλλοιώς το .Net δεν υποφέρει απο τέτοια προβλήματα. Άλλωστε ήταν κι είναι ένα απο τα κύρια πλεονεκτήματα του managed κώδικα. Επίσης, κάποιος mod να μεταφέρει το post κάπου αλλού, καθώς δεν έχει και καμιά σχέση για Design & Architecture. Ας πάει στον unmanaged code στο C++ section ή κάτι τέτοιο.
    Παναγιώτης Κεφαλίδης

    "Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

    Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.
  •  03-06-2007, 21:41 32547 σε απάντηση της 32542

    Απ: Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

    Panagiotis Kefalidis:
    Για αρχή, να πω οτι οκ, ωραίο το "άρθρο" που έγραψες/μετέφρασες/αντέγραψες (όποιο και να ισχύει δεν παίζει και τόσο σημασία εν τέλει).
    Δεν μπορώ όμως να καταλάβω πως ακριβώς ταιριάζει με την όλη φιλοσοφία του φορουμ εδώ. Εννοώ δεν μας ενδιαφέρει και πολύ όλη αυτή η ιστορία περι buffer overflow, heap corruption, κλπ κλπ, καθώς έτσι κι αλλοιώς το .Net δεν υποφέρει απο τέτοια προβλήματα. Άλλωστε ήταν κι είναι ένα απο τα κύρια πλεονεκτήματα του managed κώδικα. Επίσης, κάποιος mod να μεταφέρει το post κάπου αλλού, καθώς δεν έχει και καμιά σχέση για Design & Architecture. Ας πάει στον unmanaged code στο C++ section ή κάτι τέτοιο.

    Παναγιώτη, ο Thiseas ανέφερε στην αρχή οτι ο ίδιος έχει συγγράψει το άρθρο και το έχει δημοσιεύσει ήδη σε δύο τουλάχιστον κοινότητες. Αρα δεν υπάρχει λόγος να αμφισβητείται αυτό, εκτός αν έχεις κάποια αναφορά που να τεκμηριώνει οτι δεν αποτελεί τον πρωτότυπο συγγραφέα. Θα παρακαλέσω να είμαστε πολύ προσεκτικοί με τις αναφορές μας αυτές γιατί είναι πιθανό να θίγουν τους χρήστες που πραγματοποιούν την αρχική δημοσίευση. Θα πρότεινα να ανακαλέσεις τη συγκεκριμένη σου πρόταση αν δεν έχεις κάποια επιπρόσθετη σχετική πληροφορία που να την τεκμηριώνει.

    Οσον αφορά στην πρόταση για μετακίνηση: Προβληματίστηκα και εγώ με το πού θα έπρεπε να ανήκει ένα τέτοιο άρθρο. Ομως, στην ευρύτερη έννοια "Design and Architecture" ίσως (τραβηγμένα βέβαια, αν σκεφτούμε οτι αρχικός σκοπός του forum ήταν το software design - architecture) ίσως ταιριάζει. Ηταν ένα πολύ εκτεταμένο και λεπτομερές άρθρο για να περάσει στα "Λοιπά θέματα". Ομως, εδώ ο admin - Γιώργος έχει τον τελευταίο λόγο.

    Σχετικά με το αν μας ενδιαφέρει η όλη ιστορία ή οχι: Ισως κάποιους τους ενδιαφέρει. Και πάλι θα πετούσα το μπαλάκι στον Γιώργο για να αποφανθεί αν το θέμα είναι σχετικό με την κοινότητα λιγότερο ή περισσότερο.


    Σωτήρης Φιλιππίδης

    DotSee Web Services

    View Sotiris Filippidis's profile on LinkedIn

    DotNetNuke them!
  •  03-06-2007, 22:28 32551 σε απάντηση της 32547

    Απ: Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

    Επειδή πιστεύω ότι το θέμα του code security είναι κάτι που πρέπει να απασχολεί κάθε προγραμματιστή, και δεν πρέπει να αποτελεί ένα από τα τελευταία θέματα πριν κλείσει ένα project, αλλά να λαμβάνεται σοβαρά από την πρώτη στιγμή ενός project, δημιουργήθηκε μια καινούργια περιοχή, κάτω από το Σχεδιασμό & Αρχιτεκτονική που θα μπορεί να φιλοξενεί αυτά τα θέματα.

     

    George J.


    George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας
    w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias
    dotNETZone.gr News
  •  04-06-2007, 10:33 32570 σε απάντηση της 32542

    Απ: Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

    Panagiotis Kefalidis:
    Για αρχή, να πω οτι οκ, ωραίο το "άρθρο" που έγραψες/μετέφρασες/αντέγραψες (όποιο και να ισχύει δεν παίζει και τόσο σημασία εν τέλει).

    Ισχύουνε τα δύο πρώτα, δηλαδή πρώτα το έγραψα στα αγγλικά και μετά το μετέφρασα...
    http://www.hellboundhackers.org/articles/497-How-a-program-works.html
    και
    http://www.secfreaks.gr/showthread.php?t=2024

    Τώρα για το αν το.... αντέγραψα τι να πω?
    Διάβασες την βιβλιογραφία που παραθέτω... ??
    Αν "δεν παίζει και τόσο σημασία" η αντιγραφή για σένα είναι άποψη σου (σεβαστή μεν, απαράδεκτη δε!!), για μένα παίζει πολύ σημασία!!
    Θα ήθελα πολυ όμως,... να το αιτιολογήσεις και όχι να το πετάς έτσι!
    Περιμένω...

    Panagiotis Kefalidis:
    Δεν μπορώ όμως να καταλάβω πως ακριβώς ταιριάζει με την όλη φιλοσοφία του φορουμ εδώ.

    Αν ταιριάζει με την φιλοσοφία του forum?
    Ποιά είναι η φιλοσοφία του forum  εδω?
    Είχα την εντύπωση πως κάπου διάβασα.... "Η Δύναμη των Ελλήνων Developers" (see baneraki)!!!
    Μιας και μιλάμε για Developers αυτά τα στοιχειώδη θέματα security (ειτε σε .net είτε σε .nes-cafe), κατά την ταπεινή μου άποψη, πρέπει τουλάχιστον να αναφέρονται. Αν κάποιους δεν τους ενδιαφέρουν... τι να πω....?
    Αναφέρετο δικαίωμα τους,... όπως κι εμένα όμως!! να τα αναφέρω...

    Panagiotis Kefalidis:

    Εννοώ δεν μας ενδιαφέρει και πολύ όλη αυτή η ιστορία περι buffer overflow, heap corruption, κλπ κλπ, καθώς έτσι κι αλλοιώς το .Net δεν υποφέρει απο τέτοια προβλήματα. Άλλωστε ήταν κι είναι ένα απο τα κύρια πλεονεκτήματα του managed κώδικα. Επίσης, κάποιος mod να μεταφέρει το post κάπου αλλού, καθώς δεν έχει και καμιά σχέση για Design & Architecture.

    Τώρα όσο για τον managed code και Buffer Overrun.... κλπ κλπ.... πόσο σίγουρος είσαι οτι δεν υποφέρει από τέτοια προβλήματα?
    Το διάβασες κάπου ή το δοκίμασες μόνος σου?
    Και δεν αναφέρομαι μόνο στο buffer overflo (που έχεις δίκιο!)... αναφέρομαι γενικά στο Secure Code.
    Άλλοστε στο forum βλέπω section και για unmanaged code! Μήπως κάνω λάθος?

    Εγώ οτι έχω γράψει παραπάνω τα έχω δοκιμάσει μόνος μου. Μπορείς να μου παραθέσεις κάτι που έχεις κάνει o ίδιος και να αιτιιολογεί οτι το .NET δεν πάσχει από τέτοια προβληματα?
    Αν ναι... το σέβομαι!
    Προσωπικά δεν το έχω δοκιμάσει.... ακόμα!!
    Θα σου απαντήσω σύντομα γι αυτό, διότι, πράγματι, έθιξες ένα πολύ ενδιαφέρον θέμα.



    Nothing to declare...
  •  04-06-2007, 11:37 32576 σε απάντηση της 32570

    Απ: Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

    Υπέροχα, είμαι ενθουσιασμένος και περιμένω την συνέχεια.
    Το θέμα είναι πολύ ενδιαφέρον και σίγουρα ενδιαφέρει και τους .net developers (εκτός αν κάποιος πιστεύει ότι το δικό του software δεν χρησιμοποιεί stack Stick out tongue) Περιμένω να δω τι λύσεις έχουν δοθεί σε "χαμηλό" επίπεδο καθώς και το τι μπορούμε/χρειάζεται να κάνουμε εμείς.
  •  04-06-2007, 11:46 32578 σε απάντηση της 32576

    Απ: Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

    Προς τους συναδέλφους Thiseas και Παναγιώτη Κ.:

    Χωρίς να θέλω να απευθυνθώ ξεχωριστά σε κάποιον από τους δυο σας, θα παρακαλούσα να μην εξελιχθεί αυτο το thread σε αντιπαράθεση επί προσωπικού. Εχω ήδη δημοσιεύσει μήνυμα σχολιασμού σε αυτό το thread σχετικά με το αρχικό μήνυμα του Παναγιώτη και οποιαδήποτε απάντηση υπάρχει επ'αυτού θα παρακαλούσα να απευθύνεται σε μένα (με την ιδιότητα του moderator) και όχι προς το φίλο Thiseas. Κατά τα άλλα, ας επικεντρωθούμε στο πολύ ενδιαφέρον ουσιαστικό θέμα του thread. 


    Σωτήρης Φιλιππίδης

    DotSee Web Services

    View Sotiris Filippidis's profile on LinkedIn

    DotNetNuke them!
  •  04-06-2007, 12:50 32585 σε απάντηση της 32578

    Απ: Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

    Όπως και να έχει δεν έχω σκοπό να ανακαλέσω κάτι. Εαν δεν ισχύει κάτι απο αυτά (ο ίδιος ο Thiseas, ανέφερε τι ισχύει) θα μπορούσε απλά να το αγνοήσει. Εξακολουθώ να πιστεύω όμως ότι δεν κολλάει τόσο θεωρία και σε τόσο χαμηλό επίπεδο περι "ασφάλειας" κλπ, γιατί απλούστα δεν υπάρχει καμία απολύτος εφαρμογή σε .Net. Οι ίδιοι το ξέρετε ότι δεν ισχύει τίποτα απο όλα αυτά τα θεωρητικά στο .Net. Σαν εγκυκλοπεδικές γνώσεις, ναι, ίσως είναι καλό να υπάρχει αν και πάλι έχω κάποιες ενστάσεις. Δεν αμφισβητώ ούτε τον κόπο του, ούτε την προσπάθεια του να μας "ανοίξει" τα μάτια στο κομμάτι του security, αλλά δεν πιστεύω ότι το κάνει και με τον καλύτερο τρόπο. Θα προτιμούσα να δω ενα άρθρο για Obfuscation σε .Net και το Security namespace, απο το να διαβάζω για low level Buffer overflows κλπ.

    Κλείνοντας να σου πω Σωτήρη, ότι θα σταματήσω να κάνω συζητήσεις και reply σε θέματα του Thiseas, γιατί απο ότι φαίνεται όλα αυτά πειράζουν κάποιους και δεν έχω ούτε την διάθεση, ούτε την όρεξη να γίνω κακός και δακτυλοδεικτούμενος. Απ΄ ότι φαίνεται στην προσπάθεια να κρατήσουμε τους τόνους χαμηλά, ορισμένες φορές υπερβάλλουμε.

    Παναγιώτης Κεφαλίδης

    "Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

    Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.
  •  04-06-2007, 13:08 32586 σε απάντηση της 32585

    Απ: Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

    Επιθυμώ να είναι το τελευταίο μήνυμα που αφορά αυτό το ζήτημα σε αυτό το thread για να μην κουράζουμε και τους υπόλοιπους συναδέλφους. Αν και χρόνια τώρα γνωριζόμαστε μέσω της κοινότητας, Παναγιώτη, θα μου επιτρέψεις να πω οτι πρώτη φορά αντιμετωπίζω τέτοια αντίδραση από εσένα. Οταν χαρακτηρίζουμε ένα χρήστη υπονοώντας οτι "αντέγραψε" ενώ ο ίδιος έχει αναφέρει οτι είναι πρωτότυπος συγγραφέας του υλικού, είμαστε "φάουλ" (αν δεν έχουμε κάτι να το τεκμηριώνει). Οπως λοιπόν θα έκανα και για κάθε χρήστη του DNZ, έτσι λέω και σε σένα οτι είναι λανθασμένη αντιμετώπιση. Με την τοποθέτηση αυτή ολοκληρώνω και θα επιθυμούσα (οπως και εσύ από ο,τι γράφεις) να τερματιστούν οι αναφορές σε οτιδήποτε άλλο πλην του θέματος του thread.

    Για το θέμα της σχετικότητας η μη του θέματος με τη γενικότερη φιλοσοφία του DNZ, απεφάνθη ο Γιώργος και δεν έχω άλλο σχόλιο.

    Για το θέμα των "χαμηλών τόνων" η ομάδα διαχείρισης του DNZ πράττει όπως θεωρεί καλύτερο, και το αν η πρακτική αυτή δεν βρίσκει σύμφωνους τους πάντες είναι φυσιολογικό. Ομως, εφόσον έχει επιλέξει αυτή την αντιμετώπιση των θεμάτων, αυτή ακολουθεί το DNZ εν γένει.

    Θα παρακαλέσω το συνάδελφο Thiseas και τον Παναγιώτη, σε περίπτωση που επιθυμούν να απαντήσουν σε κάτι από όσα ελέχθησαν εδώ, να μην το κάνουν πλέον σε αυτό το thread, αλλά να μου στείλουν προσωπικό μήνυμα, για να διατηρήσουμε την αρχική συζήτηση στο thread. 


    Σωτήρης Φιλιππίδης

    DotSee Web Services

    View Sotiris Filippidis's profile on LinkedIn

    DotNetNuke them!
  •  04-06-2007, 13:09 32587 σε απάντηση της 32576

    Απ: Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

    agmarios:
    Υπέροχα, είμαι ενθουσιασμένος και περιμένω την συνέχεια.
    Το θέμα είναι πολύ ενδιαφέρον και σίγουρα ενδιαφέρει και τους .net developers (εκτός αν κάποιος πιστεύει ότι το δικό του software δεν χρησιμοποιεί stack Stick out tongue) Περιμένω να δω τι λύσεις έχουν δοθεί σε "χαμηλό" επίπεδο καθώς και το τι μπορούμε/χρειάζεται να κάνουμε εμείς.


    Μια που το έφερε η κουβέντα (για το πόσο το .net) είναι vulnerable σε buffer oeverflow attachs το παρακάτω άρθρο, δίνει μια εικόνα:
    http://www.microsoft.com/technet/security/bulletin/ms02-026.mspx

    EDITED:
    Μια πιο μελετημένη αναζλήτηση θα μας δώσει τα παρακάτω
    http://securitydot.net/search/exploits/vulnerabilities/articles/buffer+overflow+asp.net.html

    Δηστυχώς δεν ακόμα προσωπική άποψη επι του θέματος.Sad
    Θα το κοιτάξω όταν και εφόσων βρώ επιτέλους λίγο free time.


    Nothing to declare...
  •  04-06-2007, 18:22 32593 σε απάντηση της 32587

    Απ: Πως λειτουργεί ένα πρόγραμμα ή τα πρώτα βήματα για την κατανόηση του Buffer Overflow.

    Οι δημοσιεύσεις που παραθέτεις δεν λένε πουθενά ότι μπορεί κάποιος να γράψει κώδικα σε .NET ο οποίος να είναι ευάλωτος σε buffer overflow. Όσο για το δεύτερο post, η συγκεκριμμένη αναζήτηση επιστρέφει τα άρθρα που περιέχουν οποιαδήποτε από τις λέξεις κλειδιά. Αν βάλεις AND θα πάρεις πάλι το πρώτο vulnerability που αναφέρεις, το οποίο όμως αφορά ένα από τα components του ASP.NET, όχι τον κώδικα που μπορείς να γράψεις εσύ ο ίδιος. Άσε που 5 χρόνια μετά, ακόμα δεν έχουν βρει exploit για το συγκεκριμένο bug, ενώ αντιμετωπίστηκε ήδη στο .NET 1.0 Service Pack 2.

    Ακόμα και αν αλλάξεις την αναζήτηση σε .NET AND buffer, αυτό είναι το μόνο vulnerability που θα βρεις, και δεν έχει σχέση με το managed memory management. Ίσως να μπορείς να πετύχεις buffer overflow στο .NET περιλαμβάνοντας unmanaged blocks τα οποία χειρίζονται με κακό τρόπο τη μνήμη, αλλά σε αυτή την περίπτωση παρακάμπτεις ενσυνείδητα κάθε προστασία που σου παρέχει το .NET.

    Συνεπώς, το buffer overflow φαίνεται να είναι μάλλον αδιάφορο για το .NET.


    Παναγιώτης Καναβός, Freelancer
    Twitter: http://www.twitter.com/pkanavos
Σελίδα 1 από 2 (18 εγγραφές)   1 2 >
Προβολή Τροφοδοσίας RSS με μορφή XML
Με χρήση του Community Server (Commercial Edition), από την Telligent Systems