{"id":4847,"date":"2020-11-25T15:06:18","date_gmt":"2020-11-25T07:06:18","guid":{"rendered":"https:\/\/damogame.cn\/wordpress\/?p=4847"},"modified":"2020-11-25T15:06:18","modified_gmt":"2020-11-25T07:06:18","slug":"relro-relocation-read-only","status":"publish","type":"post","link":"https:\/\/i007.cc\/wordpress\/archives\/4847","title":{"rendered":"RELRO: RELocation Read-Only"},"content":{"rendered":"
\n
\n
\n
\u539f\u6587\u5730\u5740<\/a><\/div>\n
<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
\n
\n
\n

This article describes ELF relocation sections, how to abuse them for arbitrary code execution, and how to protect them at runtime.<\/p>\n

ELF Relocation Sections<\/strong><\/p>\n

A dynamically linked ELF binary uses a look-up table called Global Offset Table (GOT) to dynamically resolve functions that are located in shared libraries.<\/p>\n

When you call a function that is located in a shared library, it looks like the following. This is a high-level view of what is going on, there are lots of things the linker is doing that we won\u2019t go into.<\/p>\n

First, the call is actually pointing to the Procedure Linkage Table (PLT), which exists in the .plt section of the binary.<\/p>\n

objdump -M intel -d\u00a0YOUR_BINARY<\/p>\n

80484da:<\/span>       e8<\/span> 95<\/span> fe<\/span> ff<\/span> ff<\/span>          call<\/span>   8048374<\/span> <printf@plt><\/span><\/code><\/pre>\n
The .plt section contains x86 instructions that point directly to the GOT, which lives in the .got.plt section.<\/p>\n
objdump -M intel -d\u00a0YOUR_BINARY<\/p>\n
08048374<\/span> <printf@plt>:<\/span>\r\n 8048374:<\/span>       ff<\/span> 25<\/span> 54<\/span> 97<\/span> 04<\/span> 08<\/span>       jmp<\/span>    DWORD<\/span> PTR<\/span> ds:0x8049754<\/span>\r\n 804837a:<\/span>       68<\/span> 20<\/span> 00<\/span> 00<\/span> 00<\/span>          push<\/span>   0x20<\/span>\r\n 804837f:<\/span>       e9<\/span> a0<\/span> ff<\/span> ff<\/span> ff<\/span>          jmp<\/span>    8048324<\/span> <_init+0x30><\/span><\/code><\/pre>\n
The .got.plt section contains binary data. The GOT contain pointers back to the PLT or to the location of the dynamically linked function.<\/p>\n
objdump -s\u00a0YOUR_BINARY<\/p>\n
Contents<\/span> of<\/span> section<\/span> .got<\/span>.plt<\/span>:\r\n 8049738 6c960408<\/span> 00000000 00000000 3a830408<\/span>  l<\/span>...........:...<\/span>\r\n 8049748 4a830408<\/span> 5a830408<\/span> 6a830408<\/span> 7a830408<\/span>  J<\/span>...Z<\/span>...j<\/span>...z<\/span>...\r\n 8049758 8a830408<\/span> 9a830408<\/span>                    ........<\/code><\/pre>\n
By default, the GOT is populated dynamically while the program is running. The first time a function is called, the GOT contains a pointer back to the PLT, where the linker is called to find the actual location of the function in question (this is the part we\u2019re not going into detail about). The location found is then written to the GOT. The second time a function is called, the GOT contains the known location of the function. This is called \u201clazy binding.\u201d<\/p>\n
lazy<\/strong><\/p>\n
 When generating an executable or shared library, mark it to\r\ntell the dynamic linker to defer function call<\/span> resolution to<\/span>\r\nthe point when<\/span> the function<\/span> is<\/span> called (lazy binding), rather\r\nthan<\/span> at<\/span> load<\/span> time.  Lazy binding is<\/span> the default.  [1<\/span>]<\/code><\/pre>\n
There are a couple of design constraints for the GOT and the PLT.<\/p>\n
    \n
  • Because the PLT contains code that is called by the program directly, it needs to be allocated at a known offset from the .text segment.<\/li>\n
  • Because the GOT contains data used by different parts of the program directly, it needs to be allocated at a known static address in memory.<\/li>\n
  • Because the GOT is \u201clazy binded,\u201d it needs to be writable.<\/li>\n<\/ul>\n
    GOT Overwrite<\/strong><\/p>\n
    Since we know that the GOT lives in a predefined place and is writable, all that is needed is a bug that lets an attacker write four bytes anywhere. We\u2019ll use the following vulnerable program to simulate that. Note that we are operating on the same binary we examined above.<\/p>\n
    Here we have an intentionality vulnerable program that is hopefully believable enough to make this demo realistic. Understanding this program is not necessary for understanding the exploitation and mitigation techniques being demonstrated, it is only included for completeness.<\/p>\n
    \n
    \n\n\n\n
    \n
    1<\/div>\n
    2<\/div>\n
    3<\/div>\n
    4<\/div>\n
    5<\/div>\n
    6<\/div>\n
    7<\/div>\n
    8<\/div>\n
    9<\/div>\n
    10<\/div>\n
    11<\/div>\n
    12<\/div>\n
    13<\/div>\n
    14<\/div>\n
    15<\/div>\n
    16<\/div>\n
    17<\/div>\n
    18<\/div>\n
    19<\/div>\n
    20<\/div>\n
    21<\/div>\n
    22<\/div>\n
    23<\/div>\n
    24<\/div>\n
    25<\/div>\n
    26<\/div>\n
    27<\/div>\n
    28<\/div>\n
    29<\/div>\n
    30<\/div>\n
    31<\/div>\n
    32<\/div>\n
    33<\/div>\n
    34<\/div>\n
    35<\/div>\n
    36<\/div>\n
    37<\/div>\n
    38<\/div>\n
    39<\/div>\n<\/td>\n
    		\n
    \n
    \/\/ Include standard I\/O declarations<\/div>\n
    #include <stdio.h><\/div>\n
    \/\/ Include string declarations<\/div>\n
    #include <string.h><\/div>\n
    <\/div>\n
    \/\/ Program entry point<\/div>\n
    intmain(intargc,char** argv) {<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\/\/ Terminate if program is not run with three parameters.<\/div>\n
    \u00a0\u00a0\u00a0\u00a0if(argc != 4) {<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Print out the proper use of the program<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0puts(“.\/a.out <size> <offset> <string>”);<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Return failure<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return-1;<\/div>\n
    \u00a0\u00a0\u00a0\u00a0}<\/div>\n
    <\/div>\n
    \u00a0\u00a0\u00a0\u00a0\/\/ Convert size to an integer<\/div>\n
    \u00a0\u00a0\u00a0\u00a0intsize =atoi(argv[1]);<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\/\/ Convert offset to an integer<\/div>\n
    \u00a0\u00a0\u00a0\u00a0intoffset =atoi(argv[2]);<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\/\/ Place string into its own string on the stack<\/div>\n
    \u00a0\u00a0\u00a0\u00a0char* str = argv[3];<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\/\/ Declare a 256 byte buffer on the stack<\/div>\n
    \u00a0\u00a0\u00a0\u00a0charbuffer[256];<\/div>\n
    <\/div>\n
    \u00a0\u00a0\u00a0\u00a0\/\/ Print the location of the buffer for calculating the offset.<\/div>\n
    \u00a0\u00a0\u00a0\u00a0printf(“Buffer:\\t\\t%8x\\n”, &buffer);<\/div>\n
    <\/div>\n
    \u00a0\u00a0\u00a0\u00a0\/\/ Fill the buffer with the letter ‘A’.<\/div>\n
    \u00a0\u00a0\u00a0\u00a0memset(buffer, 65, 256 – 1);<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\/\/ Null-terminate the buffer.<\/div>\n
    \u00a0\u00a0\u00a0\u00a0buffer[255] = 0;<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\/\/ Attempt to copy the specified string into the specified location.<\/div>\n
    \u00a0\u00a0\u00a0\u00a0strncpy(buffer + offset, str, size);<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\/\/ Print out the buffer.<\/div>\n
    \u00a0\u00a0\u00a0\u00a0printf(“%s”, buffer);<\/div>\n
    <\/div>\n
    \u00a0\u00a0\u00a0\u00a0\/\/ Return success<\/div>\n
    \u00a0\u00a0\u00a0\u00a0return0;<\/div>\n
    }<\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n
    gcc -g -O0 -Wl,-z,norelro -fno-stack-protector -o\u00a0YOUR_BINARY\u00a0YOUR_SOURCE_CODE<\/p>\n
    First, some reconnaissance. We know from the examination above, that our GOT entry for printf lives at0x08049754. We know from tesing the program, that our buffer will live on the stack at0xbffff284.<\/p>\n
    (gdb)<\/span> x<\/span> 0x08049754<\/span>\r\n0x8049754<\/span> <_GLOBAL_OFFSET_TABLE_+28>:<\/span>\t0x0804837a<\/span>\r\n(gdb)<\/span> p<\/span> -(0xbffff284<\/span> -<\/span> 0x08049754<\/span>)<\/span> %<\/span> 0x80000000<\/span>\r\n$1<\/span> =<\/span> 1208263888<\/span>\r\n(gdb)<\/span> r<\/span> 4<\/span> 1208263888<\/span> \\$\\$\\$\\$<\/span>\r\nStarting program:<\/span> \/home\/hake\/code\/relro\/c<\/span> 4<\/span> 1208263888<\/span> \\$\\$\\$\\$<\/span>\r\nBuffer:<\/span>\t\tbffff284<\/span>\r\n\r\nProgram<\/span> received<\/span> signal<\/span> SIGSEGV,<\/span> Segmentation<\/span> fault.<\/span>\r\n0x08048374<\/span> in<\/span> printf@plt<\/span> ()<\/span>\r\n(gdb)<\/span> x<\/span> 0x08049754<\/span>\r\n0x8049754<\/span> <_GLOBAL_OFFSET_TABLE_+28>:<\/span>\t0x24242424<\/span><\/code><\/pre>\n
    Here, we see that we can overwrite the GOT entry for printf with our string. The program crashes because it\u2019s trying to jump to memory that is not mapped.<\/p>\n
    RELRO: RELocation Read-Only<\/strong><\/p>\n
    To prevent the above exploitation technique, we can tell the linker to resolve all dynamically linked functions at the beginning of execution and make the GOT read-only. Note that we are operating on a different binary below compiled from the same source code.<\/p>\n
    now<\/strong><\/p>\n
     When generating an executable or shared library, mark it to\r\ntell the dynamic<\/span> linker to resolve all symbols when<\/span> the program\r\nis<\/span> started, or when<\/span> the shared library is<\/span> linked to using<\/span>\r\ndlopen, instead of deferring function call resolution to the\r\npoint when<\/span> the function is<\/span> first called.  [1<\/span>]<\/code><\/pre>\n
    This exploitation mitigation technique is known as RELRO which stands for RELocation Read-Only. The idea is simple, make the relocation sections that are used to resolve dynamically loaded functions read-only. This way, they cannot overwrite them and we cannot take control of execution like we did above.<\/p>\n
    You can turn on Full RELRO with the gcc compiler option:-Wl,-z,relro,-z,now. This gets passed to the linker as-z relro -z now. On most modern Linux distributions a variant of RELRO known as Partial RELRO is used by default. Partial RELRO uses the-z relrooption, but not the-z nowoption.<\/p>\n
    gcc -g -O0 -Wl,-z,relro,-z,now -fno-stack-protector -o\u00a0YOUR_BINARY\u00a0YOUR_SOURCE_CODE<\/p>\n
    80484fa:<\/span>       e8<\/span> 95<\/span> fe<\/span> ff<\/span> ff<\/span>          call<\/span>   8048394<\/span> <printf@plt><\/span>\r\n\r\n08048394<\/span> <printf@plt>:<\/span>\r\n 8048394:<\/span>       ff<\/span> 25<\/span> f0<\/span> 9f<\/span> 04<\/span> 08<\/span>       jmp<\/span>    DWORD<\/span> PTR<\/span> ds:0x8049ff0<\/span>\r\n 804839a:<\/span>       68<\/span> 20<\/span> 00<\/span> 00<\/span> 00<\/span>          push<\/span>   0x20<\/span>\r\n 804839f:<\/span>       e9<\/span> a0<\/span> ff<\/span> ff<\/span> ff<\/span>          jmp<\/span>    8048344<\/span> <_init+0x30><\/span>\r\n\r\nContents of section .got:<\/span>\r\n 8049fd4<\/span> fc9e0408<\/span> 00000000<\/span> 00000000<\/span> 5a830408<\/span>  ............Z...<\/span>\r\n 8049fe4<\/span> 6a830408<\/span> 7a830408<\/span> 8a830408<\/span> 9a830408<\/span>  j...z...........<\/span>\r\n 8049ff4<\/span> aa830408<\/span> ba830408<\/span> 00000000<\/span>           ............<\/span><\/code><\/pre>\n
    The GOT entry for printf lives at0x08049ff0. The buffer will live on the stack at0xbffff284.<\/p>\n
    (gdb)<\/span> x<\/span> 0x08049ff0<\/span>\r\n0x8049ff0<\/span> <_GLOBAL_OFFSET_TABLE_+28>:<\/span>\t0x0804839a<\/span>\r\n(gdb)<\/span> p<\/span> -(0xbffff284<\/span> -<\/span> 0x08049ff0<\/span>)<\/span> %<\/span> 0x80000000<\/span>\r\n$1<\/span> =<\/span> 1208266092<\/span>\r\n(gdb)<\/span> r<\/span> 4<\/span> 1208266092<\/span> \\$\\$\\$\\$<\/span>\r\nStarting program:<\/span> \/home\/hake\/code\/relro\/r<\/span> 4<\/span> 1208266092<\/span> \\$\\$\\$\\$<\/span>\r\nBuffer:<\/span>\t\tbffff284<\/span>\r\n\r\nProgram<\/span> received<\/span> signal<\/span> SIGSEGV,<\/span> Segmentation<\/span> fault.<\/span>\r\nstrncpy<\/span> (s1=0x8049ff0<\/span> \"ph\\027\"<\/span>,<\/span> s2=0xbffff5fc<\/span> \"$$$\"<\/span>,<\/span> n=4)<\/span> at<\/span> strncpy.c:43<\/span>\r\n43<\/span>\tstrncpy.c:<\/span> No<\/span> such<\/span> file<\/span> or<\/span> directory.<\/span>\r\n\tin<\/span> strncpy.c<\/span>\r\n(gdb)<\/span> x<\/span> 0x08049ff0<\/span>\r\n0x8049ff0<\/span> <_GLOBAL_OFFSET_TABLE_+28>:<\/span>\t0x00176870<\/span><\/code><\/pre>\n
    Here, we see that we cannot overwrite the GOT entry for printf with our string. The program crashes because it trying to write to a memory segment that is read-only.<\/p>\n
    Technical note: All other memory corruption exploitation mitigation techniques were turned off for this demonstration.<\/em><\/p>\n
    Technical note: RELRO automatically applies all the specified protections to following segments:.ctors,.dtors,.jcr,.dynamicand.got.<\/em><\/p>\n
    Some Handy Commands<\/strong><\/p>\n
    Display Dynamic Relocation Entries
    \nobjdump -R\u00a0YOUR_BINARY<\/p>\n
    Show Program Header Table
    \nreadelf -l\u00a0YOUR_BINARY<\/p>\n
    Show Section Header Table
    \nreadelf -S\u00a0YOUR_BINARY<\/p>\n
    Display Relocations
    \nreadelf -r\u00a0YOUR_BINARY<\/p>\n
    Thanks<\/strong><\/p>\n
    Jon Oberheide<\/a><\/p>\n
    Citations<\/strong><\/p>\n
    [1] Manual page\u00a0ld(1)<\/a><\/p>\n
    Related Resources<\/strong><\/p>\n
    RELRO \u2013 A (not so well known) Memory Corruption Mitigation Technique<\/a>
    \n    How to Hijack the Global Offset Table with pointers<\/a>
    \n    Chapter 9. Dynamic Linking: Global Offset Tables<\/a>
    \n    The ELF format \u2013 How programs look from the inside<\/a>
    \n    Resolving ELF Relocation Name \/ Symbols<\/a><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
    \u539f\u6587\u5730\u5740 This article de<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[],"tags":[119],"class_list":["post-4847","post","type-post","status-publish","format-standard","hentry","tag-03-"],"_links":{"self":[{"href":"https:\/\/i007.cc\/wordpress\/wp-json\/wp\/v2\/posts\/4847","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/i007.cc\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/i007.cc\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/i007.cc\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/i007.cc\/wordpress\/wp-json\/wp\/v2\/comments?post=4847"}],"version-history":[{"count":0,"href":"https:\/\/i007.cc\/wordpress\/wp-json\/wp\/v2\/posts\/4847\/revisions"}],"wp:attachment":[{"href":"https:\/\/i007.cc\/wordpress\/wp-json\/wp\/v2\/media?parent=4847"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/i007.cc\/wordpress\/wp-json\/wp\/v2\/categories?post=4847"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/i007.cc\/wordpress\/wp-json\/wp\/v2\/tags?post=4847"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}