ELF，PIE ASLR以及两者之间的所有内容，尤其是在Linux中 [英] ELF, PIE ASLR and everything in between, specifically within Linux

问题描述

在问我的问题之前，我想介绍一些技术细节，以确保我答对了.

• 位置独立可执行程序(PIE)是一种程序，无论加载到哪个内存地址，都可以执行，对吗?

• ASLR(地址空间布局随机化)几乎表明，为了保持地址静态，我们将以某种方式将其随机化，

我已经读到，特别是在基于Linux和Unix的系统中，无论我们的代码是PIE，还是PIE，所有的跳转，调用和偏移都是相对的，实现ASLR都是可能的，因此我们没有问题.如果不是，则无论代码是可执行文件还是共享对象，代码都会以某种方式被修改并编辑地址.

现在这使我问了几个问题

1. 如果可以在非PIE且不是可执行文件且不共享/可迁移的对象内的代码中实现ASLR(我知道在可迁移的对象内如何进行重新分配！！！！ )，怎么做?ELF格式不应包含任何部分来说明代码部分中的函数，以便内核加载程序可以对其进行修改，对吗?ASLR应该是内核功能，因此，例如，包含这些指令的可执行文件到底是怎么回事.

   伪代码:

     inc_eax:添加eax，5退回主要的:mov eax，5mov ebx，6岁致电ABSOLUTE_ADDRES {inc_eax} 

   内核可执行加载器如何知道如何更改如果它们没有存储在ELF中的某些可重定位的表中，则地址文件，并且不是相对的，以便将可执行文件加载到某些文件中随机地址?

2. 假设我错了，并且要实施ASLR，您必须拥有一个PIE可执行文件.所有段都是相对的.一个人怎么编译C ++ OOP代码并使之工作，例如，如果我有一些实例类使用指向其结构中的虚拟表的指针的实例，并且该虚拟表应包含绝对地址，因此我无法为具有以下功能的C ++程序编译纯PIE使用运行时虚拟表，再也无法使用ASLR....我怀疑虚拟表是否包含相对地址和每个呼叫都会有一个不同的虚拟表虚拟功能...

3. 我最后一个也是最不重要的问题是关于ELF和PIE的-是否有一些特殊的方法来检测ELF可执行文件是PIE?我熟悉ELF格式，因此我怀疑是否有办法，但是我可能错了.无论如何，如果没有办法，内核加载程序如何知道我们的可执行文件是否为PIE，因此可以在其上使用ASLR.

我已经把这一切弄得一团糟，如果有人可以在这里帮助我，我会很乐意的.

解决方案

您的问题似乎充满了混乱和误解.

位置独立可执行文件(PIE)是一种程序，无论加载到哪个内存地址，都可以执行，对吧?

差不多.通常无法将 PIE 二进制文件加载到任意地址处的内存中，因为其 PT_LOAD 段将具有一些对齐要求(例如0x400或0x10000).但是它可以加载，并且如果将其加载到满足对齐要求的地址的内存中，它将可以正确运行.

ASLR(地址空间布局随机化)几乎指出，为了使地址保持静态，我们将以某种方式将其随机化，

我无法以任何有意义的方式解析以上语句.

ASLR是一种用于随机化地址空间的各个部分以便使已知地址"成为随机数的技术.攻击更加困难.

请注意，ASLR 早于 PIE 二进制文件，并且完全不需要 PIE .引入ASLR时，它会随机放置堆栈，堆和共享库.(非 PIE )主可执行文件的位置无法随机分配.

ASLR被认为是成功的，因此可以扩展为还支持 PIE 主二进制文件，它实际上是一个特制的共享库(并且具有 ET_DYN 文件类型).

1. 致电ABSOLUTE_ADDRES {inc_eax} 如果>，内核可执行加载程序将如何知道如何更改地址?它们没有存储在可重定位的表中

简单:在x86上，没有 no 指令来调用ABSOLUTE_ADDRESS -所有调用都是相对的.

2 ...对于使用运行时虚拟表的C ++程序，我将无法编译纯PIE，因此ASLR也是不可能的..

PIE 二进制文件要求重定位，就像共享库一样. PIE 二进制文件中的虚拟表与共享库中的虚拟表完全相同地工作: ld-linux.so.2 更新 GOT (全局偏移量表)，然后再将控制权转移到 PIE 二进制文件.

3 ...有什么特殊的方法可以检测到ELF可执行文件是PIE

简单: PIE 二进制文件的ELF文件类型设置为 ET_DYN (非 PIE 二进制文件的类型为 ET_EXEC ).如果在 PIE 可执行文件上运行 file a.out ，则会看到它是共享库".

Before asking my question, I would like to cover some few technical details I want to make sure I've got correct:

• A Position Independent Executable (PIE) is a program that would be able to execute regardless of which memory address it is loaded into, right?

• ASLR (Address Space Layout Randomization) pretty much states that in order to keep addresses static, we would randomize them in some manner,

I've read that specifically within Linux and Unix based systems, implementing ASLR is possible regardless of if our code is a PIE, if it is PIE, all jumps, calls and offsets are relative hence we have no problem. If it's not, code somehow gets modified and addresses are edited regardless of whether the code is an executable or a shared object.

Now this leads me to ask a few questions

1. If ASLR is possible to implement within codes that aren't PIE and are executables AND NOT SHARED / RELOCATABLE OBJECT (I KNOW HOW RELOCATION WORKS WITHIN RELOCATABLE OBJECTS!!!!), how is it done? ELF format should hold no section that states where within the code sections are functions so the kernel loader could modify it, right? ASLR should be a kernel functionality so how on earth could, for example, an executable containing, for example, these instructions.

   pseudo code:

    inc_eax:
     add eax, 5
     ret
   
    main:
     mov eax, 5
     mov ebx, 6
     call ABSOLUTE_ADDRES{inc_eax}
   

   How would the kernel executable loader know how to change the addresses if they aren't stored in some relocatable table within the ELF file and aren't relative in order to load the executable into some random address?

2. Let's say I'm wrong, and in order to implement ASLR you must have a PIE executable. All segments are relative. How would one compile a C++ OOP code and make it work, for example, if I have some instance of a class using a pointer to a virtual table within its struct, and that virtual table should hold absolute addresses, hence I wouldn't be able to compile a pure PIE for C++ programs that have usage of run time virtual tables, and again ASLR isn't possible.... I doubt that virtual tables would contain relative addresses and there would be a different virtual table for each call of some virtual function...

3. My last and least significant question is regarding ELF and PIE — is there some special way to detect an ELF executable is PIE? I'm familiar with the ELF format so I doubt that there is a way, but I might be wrong. Anyway, if there isn't a way, how does the kernel loader know if our executable is PIE hence it could use ASLR on it.

I've got this all messed up in my head and I'd love it if someone could help me here.

解决方案

Your question appears to be a mish-mash of confusion and misunderstanding.

A Position Independent Executable (PIE) is a program that would be able to execute regardless of which memory address it is loaded into, right?

Almost. A PIE binary usually can not be loaded into memory at arbitrary address, as its PT_LOAD segments will have some alignment requirements (e.g. 0x400, or 0x10000). But it can be loaded and will run correctly if loaded into memory at address satisfying the alignment requirements.

ASLR (Address Space Layout Randomization) pretty much states that in order to keep addresses static we would randomize them in some manner,

I can't parse the above statement in any meaningful way.

ASLR is a technique for randomizing various parts of address space, in order to make "known address" attacks more difficult.

Note that ASLR predates PIE binaries, and does not in any way require PIE. When ASLR was introduced, it randomized placement of stack, heap, and shared libraries. The placement of (non-PIE) main executable could not be randomized.

ASLR has been considered a success, and therefore extended to also support PIE main binary, which is really a specially crafted shared library (and has ET_DYN file type).

1. call ABSOLUTE_ADDRES{inc_eax} how would the kernel executable loader know how to change the addresses if > they aren't stored in some relocatable table

Simple: on x86, there is no instruction to call ABSOLUTE_ADDRESS -- all calls are relative.

2 ... I wouldn't be able to compile a pure PIE for C++ programs that have usage of run time virtual tables, and again ASLR isn't possible..

PIE binary requires relocation, just like a shared library. Virtual tables in PIE binaries work exactly the same way they work in shared libraries: ld-linux.so.2 updates GOT (global offset table) before transferring control to the PIE binary.

3 ... is there some special way to detect an ELF executable is PIE

Simple: a PIE binary has ELF file type set to ET_DYN (a non-PIE binary will have type ET_EXEC). If you run file a.out on a PIE executable, you'll see that it's a "shared library".

这篇关于ELF，PIE ASLR以及两者之间的所有内容，尤其是在Linux中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！