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

---

Nothing to declare...

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

---

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

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

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.

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 τελικά. Και λέω μήπως έχει ακούσει-ξέρει-ψάξει κάποιος τίποτα παραπάνω...

---

Nothing to declare...

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

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

---

Nothing to declare...

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

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Παναγιώτης Καναβός:

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

Παναγιώτης Καναβός:

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

---

Nothing to declare...

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

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

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

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

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

thnx

---

Nothing to declare...

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

---

Palladinos Nick
Software Engineer
-----------------------
The limits of my language mean the limits of my world. (Ludwig Wittgenstein)

George J. Capnias:

...Small buffers are unlikely to be the target of an attack,...

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

Thnx 4 your time gentlemen!

---

Nothing to declare...

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

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

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

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

---

Nothing to declare...