{"id":485,"date":"2014-03-27T04:00:26","date_gmt":"2014-03-27T03:00:26","guid":{"rendered":"http:\/\/blog.pi3.com.pl\/?p=485"},"modified":"2014-03-27T04:02:22","modified_gmt":"2014-03-27T03:02:22","slug":"adventure-with-stack-smashing-protector-ssp","status":"publish","type":"post","link":"https:\/\/blog.pi3.com.pl\/?p=485","title":{"rendered":"Adventure with Stack Smashing Protector (SSP)"},"content":{"rendered":"

Introduction.<\/span><\/b><\/p>\n

I was heavily playing with Stack Smashing Protector a few years ago. Some of my research (observation) I decided to publish on phrack magazine but not everything. Two years ago my professional life moved to the Windows environment and unfortunately I didn\u2019t have time to play with UNIX world as much as before. One weekend I decided to reanalyze SSP code again and this write-up is describing a few of my observations I\u2019ve made during the work\u2026<\/p>\n

\u2026 which can be shortly summarized as:<\/p>\n

 <\/p>\n

Not security related\u2026<\/span><\/p>\n

    \n
  1. We can change program\u2019s name (from SSP perspective) via overwriting memory region where pointer to “argv[0]” points to.<\/li>\n
  2. We can crash Stack Smashing Protector code in many ways:\n
      \n
    1. Via corrupting memory region pointed by “__environ” variable.<\/li>\n
    2. Via setting “LIBC_FATAL_STDERR_” to the edge of valid addresses.<\/li>\n
    3. Via forcing “alloca()” to fail \u2013 e.g. stack exhaustion.<\/li>\n
    4. There is one more bug which I\u2019m analyzing more comprehensively at point 4. It may indirectly force SSP to crash. It exists in DWARF stack (state) machine which is responsible for gathering information about the stack trace (“__backtrace()”) and prints it.<\/li>\n<\/ol>\n<\/li>\n
    5. We can slightly control SSP\u2019s execution flow. (Un)Fortunately it doesn\u2019t have any influence for the main execution (what about security?). Following scenarios are possible:\n
        \n
      1. Force SSP to open “\/dev\/tty”<\/li>\n
      2. Force SSP not<\/span><\/i> to open “\/dev\/tty” and assign to the “fd” descriptor “STDERR_FILENO” value:<\/li>\n<\/ol>\n

        #define STDERR_FILENO 2 \/* Standard error output. *\/<\/p>\n

          \n
        1. Crash SSP via 2b. scenario<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
            \n
          1. We can crash indirectly SSP via unwinding algorithm (read-AV or we can be killed by “gcc_unreachable” or “gcc_assert” function) \u2013 DWARF stack (state) machine:\n
              \n
            1. Simulate FDE object was not found<\/li>\n
            2. Simulate FDE object was found.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

              Somehow security related\u2026<\/span><\/p>\n

                \n
              1. We can force SSP to allocate a lot of memory and cause Denial of Service via Resource Exhaustion attack.<\/li>\n
              2. Theoretical Information leak:\n
                  \n
                1. Stack cookie information leak.<\/li>\n
                2. Any kind of information leak<\/li>\n
                3. File corruption.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

                  Full write-up is available here <\/a>\ud83d\ude42
                  \n 
                  \n 
                  \nBest regards,
                  \nAdam ‘pi3’ Zabrocki<\/p>\n","protected":false},"excerpt":{"rendered":"

                  Introduction. I was heavily playing with Stack Smashing Protector a few years ago. Some of my research (observation) I decided to publish on phrack magazine but not everything. Two years ago my professional life moved to the Windows environment and unfortunately I didn\u2019t have time to play with UNIX world as much as before. One […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-485","post","type-post","status-publish","format-standard","hentry","category-o-wszystkim-i-o-niczym"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/blog.pi3.com.pl\/index.php?rest_route=\/wp\/v2\/posts\/485","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.pi3.com.pl\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.pi3.com.pl\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.pi3.com.pl\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.pi3.com.pl\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=485"}],"version-history":[{"count":10,"href":"https:\/\/blog.pi3.com.pl\/index.php?rest_route=\/wp\/v2\/posts\/485\/revisions"}],"predecessor-version":[{"id":495,"href":"https:\/\/blog.pi3.com.pl\/index.php?rest_route=\/wp\/v2\/posts\/485\/revisions\/495"}],"wp:attachment":[{"href":"https:\/\/blog.pi3.com.pl\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=485"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.pi3.com.pl\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=485"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.pi3.com.pl\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=485"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}