Security Summer School

User Tools

Site Tools

session:11

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
session:11 [2020/07/17 15:07]
Radu-Nicolae NICOLAU (78289) 		session:11 [2020/07/19 12:49] (current)
Line 1: Line 1:
-= 0x0A: Information Leaks+====== 0x0A: Information Leaks ======
  
-== Slides+===== Slides =====
  
-== Resources+===== Resources =====
  
-[[https://security.cs.pub.ro/summer-school/res/slides/10-information-leaks.pdf|Session 9 slides]]+[[https://security.cs.pub.ro/summer-school/res/slides/10-information-leaks.pdf|Session 10 slides]]
  
-[[https://security.cs.pub.ro/summer-school/res/arc/10-information-leaks-skel.zip|Session's tutorials and challenges archive]]+[[https://github.com/hexcellents/sss-exploit/tree/master/sessions|Session's tutorials and challenges archive]]
  
-[[https://security.cs.pub.ro/summer-school/res/arc/10-information-leaks-full.zip|Session's solutions]] +===== Stack Protection (Canaries) =====
- +
- +
-== Stack Protection (Canaries)+
  
 The name comes from canaries (birds) that were used by mining workers when entering mines and were affected by any deadly gases such as methane before humans were. In our case, stack canaries are used to check if a buffer overflow of a stack variable resulted in overriding the return address. The mechanism is based on a (sometimes random) value that is placed on each function's stack, just above the return address, as the following picture shows. The value is checked in the function's epilogue before calling ''ret'', and if the values do not match the execution is halted. Since the stack grows from higher memory addresses to lower ones, any buffer overflow targeting the return address will also have to overwrite the canary with the right value. The name comes from canaries (birds) that were used by mining workers when entering mines and were affected by any deadly gases such as methane before humans were. In our case, stack canaries are used to check if a buffer overflow of a stack variable resulted in overriding the return address. The mechanism is based on a (sometimes random) value that is placed on each function's stack, just above the return address, as the following picture shows. The value is checked in the function's epilogue before calling ''ret'', and if the values do not match the execution is halted. Since the stack grows from higher memory addresses to lower ones, any buffer overflow targeting the return address will also have to overwrite the canary with the right value.
Line 32: Line 29:
 The 3 well known implementations of stack protections are: StackGuard, ProPolice, and StackShield. The 3 well known implementations of stack protections are: StackGuard, ProPolice, and StackShield.
  
-=== StackGuard+==== StackGuard ====
  
 The [[https://www.usenix.org/legacy/publications/library/proceedings/sec98/full_papers/cowan/cowan_html/cowan.html|initial implementation]] proposed by Crispin Cowan et al. from Immunix Inc., only protected the return address by pushing the canary value on the stack right after it (at lower adresses in memory, just like in the picture). Follow-up versions also protected the saved registers and base pointer. StackGuard is implemented as a patch for the GCC compiler that modifies the GCC's code generation routines for function prologues and epilogues. The prologue will push the random value onto the stack, while the epilogue will contain a short value checking code. The [[https://www.usenix.org/legacy/publications/library/proceedings/sec98/full_papers/cowan/cowan_html/cowan.html|initial implementation]] proposed by Crispin Cowan et al. from Immunix Inc., only protected the return address by pushing the canary value on the stack right after it (at lower adresses in memory, just like in the picture). Follow-up versions also protected the saved registers and base pointer. StackGuard is implemented as a patch for the GCC compiler that modifies the GCC's code generation routines for function prologues and epilogues. The prologue will push the random value onto the stack, while the epilogue will contain a short value checking code.
Line 40: Line 37:
 </note> </note>
  
-=== StackShield+==== StackShield ====
  
 The most notable feature of StackShield, compared to other implementations, is the //Global Return Stack//. This is a separate memory structure where return addresses are pushed as function are being called. When the function returns, the correct value is copied back to the application stack, thus overriding any malicious value. //Ret Range Check// is another feature that allows stack smashing detection by copying return addresses from the application stack to a memory region with no write permission - the value is compared to the current return address in function's epilogue. The most notable feature of StackShield, compared to other implementations, is the //Global Return Stack//. This is a separate memory structure where return addresses are pushed as function are being called. When the function returns, the correct value is copied back to the application stack, thus overriding any malicious value. //Ret Range Check// is another feature that allows stack smashing detection by copying return addresses from the application stack to a memory region with no write permission - the value is compared to the current return address in function's epilogue.
  
-=== ProPolice+==== ProPolice ====
  
 ProPolice, proposed by IBM, started from an implementation similar to StackGuard, but evolved and introduced new features. It is currently the method used by GCC when the ''%%--fstack-protector%%'' compilation flag is used. The ProPolice mechanism will reorder local variables based on their types. The following picture shows where each variable should be placed on the stack based on it's type such that different attacks become impossible. ProPolice, proposed by IBM, started from an implementation similar to StackGuard, but evolved and introduced new features. It is currently the method used by GCC when the ''%%--fstack-protector%%'' compilation flag is used. The ProPolice mechanism will reorder local variables based on their types. The following picture shows where each variable should be placed on the stack based on it's type such that different attacks become impossible.
Line 117: Line 114:
 </code> </code>
  
-=== Defeating Canaries+==== Defeating Canaries ====
  
 This [[http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-silberman/bh-us-04-silberman-paper.pdf|white paper]] covers different attack vectors and the capabilities of protecting against these offered by the 3 implementations that we previously presented. As the paper presents, there are multiple target values that an attacker might want to modify during exploitation, by overflowing buffers stored in different regions of the process.  This [[http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-silberman/bh-us-04-silberman-paper.pdf|white paper]] covers different attack vectors and the capabilities of protecting against these offered by the 3 implementations that we previously presented. As the paper presents, there are multiple target values that an attacker might want to modify during exploitation, by overflowing buffers stored in different regions of the process. 
Line 136: Line 133:
  
  
-== Format String Exploits+===== Format String Exploits =====
  
 <note warning> <note warning>
Line 161: Line 158:
 } }
 </code> </code>
-=== Format functions+==== Format functions ====
 A number of format functions are defined in the ANSI C definition. There are some basic format string functions on which more complex functions are based on, some of which are not part of the standard but are widely available. A number of format functions are defined in the ANSI C definition. There are some basic format string functions on which more complex functions are based on, some of which are not part of the standard but are widely available.
 Real family members: Real family members:
Line 173: Line 170:
  * vsnprintf — prints to a string with length checking from a va_arg structure  * vsnprintf — prints to a string with length checking from a va_arg structure
  
-===== Relatives:+== Relatives: ==
  * setproctitle — set argv[]  * setproctitle — set argv[]
  * syslog — output to the syslog facility  * syslog — output to the syslog facility
Line 220: Line 217:
 The code above works, because '\x25' is replaced at compile time with '%', since 0x25 (37) is the ASCII value for the percent character. The code above works, because '\x25' is replaced at compile time with '%', since 0x25 (37) is the ASCII value for the percent character.
  
-=== The stack and its role at format strings+==== The stack and its role at format strings ====
 The behaviour of the format function is controlled by the format string. The function retrieves the parameters requested by the format string from the stack. The behaviour of the format function is controlled by the format string. The function retrieves the parameters requested by the format string from the stack.
 <code C> <code C>
Line 232: Line 229:
 should be evaluated. The string "%%" has a special meaning, it is used to print the escape character '%' itself. Every other parameter relates to data, which is located on the stack. should be evaluated. The string "%%" has a special meaning, it is used to print the escape character '%' itself. Every other parameter relates to data, which is located on the stack.
  
-=== What do we control?+==== What do we control? ====
 Through supplying the format string we are able to control the behaviour of the format function. We now have to examine what exactly we are able to control, and how to use this control to extend this partial control over Through supplying the format string we are able to control the behaviour of the format function. We now have to examine what exactly we are able to control, and how to use this control to extend this partial control over
 the process to full control of the execution flow. the process to full control of the execution flow.
-=== Crash of the program+==== Crash of the program ====
 By utilizing format strings we can easily trigger some invalid pointer access by just supplying a format string like: By utilizing format strings we can easily trigger some invalid pointer access by just supplying a format string like:
 <code C> <code C>
Line 242: Line 239:
 Because '%s' displays memory from an address that is supplied on the stack, where a lot of other data is stored, too, our chances are high to read from an illegal address, which is not mapped. Also most format function Because '%s' displays memory from an address that is supplied on the stack, where a lot of other data is stored, too, our chances are high to read from an illegal address, which is not mapped. Also most format function
 implementations offer the '%n' parameter, which can be used to write to the addresses on the stack. If that is done a few times, it should reliably produce a crash, too. implementations offer the '%n' parameter, which can be used to write to the addresses on the stack. If that is done a few times, it should reliably produce a crash, too.
-=== Viewing the stack+==== Viewing the stack ====
 We can show some parts of the stack memory by using a format string like this: We can show some parts of the stack memory by using a format string like this:
 <code C> <code C>
Line 253: Line 250:
 This is a partial dump of the stack memory, starting from the current bottom of the stack towards the top — assuming the stack grows towards the low addresses. Depending on the size of the format string buffer and the size of the output buffer, you can reconstruct more or less large parts of the stack memory by using this technique. In some cases you can even retrieve the entire stack memory. This is a partial dump of the stack memory, starting from the current bottom of the stack towards the top — assuming the stack grows towards the low addresses. Depending on the size of the format string buffer and the size of the output buffer, you can reconstruct more or less large parts of the stack memory by using this technique. In some cases you can even retrieve the entire stack memory.
 A stack dump gives important information about the program flow and local function variables and may be very helpful for finding the correct offsets for a successful exploitation. A stack dump gives important information about the program flow and local function variables and may be very helpful for finding the correct offsets for a successful exploitation.
-=== Viewing memory at any location +==== Viewing memory at any location  ====
 It is also possible to peek at memory locations different from the stack memory. To do this we have to get the format function to display memory from an address we can supply.  It is also possible to peek at memory locations different from the stack memory. To do this we have to get the format function to display memory from an address we can supply. 
 This poses two problems to us:  This poses two problems to us: 
Line 295: Line 292:
 This is analog to the alignment in buffer overflow exploits. This is analog to the alignment in buffer overflow exploits.
  
-=== Exploitation - through pure format strings+==== Exploitation - through pure format strings ====
 Our goal in the case of exploitation is to be able to control the instruction pointer, i.e we want to extend our very limited control — the ability to control the behaviour of the format function — to real execution control, that is executing our raw machine code. Our goal in the case of exploitation is to be able to control the instruction pointer, i.e we want to extend our very limited control — the ability to control the behaviour of the format function — to real execution control, that is executing our raw machine code.
 Let's take a look at the following code: Let's take a look at the following code:
Line 428: Line 425:
 By ensuring our padding is always larger than 10, we can keep an always accurate number of ‘already_written’, the counter the format function maintains, since we always write exactly as much output bytes as specified with the length option in the format parameter. By ensuring our padding is always larger than 10, we can keep an always accurate number of ‘already_written’, the counter the format function maintains, since we always write exactly as much output bytes as specified with the length option in the format parameter.
  
-=== A general method to exploit format strings vulnerabilities+==== A general method to exploit format strings vulnerabilities ====
 The only remaining thing to exploit such vulnerabilities in a hands-on practical way is to put the arguments into the right order on the stack and use a stackpop sequence to increase the stack pointer.  The only remaining thing to exploit such vulnerabilities in a hands-on practical way is to put the arguments into the right order on the stack and use a stackpop sequence to increase the stack pointer. 
 It should look like: It should look like:
Line 440: Line 437:
  
 The write code has to be modified to match the number of bytes written by the stackpop, since the stackpop wrote already characters to the output when the format function parses the write-code — the format function counter does not start at zero, and this has to be considered. The write code has to be modified to match the number of bytes written by the stackpop, since the stackpop wrote already characters to the output when the format function parses the write-code — the format function counter does not start at zero, and this has to be considered.
-=== Direct Parameter Access+==== Direct Parameter Access ====
 There is a huge simplification which is known as 'direct parameter access', a way to directly address a stack parameter from within the format string. Almost all currently in use C libraries do support this features, but not all are useable to apply this There is a huge simplification which is known as 'direct parameter access', a way to directly address a stack parameter from within the format string. Almost all currently in use C libraries do support this features, but not all are useable to apply this
 method to format string exploitation. method to format string exploitation.
Line 462: Line 459:
  
  
-=== Generalizing format string exploits+==== Generalizing format string exploits ====
 The ''printf'' example is just one of many cases of format string vulnerabilities.  The ''printf'' example is just one of many cases of format string vulnerabilities. 
 In general, any system where user input affects program execution and data access in a custom way can be susceptible to such a vulnerability. Other specialized examples can be considered: In general, any system where user input affects program execution and data access in a custom way can be susceptible to such a vulnerability. Other specialized examples can be considered:
  * SQL injections  * SQL injections
  * XSS injections  * XSS injections
-== Tasks+===== Tasks =====
  
-=== Stack Canaries+==== Stack Canaries ====
  
 Download the archive with the tasks at the top of the page. The binaries should be fairly easy to reverse engineer. You can use any tool. Download the archive with the tasks at the top of the page. The binaries should be fairly easy to reverse engineer. You can use any tool.
  
-==== Task 1+=== Task 1 ===
  
 The ''mycanary'' binary contains a custom stack canary implementation. Can you defeat it? Call ''bad_func()''. The ''mycanary'' binary contains a custom stack canary implementation. Can you defeat it? Call ''bad_func()''.
  
-==== Task 2+=== Task 2 ===
  
 The ''bulletproof'' binary is compiled using GCC's SSP. I bet you can defeat it, **twice**! Don't let me down. Call ''bad_func()'' in **2 ways**: by overwriting a function pointer, and by overwriting a stack return address. **Disable ASLR for the second attack.** The ''bulletproof'' binary is compiled using GCC's SSP. I bet you can defeat it, **twice**! Don't let me down. Call ''bad_func()'' in **2 ways**: by overwriting a function pointer, and by overwriting a stack return address. **Disable ASLR for the second attack.**
Line 492: Line 489:
  
  
-=== Task 3 - Format Strings+==== Task 3 - Format Strings ====
 Download the archive with the tasks at the top of the page containing 5 binaries exhibiting a format string vulnerability. Analyze what each binary does using the methods already familiar to you and try to determine the exact format string that will lead to the desired result.  Download the archive with the tasks at the top of the page containing 5 binaries exhibiting a format string vulnerability. Analyze what each binary does using the methods already familiar to you and try to determine the exact format string that will lead to the desired result. 
 <note important> <note important>
Line 500: Line 497:
 shows you the invalid address associated with a SIGSEGV signal.  shows you the invalid address associated with a SIGSEGV signal. 
 </note> </note>
-<note tip> 
-In case you get stuck, please have a look at the {{:session:string_format_source.tgz|source code}} for the exercises.  
-</note> 
- 
-=== Feedback 
-Your feedback is very much needed and appreciated [[https://docs.google.com/forms/d/1iO7iNwyTdXi-2TVWnc5M4z3789Kiuu9god7PJ3xMKOU/edit|Feedback]] 
  
session/11.1594987649.txt.gz · Last modified: 2020/07/17 15:07 by Radu-Nicolae NICOLAU (78289)

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki