Code Security

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

Παναγιώτης Καναβός — Fri, 27 Aug 2010 21:50:27 GMT

Σωστό αυτό, μάλιστα είναι και αυτό που έχουν πει από την πρώτη στιγμή: Το /GS είναι ένα πρώτο γρήγορο μέτρο προστασίας για char buffer overruns, όχι μία ολοκληρωμένη αντιμετώπιση των buffer overruns. Άσε που, επίσης από την αρχή, λένε ότι δεν πρέπει να βασίζεται κανείς σε αυτό αλλά να χρησιμοποιεί σωστή μεθοδολογία. Δεν είναι τυχαίο που το λένε "canary trap" και όχι "αντιασφυξιογόνο μάσκα".

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

PALLADIN — Fri, 27 Aug 2010 21:14:53 GMT

Εκτος από το μέγεθος του buffer, μια ενδιαφέρουσα λεπτομέρεια είναι to "where each element of the buffer is either one or two bytes".

Νομίζω ότι φαίνεται ξεκάθαρα ότι κάνουν target μονο char/wchar buffers (και οχι int[], long[] ktlp) και αυτό αντικατοπτρίζει το στατιστικό γεγονός ότι οι

περισσότεροι προγραμματιστές τα χρησιμοποιούν με αντίστοιχα "επικίνδυνα" functions (strcpy, memcpy ktlp)

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

Thiseas — Fri, 27 Aug 2010 20:59:20 GMT

Παναγιώτης Καναβός:
Το θέμα είναι, οι δικοί σου προβληματισμοί λύθηκαν? Γιατί θεωρούν ότι τα μικρά buffer είναι χαμηλού κινδύνου? Καθώς και γιατί υπάρχουν συμβιβασμοί ? Εγώ δεν είχα καμμία αμφιβολλία ότι ένα απλό προστατευτικό μέτρο όπως το /GS θα έχει πολλούς περιορισμούς και συμβιβασμούς υπέρ της ταχύτητας.

Χμ, σωστή ερώτηση.
Οι συμβιβασμοί λόγω performance είναι κατανοητοί, αν και εγώ θα ήθελα να μπορούσα να έχω την επιλογή να αναλάβω το "κόστος" του perfomance penalty για οποιαδήποτε function ή buffer όσο μικρό κι αν είναι.
Αυτό που έγινε clear σε εμένα είναι οτι οι μηχανικοί της MS δεν προσπάθησαν να εξαλείψουν το πρόβλημα αλλά προσπάθησαν να ελαχιστοποιήσουν την πιθανότητα εμφάνισης του, με βάση κάποιους κανόνες που ισχύουν και ακολουθούνται στα περσσότερα προγράμματα από τους περισσότερους προγραμματιστές, επηρεάζοντας επίσης όσο το δυνατόν λιγότερο το performance.
Κατά συνέπεια, την έκφραση "Small buffers are unlikely to be the target of an attack..." δεν την ερμηνεύω οτι στα μικρά buffers έχουμε μικρή δυνατότητα να κάνουμε κάτι κακό αλλά οτι:
Τα μικρά buffers έχουν μικρή πιθανότητα να χρησιμοποιηθούν σε πολύ μεγάλα προγράμματα. Ή αλλιώς, τα μικρά buffers έχουν μικρή συχνότητα εμφάνισης σε μεγάλα προγράματα. Τόσο μικρή που δεν αξίζει τον κόπο να δημιουργούν την __cooklie__ variable (με όλα τα συναφή) σε σχέση με αυτό που θα κερδίσουμε...

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

Παναγιώτης Καναβός — Fri, 27 Aug 2010 18:36:00 GMT

Το θέμα είναι, οι δικοί σου προβληματισμοί λύθηκαν? Γιατί θεωρούν ότι τα μικρά buffer είναι χαμηλού κινδύνου? Καθώς και γιατί υπάρχουν συμβιβασμοί ? Εγώ δεν είχα καμμία αμφιβολλία ότι ένα απλό προστατευτικό μέτρο όπως το /GS θα έχει πολλούς περιορισμούς και συμβιβασμούς υπέρ της ταχύτητας.

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

Thiseas — Fri, 27 Aug 2010 16:56:30 GMT

Το άρθρο του "πολύ" 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". Σωστό κι αυτό! Αλλά δεν είναι κακό να λέμε όλες τις... εναλλακτικές.

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

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

Παναγιώτης Καναβός — Fri, 27 Aug 2010 01:16:49 GMT

Καλά, αυτό που γράφει ο Γιώργος το έχουμε πει ήδη εδώ και 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.

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

Thiseas — Fri, 27 Aug 2010 00:38:40 GMT

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

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

Thnx 4 your time gentlemen!

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

PALLADIN — Thu, 26 Aug 2010 23:38:16 GMT

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

Η φιλοσοφία της C/C++ συνοψίζεται ως:

δύναμη και εμπιστοσύνη στον προγραμματιστή.

Πλέον είναι σαφές ότι αυτό δεν μπορεί να συνεχιστεί ...

οποτε αφού πρέπει να ζήσουμε με όλον αυτόν τον κώδικα,

θα πρέπει να βρούμε κάποιες ισορροπίες.

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

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

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

George J. Capnias — Thu, 26 Aug 2010 23:03:17 GMT

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.

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

Thiseas — Thu, 26 Aug 2010 22:25:18 GMT

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

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

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

thnx

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

Παναγιώτης Καναβός — Thu, 26 Aug 2010 21:19:42 GMT

Σέ όλα σου τα 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).

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

Thiseas — Thu, 26 Aug 2010 17:52:18 GMT

Παναγιώτης Καναβός:
Καταρχήν, να λύσουμε μία παρανόηση. Το 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.

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

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

Παναγιώτης Καναβός — Thu, 26 Aug 2010 00:31:33 GMT

Καταρχήν, να λύσουμε μία παρανόηση. Το 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).

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

George J. Capnias — Wed, 25 Aug 2010 19:51:06 GMT

Thiseas:

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

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

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

Είναι σημαντικό να ξέρουμε τη χρονική σειρά - γιατί είναι πολυ πιθανό να έχει γίνει fix, και στο fix να περιγράφει και το γιατί και το πως υπάρχει η συμπεριφορά...

George J.

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

Thiseas — Wed, 25 Aug 2010 18:37:36 GMT

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 ή κάτι τέτοιο...?