Flag for late RELRO application

Flag for late RELRO application

[Florian Weimer]

I would like to add a flag to gABI (visible in the dynamic section) 
which indicates that the loader shall apply RELRO protection only after 
running the ELF constructors from DT_INIT and DT_INIT_ARRAY.

This would allow applications to allocate a mapping and store a pointer 
to it in permanently read-only memory.  On the mapping itself, the 
application can set the protection flags (and keys) as needed.

Comments?

Thanks,
Florian

Re: Flag for late RELRO application

[Florian Weimer]

On 06/11/2018 06:29 PM, Carlos O'Donell wrote:
> On 06/11/2018 07:23 AM, Florian Weimer wrote:
>> I would like to add a flag to gABI (visible in the dynamic section)
>> which indicates that the loader shall apply RELRO protection only
>> after running the ELF constructors from DT_INIT and DT_INIT_ARRAY.
> 
> I assume that means also after DT_PREINIT_ARRAY?

Yes, that too.

> Should the semantics be worded in such a way as to simply say that
> all constructors have finished running?

That would be okay.

> That could be a lot of code running without RELRO protections.

Hence I suggest to require opt-in via a flag.

>> This would allow applications to allocate a mapping and store a
>> pointer to it in permanently read-only memory.  On the mapping
>> itself, the application can set the protection flags (and keys) as
>> needed.
> 
> Wouldn't it be safer to have some kind of second "type" of RELRO
> for these particular uses?

Safer in what sense?  It's going to be quite complicated (new DT_* 
entries, linker support for various sections, documentation for the new 
section names).

A new flag would only need very limited linker support, and we'd have to 
document the existing section names (which are already part of the ABI, 
but may not be documented).

> This way we don't mix what is effectively early RELRO with late
> RELRO?

I'm not convinced the additional complexity is worth it.  It's possible 
to write a shared object in such a way that constructors are minimized 
(and we should clean up the ones automatically provided by GCC, 
independently of that).  If necessary, a separate object can be used.

> I know that it's easier to just defer RELRO (all the existing
> machinery is already in place for it), but I'm wondering if that
> won't worsen the protection in substantial ways.
> 
> For example how would an application mark a pointer as read-only
> but also write to it?

This seems to be portable across all GNU architectures:

void *ptr __attribute__ ((section (".data.rel.ro")));

> If you have to markup existing code with
> attributes to get this to work, you might as well collect them
> into a special section and use a 'late RELRO' flag for it,
> extending the existing RELRO framework.

Again, is this really worth the complexity?

Thanks,
Florian

Re: Flag for late RELRO application

[Carlos O'Donell]

On 06/11/2018 01:37 PM, Florian Weimer wrote:
> On 06/11/2018 06:29 PM, Carlos O'Donell wrote:
>> If you have to markup existing code with
>> attributes to get this to work, you might as well collect them
>> into a special section and use a 'late RELRO' flag for it,
>> extending the existing RELRO framework.
> 
> Again, is this really worth the complexity?

Consider the behaviour the flag will enable.

Say it becomes wildly successful, and all application authors turn
it on. Now, everyone is using "LATE" (flag) + "RELRO." Maybe even
against your recommendations.

If we wish to further harden such binaries (applying some of RELRO 
earlier again), would we have a way to do so easily?

Do we have to define the "late RELRO" flag in such a way as to guide
implementations to make choices that allow them to continue to be
able to incrementally harden applications?

For example:

DT_FLAGS:

* DF_LATE_RELRO flag set in DT_FLAGS if the dynamic loader should
  run all constructors and initializers before marking all relocations
  read-only.

Special Sections:

* ".data.re.ro.late" - SHT_PROGBITS, SHF_ALLOC+SHF_WRITE
  This section holds data that must be writable until after all
  constructors and initializers have been run.

Implementation considerations:

* The guidance to linker implementations is that DF_LATE_RELRO should
  only be set if an input section contained data in the section
  ".data.rel.ro.late" to disambiguate the data that really needs the
  late RELRO semantics from those that don't. So we can eventually
  harden in two stages. For now the linker can choose to merge everything
  together and let the dynamic loader delay RELRO.

In this way we define the flag, *and* a section for late RELRO in such
a way that we can find these uses later if we want to move them or further
harden such binaries. This is a bit more work, but I think it will pay
dividends if we ever need to do further hardening.

Thoughts?

Cheers,
Carlos.

Re: Flag for late RELRO application

[Cary Coutant]

> I would like to add a flag to gABI (visible in the dynamic section) which
> indicates that the loader shall apply RELRO protection only after running
> the ELF constructors from DT_INIT and DT_INIT_ARRAY.
>
> This would allow applications to allocate a mapping and store a pointer to
> it in permanently read-only memory.  On the mapping itself, the application
> can set the protection flags (and keys) as needed.

Why can't the application that wants to do this simply do the following?

   mprotect(&ptr, sizeof(ptr), PROT_READ|PROT_WRITE);
   ptr = ...;
   mprotect(&ptr, sizeof(ptr), PROT_READ);

We have RELRO to collect all the data together that the dynamic loader
needs to initialize. I see no good reason to extend that feature to
support an application-specific need, especially when it significantly
expands the window during which the program is subject to attack.
Initializers are just as prone to hacking as the rest of the program.

-cary

Re: Flag for late RELRO application

[Carlos O'Donell]

On 06/11/2018 07:23 AM, Florian Weimer wrote:
> I would like to add a flag to gABI (visible in the dynamic section)
> which indicates that the loader shall apply RELRO protection only
> after running the ELF constructors from DT_INIT and DT_INIT_ARRAY.

I assume that means also after DT_PREINIT_ARRAY?

Should the semantics be worded in such a way as to simply say that
all constructors have finished running?

That could be a lot of code running without RELRO protections.

> This would allow applications to allocate a mapping and store a
> pointer to it in permanently read-only memory.  On the mapping
> itself, the application can set the protection flags (and keys) as
> needed.

Wouldn't it be safer to have some kind of second "type" of RELRO
for these particular uses?

This way we don't mix what is effectively early RELRO with late
RELRO?

I know that it's easier to just defer RELRO (all the existing
machinery is already in place for it), but I'm wondering if that
won't worsen the protection in substantial ways.

For example how would an application mark a pointer as read-only
but also write to it? If you have to markup existing code with
attributes to get this to work, you might as well collect them
into a special section and use a 'late RELRO' flag for it,
extending the existing RELRO framework.

Just a thought.

Cheers,
Carlos.

Re: Flag for late RELRO application

[Florian Weimer]

On 06/11/2018 09:52 PM, Cary Coutant wrote:
>> I would like to add a flag to gABI (visible in the dynamic section) which
>> indicates that the loader shall apply RELRO protection only after running
>> the ELF constructors from DT_INIT and DT_INIT_ARRAY.
>>
>> This would allow applications to allocate a mapping and store a pointer to
>> it in permanently read-only memory.  On the mapping itself, the application
>> can set the protection flags (and keys) as needed.
> 
> Why can't the application that wants to do this simply do the following?
> 
>     mprotect(&ptr, sizeof(ptr), PROT_READ|PROT_WRITE);
>     ptr = ...;
>     mprotect(&ptr, sizeof(ptr), PROT_READ);

The original mapping might have been PROT_READ | PROT_EXEC, and then the 
PROT_EXEC is gone, which isn't good.  Security policy may also preven 
tthe PROT_WRITE → PROT_EXEC transition.

> We have RELRO to collect all the data together that the dynamic loader
> needs to initialize. I see no good reason to extend that feature to
> support an application-specific need, especially when it significantly
> expands the window during which the program is subject to attack.
> Initializers are just as prone to hacking as the rest of the program.

Initializers can access the process environment, true, but for many 
applications, that is trusted and there is no boundary crossed.  That 
only comes later in the process (after running main).

In any case, I wanted to make this opt-in, so that applications or 
libraries can choose the approach they prefer.

Thanks,
Florian