{"id":134,"date":"2007-09-15T20:57:05","date_gmt":"2007-09-16T04:57:05","guid":{"rendered":"http:\/\/outflux.net\/blog\/archives\/2007\/09\/15\/catching-stack-overflows-in-gdb-as-they-happen\/"},"modified":"2007-09-27T10:33:48","modified_gmt":"2007-09-27T18:33:48","slug":"catching-stack-overflows-in-gdb-as-they-happen","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2007\/09\/15\/catching-stack-overflows-in-gdb-as-they-happen\/","title":{"rendered":"catching stack overflows in gdb as they happen"},"content":{"rendered":"

Recently I was trying to help debug a stack overflow crash in wpa_supplicant<\/a>. The trouble with a stack crash is that you end up without a useful call history since the stack is left partially wrecked. The compiler code for detecting stack overflows (SSP), sets up a canary value between the local variables of the function and the stack frame. When the function exits, it tests this canary value and aborts if it doesn’t match what it is expecting. So, logically, to catch the stack overflow, gdb needs to be set up in a way to watch the canary location too. Since the canary is only valid while in the function, gdb must be set up to have a memory watch only when the function is called.<\/p>\n

Here is the function preamble:<\/p>\n

\n
\r\n0x08081940 <wpa_driver_wext_get_scan_results+0>:        push   %ebp\r\n0x08081941 <wpa_driver_wext_get_scan_results+1>:        mov    %esp,%ebp\r\n0x08081943 <wpa_driver_wext_get_scan_results+3>:        push   %edi\r\n0x08081944 <wpa_driver_wext_get_scan_results+4>:        push   %esi\r\n0x08081945 <wpa_driver_wext_get_scan_results+5>:        push   %ebx\r\n<\/pre>\n<\/blockquote>\n
Save registers, prepare %ebp.<\/p>\n
\n
\r\n0x08081946 <wpa_driver_wext_get_scan_results+6>:        mov    $0x1000,%ebx\r\n0x08081951 <wpa_driver_wext_get_scan_results+17>:       mov    0x8(%ebp),%eax\r\n0x08081954 <wpa_driver_wext_get_scan_results+20>:       mov    0xc(%ebp),%edx\r\n0x08081957 <wpa_driver_wext_get_scan_results+23>:       lea    0xffffffb0(%ebp),%esi\r\n<\/pre>\n<\/blockquote>\n
Make room for local variables, copy some function arguments and local variables into registers.<\/p>\n
\n
\r\n0x0808195a <wpa_driver_wext_get_scan_results+26>:       mov    %gs:0x14,%ecx\r\n0x08081961 <wpa_driver_wext_get_scan_results+33>:       mov    %ecx,0xffffffec(%ebp)\r\n0x08081964<\/b> <wpa_driver_wext_get_scan_results+36>:       xor    %ecx,%ecx\r\n<\/pre>\n<\/blockquote>\n
Here’s the stack canary getting set, and the register cleared.  It’s saved at %ebp minus 0x14 (0xffffffec signed is -0x14):<\/p>\n
\n
\r\n(gdb) printf \"0x%x\\n\", 0-0xffffffec\r\n0x14\r\n<\/pre>\n<\/blockquote>\n
Now for the function play-out:<\/p>\n
\n
\r\n0x08081a37 <wpa_driver_wext_get_scan_results+247>:      mov    0xffffffec(%ebp),%edx\r\n0x08081a3a<\/b> <wpa_driver_wext_get_scan_results+250>:      xor    %gs:0x14,%edx\r\n0x08081a41 <wpa_driver_wext_get_scan_results+257>:      jne    0x8081eae <wpa_driver_wext_get_scan_results+1390>\r\n<\/pre>\n<\/blockquote>\n
There is the canary check.<\/p>\n
\n
\r\n0x08081a47 <wpa_driver_wext_get_scan_results+263>:      add    $0xec,%esp\r\n0x08081a4d <wpa_driver_wext_get_scan_results+269>:      pop    %ebx\r\n0x08081a4e <wpa_driver_wext_get_scan_results+270>:      pop    %esi\r\n0x08081a4f <wpa_driver_wext_get_scan_results+271>:      pop    %edi\r\n0x08081a50 <wpa_driver_wext_get_scan_results+272>:      pop    %ebp\r\n0x08081a51 <wpa_driver_wext_get_scan_results+273>:      ret    \r\n...\r\n0x08081eae <wpa_driver_wext_get_scan_results+1390>:     call   0x804bdc8 <__stack_chk_fail@plt>\r\n<\/pre>\n<\/blockquote>\n
Release local stack, pop saved registers and return.  Nearer the end is the call to __stack_chk_fail when the canary doesn’t match.<\/p>\n
So, to watch the canary, we need to set up a memory watch after it as been set, and tear it down before we leave the function.  Respectively, we can use addresses 0x08081964 and 0x08081a3a (in bold above):<\/p>\n
\n
\r\n(gdb) br *0x08081964\r\nBreakpoint 1 at 0x8081964\r\n(gdb) br *0x08081a3a\r\nBreakpoint 2 at 0x8081a3a\r\n<\/pre>\n<\/blockquote>\n
At the first breakpoint, we set a memory watch using a gdb-local variable, based on %ebp (we can’t use %ebp directly since it will change in lower function calls):<\/p>\n
\n
\r\n(gdb) commands 1\r\nType commands for when breakpoint 1 is hit, one per line.\r\nEnd with a line saying just \"end\".\r\n>silent\r\n>set variable $cow = (unsigned long*)($ebp - 0x14)\r\n>watch *$cow\r\n>cont\r\n>end\r\n<\/pre>\n<\/blockquote>\n
Since I couldn’t find an easy way to track the memory watch number that was created during the first breakpoint, I just built a gdb counter, and deleted the memory watch when leaving, since I could predict gdb’s numbering (first watch will be “3”, following our breakpoints 1 and 2):<\/p>\n
\n
\r\n(gdb) set variable $count = 3\r\n(gdb) commands 2\r\nType commands for when breakpoint 2 is hit, one per line.\r\nEnd with a line saying just \"end\".\r\n>silent\r\n>delete $count\r\n>set variable $count = $count + 1\r\n>cont\r\n>end\r\n<\/pre>\n<\/blockquote>\n
Now we can run, and wait for the canary to get overwritten:<\/p>\n
\n
\r\n(gdb) cont\r\nContinuing.\r\nHardware watchpoint 3: *$cow\r\nHardware watchpoint 4: *$cow\r\n...\r\nHardware watchpoint 12: *$cow\r\nHardware watchpoint 13: *$cow\r\nHardware watchpoint 13: *$cow\r\n\r\nOld value = 4278845440\r\nNew value = 4278845546\r\n0x0804eae6 in ?? ()\r\n<\/pre>\n<\/blockquote>\n
We see the canary value is 0xFF0A0000 getting it’s little-endian first byte overwritten to FF0A006A.  We catch it before it has wrecked the stack, and we can see very clearly where we are:<\/p>\n
\n
\r\n(gdb) bt\r\n#0  hexstr2bin (hex=0x080a239d \"6151663870517a74\", buf=0x080a2395 \"aQf8pQzt00000000j\", len=8)\r\n    at ..\/src\/utils\/common.c:88\r\n#1  0x08082297 in wpa_driver_wext_get_scan_results (priv=0xb7dd816c, \r\n    results=0x080a239d, max_size=0x79)\r\n    at ..\/src\/drivers\/driver_wext.c:1383\r\n...\r\n(gdb) x\/1i $eip      \r\n0x804eae6 <hexstr2bin +54>:      addl   $0x1,0xfffffff0(%ebp)\r\n<\/pre>\n<\/blockquote>\n
On a closer look at the source, we realize wext_get_scan_custom got inlined into the function (it was static and only called from one place, so the compiler optimized it).  Further tracking in the source shows that the “16” value passed in should actually be “8” (the limit of the destination, not the source, buffer size).<\/p>\n","protected":false},"excerpt":{"rendered":"
Recently I was trying to help debug a stack overflow crash in wpa_supplicant. The trouble with a stack crash is that you end up without a useful call history since the stack is left partially wrecked. The compiler code for detecting stack overflows (SSP), sets up a canary value between the local variables of the […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10,6,14],"tags":[],"_links":{"self":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/134"}],"collection":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/comments?post=134"}],"version-history":[{"count":0,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/134\/revisions"}],"wp:attachment":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/media?parent=134"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/categories?post=134"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/tags?post=134"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}