Re: [DynInst_API:] After Executable Stack

[Sergej Proskurin <prosig@xxxxxxx>]

I believe I can answer my question by myself:

As I have already mentioned within my initial question above,
PT_GNU_STACK permissions are only enforced if all included libraries do
not require an executable stack. Since my Dyninst-based binary editing
implementation does not require any functions from the included library
dependency "libdyninstAPI_RT.so.8.2", it is possible to simply delete
this dependency from the ELF file. This way the stack will be marked as
specified within the PT_GNU_STACK program header.

Thank you.

Best regards,
Sergej

On 29.12.2014 23:42, Sergej Proskurin wrote:
> Hello,
> 
> I have noticed that after a binary has been statically rewritten with
> help of Dyninst, its stack is marked as executable. Even after
> modification of the PT_GNU_STACK program header (RW), the stack remains
> executable -- (this may be observed e.g. by means of 'pmap' on Linux).
> 
> The mentioned process of binary rewriting does not make much: in my case
> Dyninst creates a wrapper for the _init() function and includes another
> segment (marked as RWE) comprising among others a new .dynamic section
> and a section containing the wrapper code. But even, if the program does
> not create a wrapper code (so no additional .text section in the
> dynsinst specific segment is needed), the stack of the resulting binary
> remains executable.
> 
> /* snippet of the readelf output */
> 
> Program Headers:
> ...
> LOAD       0x005000 0x08100000 0x08100000 0x0049f 0x0049f RWE 0x1000
> ...
> GNU_STACK  0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x10
> ...
> 
> (as already mentioned above: the deletion of the E flag of the GNU_STACK
> program header does not help)
> 
> Section to Segment mapping (Segment 04 is the LOAD segment from above):
> ...
>  04  .dyninstInst .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r
> .rel.dyn .rel.plt .dynamic
> ...
> 
> /* snippet end */
> 
> First I thought of manually moving all relevant parts of the .dynamic
> section, created by Dyninst to another segment and mark it as RW. Thus,
> the other parts of the .dynamic Segment could be marked as RW and and
> the remaining parts of the LOAD segment created by Dyninst as RE. I
> thouth there might be a connection between this LOAD segment and the
> need for an executable stack... However, this does not seem to be a
> solution here, since I have marked the complete section as RW (just for
> testing) and the stack was marked as RWE, as well.
> 
> Dyninst inserts an additional library dependency to the binary, namely
> "libdyninstAPI_RT.so.8.2". This library seems to has (in my case) a
> PT_GNU_STACK program heder, which specifies an executable stack (RWX).
> If I have understood it correctly, the dynamic linker (loader) will mark
> a binary's stack as executable if a library dependency requires an
> executable stack. But I am not sure in what way this information should
> help me in this case: The delection of the library dependency
> "libdyninstAPI_RT.so.8.2" would certainly lead to a non-working binary...
> 
> I was wondering whether you could provide me information about what
> needed to be done so that the stack of rewritten binaries is marked by
> the loader according to the PT_GNU_STACK program header permissions?
> 
> Thank you very much in advance.
> 
> Best regards,
> Sergej
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
> 


-- 
Sometimes the problem is to discover what the problem is.

[Gordon Glegg, The Design of Design]