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

 

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

Win 7 Stack protection feature...?

Îåêßíçóå áðü ôï ìÝëïò Thiseas. Τελευταία δημοσίευση από το μέλος Παναγιώτης Καναβός στις 27-08-2010, 14:50. Υπάρχουν 18 απαντήσεις.
Σελίδα 1 από 2 (19 εγγραφές)   1 2 >
Ταξινόμηση Δημοσιεύσεων: Προηγούμενο Επόμενο
  •  24-08-2010, 09:20 59718

    Win 7 Stack protection feature...?

    Γιατί άραγε δεν δουλεύει το stack protection (_cookie_vars_ κλπ) στα Win 7 όταν το χρησιμοποιούμενο buffer είναι μικρότερο ή ίσο από 4 bytes...?
    Μην μου απαντήσετε "Διότι με 4 bytes δεν μπορείς να περάσεις shellcode!" διότι θα σας πω οτι με 4 bytes μπορείς κάλιστα να κάνεις ανακατεύθνυση της RET address και αυτό είναι πολλές φορές αρκετό!Devil

    When you 've got a hammer everything starts to look like a nail...
  •  24-08-2010, 10:33 59720 σε απάντηση της 59718

    Απ: Win 7 Stack protection feature...?

    Πιθανόν διότι θα πρέπει στον ίδιο code να βρείς το Address καθώς απο τα Vista και μετά και ειδικά απο τα 7/2008 και μετά, το Memory allocation είναι scrambled απο τον Kernel. Οπότε δεν ξέρω έαν θα σου φτάνουν 4 bytes για να τα κάνεις όλα αυτά. Ακόμα κι εάν βρεις απο πριν που είναι, δεν ξέρεις εάν θα είναι το ίδιο την στιγμή που θα πας να το αλλάξεις.
    Παναγιώτης Κεφαλίδης

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

    Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.
  •  24-08-2010, 11:19 59721 σε απάντηση της 59720

    Απ: Win 7 Stack protection feature...?

    Panagiotis Kefalidis:
    Πιθανόν διότι θα πρέπει στον ίδιο code να βρείς το Address καθώς απο τα Vista και μετά και ειδικά απο τα 7/2008 και μετά, το Memory allocation είναι scrambled απο τον Kernel...


    Σωστά, αλλά η /GS flag του compiler δημιουργεί την περίφημη protection cookie variable στο buffer μόνο αν χρησιμοποιήσεις πάνω από 4 bytes μεταβλητές στην function που θα καλέσεις.
    Για να γίνω πιο συγκεκριμένος, εννοώ το εξής:
    Διαβάζοντας αυτό το πολύ ενδιαφέρον άρθρο και κάνοντας και κάποια δικά μου παραδείγματα διαπίστωσα οτι αυτό συμβαίνει όχι μόνο στα Vista που λέει το άρθρο αλλά και στα 7. Πιο συγκεκριμένα, αναφέρει:
    ...the GS option does not always protect vulnerable code. We identified one additional restriction not mentioned in the Microsoft documentation: Functions are only protected if they have a buffer of 5 bytes or more....

    Απλά δεν βρίσκω κάποιο προφανή λόγο να υπάρχει αυτό το limitation. Αν είναι limitation τελικά. Και λέω μήπως έχει ακούσει-ξέρει-ψάξει κάποιος τίποτα παραπάνω...

    When you 've got a hammer everything starts to look like a nail...
  •  25-08-2010, 09:20 59732 σε απάντηση της 59721

    Απ: Win 7 Stack protection feature...?

    Thiseas:
    Διαβάζοντας αυτό το πολύ ενδιαφέρον άρθρο και κάνοντας και κάποια δικά μου παραδείγματα διαπίστωσα οτι αυτό συμβαίνει όχι μόνο στα Vista που λέει το άρθρο αλλά και στα 7. Πιο συγκεκριμένα, αναφέρει:
    ...the GS option does not always protect vulnerable code. We identified one additional restriction not mentioned in the Microsoft documentation: Functions are only protected if they have a buffer of 5 bytes or more....

    Έχεις το σχετικό link μέσα στην Symantec που οδηγεί στο άρθρο;

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

    Δεν μπόρεσα να βρω reference μέσα από την Symantec σε αυτό το paper, παρά μόνο μέσα από Google, που δείχνει να υπάρχουν links σε αυτό από "ιδιαίτερα" sites. 

    Μου κάνει εντύπωση, ότι στο paper, μιλάνε μόνο για Visual Studio 2003-Visual Studio 2005, ενώ για ανάπτυξη σε Vista προτείνεται Visual Studio 2008...

     

    George J.


    George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας
    w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias
    dotNETZone.gr News
  •  25-08-2010, 11:37 59736 σε απάντηση της 59732

    Απ: Win 7 Stack protection feature...?


    George J. Capnias:

    Έχεις το σχετικό link μέσα στην Symantec που οδηγεί στο άρθρο;

    [EDITED]

    Κάτι βρήκα.... πρέπει να βγήκε μέσα στο 2007... Το παραπάνω paper της Symantec αναφέρεται σε αυτό το link το οποίο συνοψίζει τα ευρήματα του τμήματος Advanced Research Group της ίδιας εταιρίας.

    [/EDITED]

    George J. Capnias:
    Μου κάνει εντύπωση, ότι στο paper, μιλάνε μόνο για Visual Studio 2003-Visual Studio 2005, ενώ για ανάπτυξη σε Vista προτείνεται Visual Studio 2008...

    Προσωπικά το δοκίμασα με VS 2008 σε windows 7 Ultimate 64bit και παρουσιάζει την ίδια συμπεριφορά. Παρήγαγα 2 executables με /GS το ένα με μια function με δηλωμένο ένα char array of 4 και το αλλο με 12. Μετά σύγκρινα (με την χρηση του dumpbin /ALL) τα δύο εκτλέσιμα. Φαίνεται καθαρά οτι οτι ένα χρησιμοποιεί το __cookie__Var και το άλλο όχι.

    Η microsoft πάντως (σε αντίθεση από αυτό που ισχυρίζεται το παραπάνω κείμενο - οτι είναι undocumented*) το αναφέρει εδώ. Συνοπτικά λέει:

    A buffer overrun security check is performed on a GS buffer. A GS buffer can be one of these:

    • An array that is larger than 4 bytes, has more than two elements, and has an element type that is not a pointer type.

    • A data structure whose size is more than 8 bytes and contains no pointers.

    • A buffer allocated by using the _alloca function.

    • Any class or structure that contains a GS buffer.


  • Εκτός κι αν αυτό που λεέι η MS είναι μεταγενέστερο της δημοσίευσης της Symentec.

    Το ερώτημα όμως που εχω όμως παραμένει... Γιατί όχι security check στα 4 bytes...?

    Μπορεί να φανεί χαζό αλλά μήπως κάτι "παίζει" στην περίπτωση <=4 bytes και φοβούνται μην το χαλάσουνε... μην χάσουνε κάποιο backward compatibility ή κάτι τέτοιο...?

  • When you 've got a hammer everything starts to look like a nail...
  •  25-08-2010, 12:51 59738 σε απάντηση της 59736

    Απ: Win 7 Stack protection feature...?

    Thiseas:

  • Εκτός κι αν αυτό που λεέι η MS είναι μεταγενέστερο της δημοσίευσης της Symentec.

    Το ερώτημα όμως που εχω όμως παραμένει... Γιατί όχι security check στα 4 bytes...?

    Μπορεί να φανεί χαζό αλλά μήπως κάτι "παίζει" στην περίπτωση <=4 bytes και φοβούνται μην το χαλάσουνε... μην χάσουνε κάποιο backward compatibility ή κάτι τέτοιο...?
  • Είναι σημαντικό να ξέρουμε τη χρονική σειρά - γιατί είναι πολυ πιθανό να έχει γίνει fix, και στο fix να περιγράφει και το γιατί και το πως υπάρχει η συμπεριφορά...

     

    George J.


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

    Απ: Win 7 Stack protection feature...?

    Καταρχήν, να λύσουμε μία παρανόηση. Το GS δεν έχει καμμία σχέση με την έκδοση του λειτουργικού. Έχει να κάνει με την έκδοση του compiler που χρησιμοποιήθηκε για να φτιαχτεί ένα binary. Δεύτερον, η χρήση του GS αυξάνει τόσο το μέγεθος του κώδικα όσο και το χρόνο εκτέλεσης. Προφανώς πρέπει να γίνουν κάποιοι συμβιβασμοί από τον compiler στο πού και πότε μπορεί να χρησιμοποιηθεί.  Αυτό εξηγείται ήδη από το 2002, στην περιγραφή του GS. "The most important factor behind keeping the performance impact from being an issue is that only functions that are vulnerable to attack are targeted. Currently, the definition of a vulnerable function is one that allocates a type of string buffer on the stack. A string buffer that is considered vulnerable allocates more than four bytes of storage and where each element of the buffer is either one or two bytes. Small buffers are unlikely to be the target of an attack, and limiting the number of functions that have security checks limits the code growth. Most executables will not even notice an increase in size when building with /GS."

    Δεν είναι ότι "κάτι παίζει και φοβούνται να το χαλάσουνε". Απλά τα διάφορα optimizations του compiler μπορούν ακόμα και να εξαφανίσουνε buffers μικρότερους από 4 bytes, δηλαδή ... μικρότερα από ένα WORD. Ο compiler μπορεί άνετα να χρησιμοποιήσει κάποιο register αντί για το stack για να αποθηκεύσει τον buffer και έτσι να μη χρησιμοποιήσει καθόλου. 

    Όσον αφορά τα περί undocumented συμπεριφοράς, πρόκειται μάλλον για κακή περιγραφή του τί θεωρούσανε vulnerable buffers το 2002. Ή μάλλον, θεωρούσαν ότι δεν χρειάζεται να βάλλουν τους κανόνες αυτούς στην περιγραφή του /GS switch. Έτσι κι αλλιώς, το user guide του compiler δεν είναι και το καταλληλότερο σημείο να περιγράψεις πως δουλεύει εσωτερικά, ούτε ενδιαφέρει τους χρήστες του compiler. Αν πας όμως, π.χ. στο Security Research and Defense blog, όπου συζητάνε πως δουλεύουν τα διάφορα features όπως το GS, θα βρεις και posts που περιγράφουν τα heuristics που χρησιμοποιούνται, π.χ. περιορισμούς και βελτιώσεις στο Visual Studio 2010 . Δες επίσης και αυτό το post του Michael Howard που περιγράφει το #pragma strict_gs_check το οποίο προστέθηκε στο Visual Studio 2005 SP1 για να επιτρέψει τη χρήση των cookies σε όλες τις περιπτώσεις (ακόμα και για buffers μικρότερους από 4 bytes).

    Παναγιώτης Καναβός, Freelancer
    Twitter: http://www.twitter.com/pkanavos
  •  26-08-2010, 10:52 59753 σε απάντηση της 59743

    Απ: Win 7 Stack protection feature...?

    Παναγιώτης Καναβός:
    Καταρχήν, να λύσουμε μία παρανόηση. Το GS δεν έχει καμμία σχέση με την έκδοση του λειτουργικού.

    Παναγιώτη δεν καταλαβαίνω πως μπορεί κάποιος να θεωρήσει (διαβάζοντας τα παραπάνω) πως το /GS εξαρτάται το λειτουργικό...
    Οι αναφορές στο λειτουργικό (κατά την δική μου οπτική γωνία, πάντα) ήταν και ξεκάθαρες και προφανείς.
    Αν νόμισες οτι εννούσα αυτό, τότε μάλλον δεν έχω εκφράσει κάτι καλά...
    Ας τα πάρουμε τα πράματα λοιπόν από την αρχή:

    Έχω τα παρακάτω πρόγραμματα:

    #include "stdio.h"
    void vulnerable(char *input){
    char foo[4];
    strcpy(foo, input);
    }
    int main(int argc, char* argv[])
    {
    vulnerable(argv[1]);
    return 0;
    }


    #include "stdio.h"
    void vulnerable(char *input){
    char foo[12];
    strcpy(foo, input);
    }
    int main(int argc, char* argv[])
    {
    vulnerable(argv[1]);
    return 0;
    }

    Περίπτωση 1: Buffer 4 bytes και Compilation με /GS αλλά και /Od (disable optimizations)

    C:\Work>cl testGS.c /GS /Od
    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
    Copyright (C) Microsoft Corporation.  All rights reserved.

    testGS.c
    Microsoft (R) Incremental Linker Version 9.00.21022.08
    Copyright (C) Microsoft Corporation.  All rights reserved.

    /out:testGS.exe
    testGS.obj

    C:\Work>dumpbin testGS.obj /symbols
    Microsoft (R) COFF/PE Dumper Version 9.00.21022.08
    Copyright (C) Microsoft Corporation.  All rights reserved.


    Dump of file testGS.obj

    File Type: COFF OBJECT

    COFF SYMBOL TABLE
    000 0083521E ABS    notype       Static       | @comp.id
    001 00000001 ABS    notype       Static       | @feat.00
    002 00000000 SECT1  notype       Static       | .drectve
        Section length   2F, #relocs    0, #linenums    0, checksum        0
    004 00000000 SECT2  notype       Static       | .debug$S
        Section length   64, #relocs    0, #linenums    0, checksum        0
    006 00000000 SECT3  notype       Static       | .text
        Section length   36, #relocs    2, #linenums    0, checksum C9620A42
    008 00000000 SECT3  notype ()    External     | _vulnerable
    009 00000000 UNDEF  notype ()    External     | _strcpy
    00A 00000020 SECT3  notype ()    External     | _main

    String Table Size = 0x10 bytes

      Summary

              64 .debug$S
              2F .drectve
              36 .text

    C:\Work>dir testGS.*
     Volume in drive C has no label.
     Volume Serial Number is 3058-A226

     Directory of C:\Work

    26/08/2010  10:03 πμ               162 testGS.c
    26/08/2010  10:15 πμ            37,376 testGS.exe
    26/08/2010  10:15 πμ               575 testGS.obj
                   3 File(s)         38,113 bytes



    Περίπτωση 2: Buffer 12 bytes και Compilation με /GS αλλά και /Od (disable optimizations)

    C:\Work2>cl testGS.c /GS /Od
    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
    Copyright (C) Microsoft Corporation.  All rights reserved.

    testGS.c
    Microsoft (R) Incremental Linker Version 9.00.21022.08
    Copyright (C) Microsoft Corporation.  All rights reserved.

    /out:testGS.exe
    testGS.obj

    C:\Work2>dumpbin testGS.obj /symbols
    Microsoft (R) COFF/PE Dumper Version 9.00.21022.08
    Copyright (C) Microsoft Corporation.  All rights reserved.


    Dump of file testGS.obj

    File Type: COFF OBJECT

    COFF SYMBOL TABLE
    000 0083521E ABS    notype       Static       | @comp.id
    001 00000001 ABS    notype       Static       | @feat.00
    002 00000000 SECT1  notype       Static       | .drectve
        Section length   2F, #relocs    0, #linenums    0, checksum        0
    004 00000000 SECT2  notype       Static       | .debug$S
        Section length   64, #relocs    0, #linenums    0, checksum        0
    006 00000000 SECT3  notype       Static       | .text
        Section length   46, #relocs    4, #linenums    0, checksum A78D99CF
    008 00000000 SECT3  notype ()    External     | _vulnerable
    009 00000000 UNDEF  notype ()    External     | _strcpy
    00A 00000000 UNDEF  notype       External     | ___security_cookie
    00B 00000000 UNDEF  notype ()    External     | @__security_check_cookie@4
    00C 00000030 SECT3  notype ()    External     | _main

    String Table Size = 0x3E bytes

      Summary

              64 .debug$S
              2F .drectve
              46 .text

    C:\Work2>dir testGS.*
     Volume in drive C has no label.
     Volume Serial Number is 3058-A226

     Directory of C:\Work2

    26/08/2010  10:10 πμ               163 testGS.c
    26/08/2010  10:17 πμ            37,376 testGS.exe
    26/08/2010  10:17 πμ               693 testGS.obj
                   3 File(s)         38,232 bytes



    To binary αρχείο (obj) έχει διαφορετικό μέγεθος αλλά όχι το executable. Αυτό είναι καθαρά feature - το αναφέρω απλά ως επισήμανση. Το dumpbin δείχνει καθαρά την διαφορά και μάλιστα χωρίς καθόλου optimization (/Od).

    Παναγιώτης Καναβός:
    Δεν είναι ότι "κάτι παίζει και φοβούνται να το χαλάσουνε". Απλά τα διάφορα optimizations του compiler μπορούν ακόμα και να εξαφανίσουνε buffers μικρότερους από 4 bytes, δηλαδή ... μικρότερα από ένα WORD. Ο compiler μπορεί άνετα να χρησιμοποιήσει κάποιο register αντί για το stack για να αποθηκεύσει τον buffer και έτσι να μη χρησιμοποιήσει καθόλου.
    Αν τώρα, ακόμα και με το /Od ο compiler παίρνει την πρωτοβουλία να κάνει τα... δικά του, αντικαθιστώντας το stack με ένα register, OK!... είναι εξίσου ενοχλητικό (για μένα).

    Παναγιώτης Καναβός:
    Προφανώς πρέπει να γίνουν κάποιοι συμβιβασμοί από τον compiler στο πού και πότε μπορεί να χρησιμοποιηθεί.  Αυτό εξηγείται ήδη από το 2002, στην περιγραφή του GS. "The most important factor behind keeping the performance impact from being an issue is that only functions that are vulnerable to attack are targeted...

    Νομίζω οτι η function vulnerable στο παράδειγμα μας με τα 4 bytes (που μάλιστα κάνει και χρήση της strcpy) είναι το... definition του vulnerability. Wink

    Επίσης, ΤΗΧ για τις υπόλοιπες πληροφορίες κάποιες από αυτές δεν τις είχα διαβάσει, οι οποίες όμως δεν λύνουν την δική μου απορία βάση της οποίας έβαλα αυτό το post. Απλά περιγράφουν ΤΙ κάνει ο compiler και όχι Γιατι το κάνει, ή καλύτερα Γιατι δεν το κάνει...



    When you 've got a hammer everything starts to look like a nail...
  •  26-08-2010, 14:19 59760 σε απάντηση της 59753

    Απ: Win 7 Stack protection feature...?

    Σέ όλα σου τα post ως τώρα αναφέρεις ότι αυτή η συμπεριφορά εμφανίζεται στα Windows 7 και στα Vista, ενώ δεν έχει καμμία σημασία το λειτουργικό.

    Αν θέλεις να μάθεις γιατί τα μικρά buffer θεωρούνται χαμηλού ρίσκου θα πρέπει να ρωτήσεις τους ανθρώπους που το έγραψαν αυτό στα blogs. Όσο για το τί εντολές δημιουργεί  ο compiler, μπορείς να το δεις με ένα disassembler ή από το του  debugger, όχι από το dumpbin. Τέλος, έχει σημασία αν κάνεις debug ή release compile. Μόνο το debug compile εξασφαλίζει ότι δεν θα γίνει κανένα optimization ή rewriting. Αν κάνεις compile τον κώδικα σου σε release mode θα δεις ότι το function vulnerable γίνεται Inlined μέσα στη main, οπότε δεν δημιουργείται καν call γι αυτό.

    Όσον αφορά το μέγεθος, δεν αφορά το μέγεθος του binary αλλά της μνήμης που χρησιμοποιεί το πρόγραμμα, τόσο ως μέγεθος όσο και ως allocations. Το cookie ουσιαστικά διπλασιάζει τη μνήμη που χρησιμοποιείται στο stack για μεταβλητές μεγέθους 4 bytes. Χονδρικά, μικρά buffers βρίσκεις σε μικρά functions τα οποία χρησιμοποιούνται πολύ συχνά. Το συνολικό κόστος του cookie σε αυτή την περίπτωση μπορεί να αποδειχθεί σημαντικό.

    Έτσι κι αλλιώς μιλάμε για tradeoffs. Για να είναι χρήσιμο το GS πρέπει να έχει μικρή επίδαση στο performance τόσο της εφαρμογής όσο και του compilation, αλλιώς θα το απενεργοποιούσαν όλοι. Η χρήση εκτεταμμένης ανάλυσης θα αύξανε σημαντικά το χρόνο compilation και θα ήταν εντελώς απαράδεκτη για ένα feature το οποίο παρέχει βασική ασφάλεια. Για τη δουλειά αυτή υπάρχουν άλλα εργαλεία (static και dynamic analyzers). 

    Παναγιώτης Καναβός, Freelancer
    Twitter: http://www.twitter.com/pkanavos
  •  26-08-2010, 15:25 59762 σε απάντηση της 59760

    Απ: Win 7 Stack protection feature...?

    Μάλλον δεν καταλαβαινόμαστε...
    Δεν με αφορά (αυτή τη στιγμή) το disassembly (άσε που το dump δίνει επίσης opcodes αν θες που πολλοί αρέσκονται σε αυτά, αφού τα έχουν συνηθίσει!!), άσε που είναι και off-topic. Τι να το κάνω αν δω τον assembly κώδικα (inlined  ή μη, debuged ή released)? Και να τον δω (που το έχω κάνει δλδ - ουκ ολίγες)... so what?
    θα δω πάλι τι κάνει ο compiler.... που το έχω δει. Το ερώτημα είναι αν έχει καμιά εξήγηση κάποιος στο Why?
    Είμαι σίγουρος οτι πολλοί εδώ έχουν πιο πολλά να πουν από το "Πήγαινε ρώτα αυτούς που το έγραψαν...". Σηζήτηση είπαμε να κάνουμε και όχι να καταδικάσουμε τον compiler.... (λέμε τώρα!)

    Χμ..., καλά...

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

    thnx

    When you 've got a hammer everything starts to look like a nail...
  •  26-08-2010, 16:03 59764 σε απάντηση της 59762

    Απ: Win 7 Stack protection feature...?

    http://msdn.microsoft.com/en-us/library/aa290051.aspx#vctchcompilersecuritychecksindepthanchor8

    Performance Impact

    A performance tradeoff for using security checks in an application must be made. The Visual C++ compiler team focused on making the performance degradation small. In most cases, the performance should not degrade more than 2 percent. In fact, experience has shown that most applications, including high-performance server applications, have not noticed any performance impact.

    The most important factor behind keeping the performance impact from being an issue is that only functions that are vulnerable to attack are targeted. Currently, the definition of a vulnerable function is one that allocates a type of string buffer on the stack. A string buffer that is considered vulnerable allocates more than four bytes of storage and where each element of the buffer is either one or two bytes. Small buffers are unlikely to be the target of an attack, and limiting the number of functions that have security checks limits the code growth. Most executables will not even notice an increase in size when building with /GS.

     

    George J.


    George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας
    w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias
    dotNETZone.gr News
  •  26-08-2010, 16:38 59765 σε απάντηση της 59718

    Απ: Win 7 Stack protection feature...?

    Καλησπέρα σε όλους.

    Η φιλοσοφία της C/C++ συνοψίζεται ως:
    δύναμη και εμπιστοσύνη στον προγραμματιστή.

    Πλέον είναι σαφές ότι αυτό δεν μπορεί να συνεχιστεί ...
    οποτε αφού πρέπει να ζήσουμε με όλον αυτόν τον κώδικα,
     θα πρέπει να βρούμε κάποιες ισορροπίες.

    Η ισορροπία έρχεται ακριβώς από την μελέτη του προγραμματιστή και την καταγραφή των λαθών του (heuristics).

    Συνήθως όταν δηλώνει έναν buffer με 4 elements δεν χρησιμοποιεί άλλον buffer με iteration για να τον γεμίσει... οποτε αφού και το κόστος του check ισορροπεί την κατάσταση, τότε ας το αφήσουμε έξω.

    Palladinos Nick
    Software Engineer
    -----------------------
    The limits of my language mean the limits of my world. (Ludwig Wittgenstein)
  •  26-08-2010, 17:38 59767 σε απάντηση της 59764

    Απ: Win 7 Stack protection feature...?

    George J. Capnias:
    ...Small buffers are unlikely to be the target of an attack,...

    Αυτό, πράγματι είναι μια εξήγηση... πιθανοθεωρητική (ή για άλλους αρκετά "απλοποιημένη") προσέγγιση βέβαια, αλλά είναι μια εξήγηση που μαζί με την "αρχή της ισσοροπίας" που πολύ σωστά (κατά τη γνώμη μου) τόνισε ο Palladin αιτιολογεί σε ένα βαθμό την αρχική ερώτηση.

    Thnx 4 your time gentlemen!


    When you 've got a hammer everything starts to look like a nail...
  •  26-08-2010, 18:16 59768 σε απάντηση της 59767

    Απ: Win 7 Stack protection feature...?

    Καλά, αυτό που γράφει ο Γιώργος το έχουμε πει ήδη εδώ και 4 posts! Μάλλον θα πρέπει να αναρωτηθείς "γιατί θεωρείται ότι οι μικροί buffer δεν είναι και τόσο επιρρεπείς σε επίθεση?" 

    Η πλάκα είναι ότι έδωσες την απάντηση με την αρχική σου ερώτηση, όταν μίλησες για Shellcode. Στο "Smashing the stack for fun and profit" αναφέρει, πέρα από το πως να χρησιμοποιήσεις ένα buffer overflow για να προσθέσεις shell code, και τους λόγους που αυτό είναι δύσκολο για μικρά buffers:
    "There will be times when the buffer you are trying to overflow is so small that either the shellcode wont fit into it, and it will overwrite the return address with instructions instead of the address of our code, or the number of NOPs you can pad the front of the string with is so small that the chances of guessing their address is minuscule. ". 

    Πιο απλά, ακόμα κι αν πειράξεις το return address, αυτό πρέπει να δείχνει στο δικό σου assembly code και όχι σε κάποια άσχετη θέση μνήμης. Πρέπει να ξέρεις αυτή τη απόλυτη διεύθυνση, η οποία θα αλλάζει σε κάθε εκτέλεση του κώδικα, για να μπορέσεις να την γράψεις πάνω από το κανονικό return address. Το μόνο "σίγουρο" address που έχεις όμως σημείο είναι το ίδιο το buffer, οπότε θα πρέπει να υπολογίσεις τη θέση του κώδικα σου σε σχέση με την αρχή του buffer. Αυτό όμως σημαίνει ότι πρέπει να υπολογίσεις ακριβώς το μέγεθος του κώδικα σου σε bytes ΚΑΙ την τελική του θέση μέσα στο stack, κάτι σχεδόν αδύνατο και τόσο εύκολο. Γι αυτό βάζεις και κάμποσα NOP πριν τον κώδικα σου, έτσι ώστε να μεγαλώσει ο αριθμός των return address που μπορείς να χρησιμοποιήσεις.

    Το πρόβλημα τώρα είναι ότι αν το assembly σου είναι πολύ μεγάλο θα γράψει όχι μόνο πάνω από το return address αλλά και πάνω από διευθύνσεις που δεν έχουν γίνει allocate ακόμα στο πρόγραμμα σου. Αποτέλεσμα: crash. Αν το buffer είναι αρκετά μεγάλο όλος ο κώδικας σου θα χωρέσει μέσα στον χώρο που του έχει ήδη ανατεθεί στο stack. Αν όμως είναι πολύ μικρός, ο κώδικας σου σχεδόν σίγουρα θα ξεφύγει από το buffer και μπορεί να διαγράψει και άλλα, άσχετα πράγματα. 

    Συνεπώς, είναι πολύ δυσκολότερο να υπολογίσεις το σωστό return address όταν χρησιμοποιείς μικρά buffers.

    Άσε που ο compiler αλλάζει τυχαία τη σειρά των παραμέτρων στο stack, με αποτέλεσμα συνήθως να μην ξέρεις ΠΟΥ ακριβώς θα πρέπει να γράψεις το return address.



    Παναγιώτης Καναβός, Freelancer
    Twitter: http://www.twitter.com/pkanavos
  •  27-08-2010, 09:56 59772 σε απάντηση της 59768

    Απ: Win 7 Stack protection feature...?

    Το άρθρο του "πολύ" Aleph είναι λιγάκι ξεπερασμένο. Σου προτείνω μάλιστα την original δημοσίευση στο phrack η οποία έγινε 1996.Αν και ήταν ο πρώτος που σύνδεσε όλα αυτά σε ένα κείμενο, δεν ήταν ο πρώτος που ανακάλυψε το buffer overflow το οποίο "έπαιζε" από τα μέσα του '70. Τεσπα... φιλοσοφούμε τώρα - ntax δεν είναι + κακό!
    Βέβαια το Smashing The Stack in 2010 ή το Smashing The Modern Stack For Fun And Profit και πάρα πολλά άλλα είναι λίγο πιο... σύχγρονα.

    Πάντως για να λυθούν οι περισσότεροι προβληματισμοί σου (όπως το πως θα αντιμετωπίσεις το τυχαίο starting address τόσο του προγράμματος σου όσο και των βασικών DLLs του λειτουργικού - kernel32 etc) σου προτείνω το The Shellcoder's Handbook: Discovering and Exploiting Security Holes. Λύνει αρκετές απορίες σε θέματα που πολλοί θεωρούν "σχεδόν αδύνατο" να υλοποιηθούν.

    Επίσης, έχεις κάνει μια παραδοχή για το σκεπτικό μου που δεν είναι απόλυτα σωστή: Χρησιμοποιώντας την RET address μπορεί να *μην* θέλω να κάνω redirection σε άλλο πρόγραμμα, δικό μου ούτε σε κάποιο shellcode δωσμένο από command line (που λέει ο λόγος). Μπορεί να θέλω να κάνω απλά ένα jump σε μια address το ίδιου του προγράμματος που τρέχει για να ξεπεράσω (ας πούμε) ένα έλεγχο για serial number. Θα μου πεις τώρα "αυτό μπορείς να το κάνεις με ένα patch του executable". Σωστό κι αυτό! Αλλά δεν είναι κακό να λέμε όλες τις... εναλλακτικές.

    Υπάρχουν πολλά ακόμα. Κάθε πράμα, όμως, στον καιρό του.
    Έτσι κι αλλιώς το θέμα δεν είναι το "Αν" αλλά το "Πότε"... Stick out tongue



    When you 've got a hammer everything starts to look like a nail...
Σελίδα 1 από 2 (19 εγγραφές)   1 2 >
Προβολή Τροφοδοσίας RSS με μορφή XML
Με χρήση του Community Server (Commercial Edition), από την Telligent Systems