Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Mathias Payer]

[-- Attachment #1.1: Type: text/plain, Size: 3271 bytes --]

Hi there,

We want to report a vulnerability that is common in binaries on most
Linux distributions where binaries with PIE break common security
assumptions (like read-only format strings or immutable vtables).

When a program is not compiled as PIC, the compiler assumes addresses of
global variables are known at link time statically. However, this
assumption is not upheld when the program accesses a global variable
defined in a dynamic library. The ELF specification uses copy
relocations to allow programs that are not compiled as PIC to access
library variables without having to patch the read-only code segment at
runtime.  Specifically, a copy relocation instructs the dynamic loader
to copy each referenced library global variable to a program-specified
location and discard the one in the original library.  Unfortunately,
such a copy does not preserve the original memory protection, i.e., a
read-only library variable in the .rodata section is copied to the
writable .bss section in the executable.  Our study shows that such
dangerous behavior is prevalent in current software and certain types of
library variables (e.g., C++ vtables, format strings, or code pointers)
have security implications.  For mitigation, we suggest to recompile
programs with -fPIC flag so that the resultant programs use the Global
Offset Table to access library variables instead of relying on copy
relocations.  This ensures permissions specified at language source
level remain at runtime.

We have studied all Ubuntu 16.04 LTS packages and found that out of
54,045 packages, 4,570 packages have unexpected copy relocations that
change read-only permissions to read-write, presenting new avenues for
attack. The attack surface is broad with 29,817 libraries exporting
relocatable read-only variables. The set of 6,399 programs with actual
copy relocation violations includes ftp servers, apt-get, and gettext.
We have contacted the Debian and Ubuntu security teams.

This is a problem prevalent in ELF (and how ELF handles relocations).
While current systems mostly don't enforce integrity of code pointers,
many upcoming defenses like CFI assume that locations that are "read
only" will remain read only at runtime. If not addressed, such
relocations allow adversaries to modify read-only data such as format
strings or vtables to bypass deployed defenses.

The mitigation is to (a) recompile packages with -fPIC instead of -fPIE
or to (b) update the ELF format/loader linker toolchain so that
permissions of individual symbols can be tracked throughout the lifetime
of code.

The paper will be published at NDSS on Feb16. A preprint of
the paper is available at:
https://nebelwelt.net/publications/files/17NDSS.pdf
In the paper, we include a discussion how MacOS and Windows handle
similar issues and discuss possible mitigations in more detail.

We would like your help in addressing this problem, potentially
recompiling affected binaries/packages, updating the linker/loader, and
assigning a CVE number or numbers if warranted. When addressing/working
on this issue, we'd love if you can reference our research and NDSS paper.

We are happy to provide further details.

Thanks,
Mathias, Xinyang, and Trent


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Florian Weimer]

On 12/23/2016 12:50 PM, Mathias Payer wrote:

> We want to report a vulnerability that is common in binaries on most
> Linux distributions where binaries with PIE break common security
> assumptions (like read-only format strings or immutable vtables).

Thanks for sharing your research!

> The mitigation is to (a) recompile packages with -fPIC instead of -fPIE
> or to (b) update the ELF format/loader linker toolchain so that
> permissions of individual symbols can be tracked throughout the lifetime
> of code.

Does (b) really require changes to the ELF format?

An undefined symbol reference as such cannot be turned into a copy 
relocation because it lacks size information, and the static linker 
needs object sizes to lay out the section contents (and dynamic linker 
needs the size to make the copy).  I would expect that at the same time 
the size is looked up in the static linker, the section information 
could be determined as well.

The question is whether this is the semantics we want, or if we'd prefer 
if the reference itself determines the section type, like it is already 
the case with symbol visibility.  Implementing that would need broader 
changes.

Thanks,
Florian

PS: The C++ example code inf figure 4(a) has a typo, the call to the 
method b2 should probably be to b1.

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Alan Modra]

On Fri, Dec 23, 2016 at 01:58:38PM +0100, Florian Weimer wrote:
> On 12/23/2016 12:50 PM, Mathias Payer wrote:
> 
> >We want to report a vulnerability that is common in binaries on most
> >Linux distributions where binaries with PIE break common security
> >assumptions (like read-only format strings or immutable vtables).
> 
> Thanks for sharing your research!
> 
> >The mitigation is to (a) recompile packages with -fPIC instead of -fPIE
> >or to (b) update the ELF format/loader linker toolchain so that
> >permissions of individual symbols can be tracked throughout the lifetime
> >of code.
> 
> Does (b) really require changes to the ELF format?

I think you could fix the problem with just a linker change.  Add
another section like .dynbss (.dynrelro maybe) that is used for
variables copied into the executable from read-only sections in shared
libraries.  Like other relro sections it could be made read-only after
relocation.

I'll note that current x86 gcc makes more use of .dynbss and copy
relocs than older versions..

> An undefined symbol reference as such cannot be turned into a copy
> relocation because it lacks size information, and the static linker needs
> object sizes to lay out the section contents (and dynamic linker needs the
> size to make the copy).  I would expect that at the same time the size is
> looked up in the static linker, the section information could be determined
> as well.
> 
> The question is whether this is the semantics we want, or if we'd prefer if
> the reference itself determines the section type, like it is already the
> case with symbol visibility.  Implementing that would need broader changes.
> 
> Thanks,
> Florian
> 
> PS: The C++ example code inf figure 4(a) has a typo, the call to the method
> b2 should probably be to b1.
> 

-- 
Alan Modra
Australia Development Lab, IBM

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Florian Weimer]

I would like to point out that the reporters followed a responsible
disclosure process, and I asked them to report this publicly.  My
reasoning was this: We are talking about a post-exploitation
countermeasure (RELRO) whose effectiveness is reduced, and there is
some amount of cross-project, cross-architecture coordination needed
here, which makes bug fixing in secret extremely inefficient.

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Mathias Payer]

[-- Attachment #1.1: Type: text/plain, Size: 3233 bytes --]



On 12/23/2016 03:35 PM, Alan Modra wrote:
> On Fri, Dec 23, 2016 at 01:58:38PM +0100, Florian Weimer wrote:
>> On 12/23/2016 12:50 PM, Mathias Payer wrote:
>>
>>> We want to report a vulnerability that is common in binaries on most
>>> Linux distributions where binaries with PIE break common security
>>> assumptions (like read-only format strings or immutable vtables).
>>
>> Thanks for sharing your research!
>>
>>> The mitigation is to (a) recompile packages with -fPIC instead of -fPIE
>>> or to (b) update the ELF format/loader linker toolchain so that
>>> permissions of individual symbols can be tracked throughout the lifetime
>>> of code.
>>
>> Does (b) really require changes to the ELF format?
> 
> I think you could fix the problem with just a linker change.  Add
> another section like .dynbss (.dynrelro maybe) that is used for
> variables copied into the executable from read-only sections in shared
> libraries.  Like other relro sections it could be made read-only after
> relocation.

At the linker level you likely don't know if the referenced symbol is RO
or not (as it could come from any object) -- only the runtime loader has
this knowledge and at that time it is too late as PIE uses relative
addressing inside the object.

There is both a potential optimization story and a security story to
this issue. When compiling with PIE, the compiler assumes a relative
local offset to these globals, when compiling with PIC, the compiler
goes through the GOT, trading off performance for flexibility.

If we store, at the compilation unit level (or at the LTO level), that a
symbol is local or not local, then it could be optimized or handled
correctly. This new information would have to be stored somewhere in the
ELF file at the level of individual objects.

> I'll note that current x86 gcc makes more use of .dynbss and copy
> relocs than older versions..

Yes, that's what we observed as well. So this problem will become more
prominent in the future. Especially when defenses like vtable
authentication or CFI will become more wide-spread, this will turn into
a security problem.

>> An undefined symbol reference as such cannot be turned into a copy
>> relocation because it lacks size information, and the static linker needs
>> object sizes to lay out the section contents (and dynamic linker needs the
>> size to make the copy).  I would expect that at the same time the size is
>> looked up in the static linker, the section information could be determined
>> as well.
>>
>> The question is whether this is the semantics we want, or if we'd prefer if
>> the reference itself determines the section type, like it is already the
>> case with symbol visibility.  Implementing that would need broader changes.

Agreed. But likely the broader changes would also allow some
optimization along the way. I guess if we can argue for both performance
and security improvements, then people would be more willing to go
through with the changes.


>> PS: The C++ example code inf figure 4(a) has a typo, the call to the method
>> b2 should probably be to b1.

Can you be more specific? I don't see a call to b2 in Fig. 4a

Thanks,
Mathias


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Florian Weimer]

On 12/23/2016 07:04 PM, Mathias Payer wrote:

> At the linker level you likely don't know if the referenced symbol is RO
> or not (as it could come from any object) -- only the runtime loader has
> this knowledge and at that time it is too late as PIE uses relative
> addressing inside the object.

The static linker necessarily sees a definition, otherwise it cannot 
produce a copy relocation because copy relocations must refer to objects 
of known size.

>>> PS: The C++ example code inf figure 4(a) has a typo, the call to the method
>>> b2 should probably be to b1.
>
> Can you be more specific? I don't see a call to b2 in Fig. 4a

I meant a2.

Thanks,
Florian

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Mathias Payer]

On December 23, 2016 7:18:29 PM GMT+01:00, Florian Weimer <fweimer@redhat.com> wrote:
>On 12/23/2016 07:04 PM, Mathias Payer wrote:
>
>> At the linker level you likely don't know if the referenced symbol is
>RO
>> or not (as it could come from any object) -- only the runtime loader
>has
>> this knowledge and at that time it is too late as PIE uses relative
>> addressing inside the object.
>
>The static linker necessarily sees a definition, otherwise it cannot 
>produce a copy relocation because copy relocations must refer to
>objects 
>of known size.

Agreed. The static linker knows about the symbol and size but not the permission. That information is discarded after compilation.

Best,
-m
-- 
Sent from the road.

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Florian Weimer]

On 12/23/2016 07:32 PM, Mathias Payer wrote:
>
>
> On December 23, 2016 7:18:29 PM GMT+01:00, Florian Weimer <fweimer@redhat.com> wrote:
>> On 12/23/2016 07:04 PM, Mathias Payer wrote:
>>
>>> At the linker level you likely don't know if the referenced symbol is
>> RO
>>> or not (as it could come from any object) -- only the runtime loader
>> has
>>> this knowledge and at that time it is too late as PIE uses relative
>>> addressing inside the object.
>>
>> The static linker necessarily sees a definition, otherwise it cannot
>> produce a copy relocation because copy relocations must refer to
>> objects
>> of known size.
>
> Agreed. The static linker knows about the symbol and size but not the permission. That information is discarded after compilation.

That's not quite true.  At least in the vtable case, the vtable is 
emitted in the .data.rel.ro section, and this information is definitely 
available to the static linker.

For your class A, the compiler emits the following vtable:

         .weak   _ZTV1A
         .section        .data.rel.ro._ZTV1A,"awG",@progbits,_ZTV1A,comdat
         .align 8
         .type   _ZTV1A, @object
         .size   _ZTV1A, 24
_ZTV1A:
         .quad   0
         .quad   _ZTI1A
         .quad   _ZN1A2a1Ev

And the static linker, when producing a DSO, puts that into the 
.data.rel.ro section.  (Otherwise, using -fPIC wouldn't server as a 
workaround.)

Thanks,
Florian

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Alan Modra]

On Fri, Dec 23, 2016 at 08:02:22PM +0100, Florian Weimer wrote:
> On 12/23/2016 07:32 PM, Mathias Payer wrote:
> >
> >
> >On December 23, 2016 7:18:29 PM GMT+01:00, Florian Weimer <fweimer@redhat.com> wrote:
> >>On 12/23/2016 07:04 PM, Mathias Payer wrote:
> >>
> >>>At the linker level you likely don't know if the referenced symbol is
> >>RO
> >>>or not (as it could come from any object) -- only the runtime loader
> >>has
> >>>this knowledge and at that time it is too late as PIE uses relative
> >>>addressing inside the object.
> >>
> >>The static linker necessarily sees a definition, otherwise it cannot
> >>produce a copy relocation because copy relocations must refer to
> >>objects
> >>of known size.
> >
> >Agreed. The static linker knows about the symbol and size but not the permission. That information is discarded after compilation.
> 
> That's not quite true.  At least in the vtable case, the vtable is emitted
> in the .data.rel.ro section, and this information is definitely available to
> the static linker.

I believe that should be the case for all dynamic symbols of interest.

Here's a prototype patch for powerpc64.  Obviously there's a lot more
work to do yet to fix all the other backends.

diff --git a/bfd/elf-bfd.h b/bfd/elf-bfd.h
index 2f0aaf6..e1f4566 100644
--- a/bfd/elf-bfd.h
+++ b/bfd/elf-bfd.h
@@ -595,6 +595,10 @@ struct elf_link_hash_table
   asection *srelgot;
   asection *splt;
   asection *srelplt;
+  asection *sdynbss;
+  asection *srelbss;
+  asection *sdynrelro;
+  asection *srelro;
   asection *igotplt;
   asection *iplt;
   asection *irelplt;
diff --git a/bfd/elf64-ppc.c b/bfd/elf64-ppc.c
index ae014e5..b9cb378 100644
--- a/bfd/elf64-ppc.c
+++ b/bfd/elf64-ppc.c
@@ -93,7 +93,7 @@ static bfd_vma opd_entry_value
 #define elf_backend_grok_prstatus	      ppc64_elf_grok_prstatus
 #define elf_backend_grok_psinfo		      ppc64_elf_grok_psinfo
 #define elf_backend_write_core_note	      ppc64_elf_write_core_note
-#define elf_backend_create_dynamic_sections   ppc64_elf_create_dynamic_sections
+#define elf_backend_create_dynamic_sections   _bfd_elf_create_dynamic_sections
 #define elf_backend_copy_indirect_symbol      ppc64_elf_copy_indirect_symbol
 #define elf_backend_add_symbol_hook	      ppc64_elf_add_symbol_hook
 #define elf_backend_check_directives	      ppc64_elf_before_check_relocs
@@ -4084,8 +4084,6 @@ struct ppc_link_hash_table
   struct ppc_link_hash_entry *dot_syms;
 
   /* Shortcuts to get to dynamic linker sections.  */
-  asection *dynbss;
-  asection *relbss;
   asection *glink;
   asection *sfpr;
   asection *brlt;
@@ -4669,31 +4667,6 @@ create_got_section (bfd *abfd, struct bfd_link_info *info)
   return TRUE;
 }
 
-/* Create the dynamic sections, and set up shortcuts.  */
-
-static bfd_boolean
-ppc64_elf_create_dynamic_sections (bfd *dynobj, struct bfd_link_info *info)
-{
-  struct ppc_link_hash_table *htab;
-
-  if (!_bfd_elf_create_dynamic_sections (dynobj, info))
-    return FALSE;
-
-  htab = ppc_hash_table (info);
-  if (htab == NULL)
-    return FALSE;
-
-  htab->dynbss = bfd_get_linker_section (dynobj, ".dynbss");
-  if (!bfd_link_pic (info))
-    htab->relbss = bfd_get_linker_section (dynobj, ".rela.bss");
-
-  if (!htab->elf.sgot || !htab->elf.splt || !htab->elf.srelplt || !htab->dynbss
-      || (!bfd_link_pic (info) && !htab->relbss))
-    abort ();
-
-  return TRUE;
-}
-
 /* Follow indirect and warning symbol links.  */
 
 static inline struct bfd_link_hash_entry *
@@ -7311,7 +7284,7 @@ ppc64_elf_adjust_dynamic_symbol (struct bfd_link_info *info,
 				 struct elf_link_hash_entry *h)
 {
   struct ppc_link_hash_table *htab;
-  asection *s;
+  asection *s, *srel;
 
   htab = ppc_hash_table (info);
   if (htab == NULL)
@@ -7441,14 +7414,22 @@ ppc64_elf_adjust_dynamic_symbol (struct bfd_link_info *info,
      to copy the initial value out of the dynamic object and into the
      runtime process image.  We need to remember the offset into the
      .rela.bss section we are going to use.  */
+  if ((h->root.u.def.section->flags & SEC_READONLY) != 0)
+    {
+      s = htab->elf.sdynrelro;
+      srel = htab->elf.srelro;
+    }
+  else
+    {
+      s = htab->elf.sdynbss;
+      srel = htab->elf.srelbss;
+    }
   if ((h->root.u.def.section->flags & SEC_ALLOC) != 0 && h->size != 0)
     {
-      htab->relbss->size += sizeof (Elf64_External_Rela);
+      srel->size += sizeof (Elf64_External_Rela);
       h->needs_copy = 1;
     }
 
-  s = htab->dynbss;
-
   return _bfd_elf_adjust_dynamic_copy (info, h, s);
 }
 
@@ -10278,7 +10259,8 @@ ppc64_elf_size_dynamic_sections (bfd *output_bfd,
 	       || s == htab->elf.splt
 	       || s == htab->elf.iplt
 	       || s == htab->glink
-	       || s == htab->dynbss)
+	       || s == htab->elf.sdynbss
+	       || s == htab->elf.sdynrelro)
 	{
 	  /* Strip this section if we don't need it; see the
 	     comment below.  */
@@ -10331,7 +10313,7 @@ ppc64_elf_size_dynamic_sections (bfd *output_bfd,
 	 but this way if it does we get a R_PPC64_NONE reloc in .rela
 	 sections instead of garbage.
 	 We also rely on the section contents being zero when writing
-	 the GOT.  */
+	 the GOT and .dynrelro.  */
       s->contents = bfd_zalloc (dynobj, s->size);
       if (s->contents == NULL)
 	return FALSE;
@@ -15615,11 +15597,13 @@ ppc64_elf_finish_dynamic_symbol (bfd *output_bfd,
   if (h->needs_copy)
     {
       /* This symbol needs a copy reloc.  Set it up.  */
+      asection *srel;
 
       if (h->dynindx == -1
 	  || (h->root.type != bfd_link_hash_defined
 	      && h->root.type != bfd_link_hash_defweak)
-	  || htab->relbss == NULL)
+	  || htab->elf.srelbss == NULL
+	  || htab->elf.srelro == NULL)
 	abort ();
 
       rela.r_offset = (h->root.u.def.value
@@ -15627,8 +15611,12 @@ ppc64_elf_finish_dynamic_symbol (bfd *output_bfd,
 		       + h->root.u.def.section->output_offset);
       rela.r_info = ELF64_R_INFO (h->dynindx, R_PPC64_COPY);
       rela.r_addend = 0;
-      loc = htab->relbss->contents;
-      loc += htab->relbss->reloc_count++ * sizeof (Elf64_External_Rela);
+      if ((h->root.u.def.section->flags & SEC_READONLY) != 0)
+	srel = htab->elf.srelro;
+      else
+	srel = htab->elf.srelbss;
+      loc = srel->contents;
+      loc += srel->reloc_count++ * sizeof (Elf64_External_Rela);
       bfd_elf64_swap_reloca_out (output_bfd, &rela, loc);
     }
 
diff --git a/bfd/elflink.c b/bfd/elflink.c
index 42bb837..a10ed07 100644
--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -427,6 +427,17 @@ _bfd_elf_create_dynamic_sections (bfd *abfd, struct bfd_link_info *info)
 					      (SEC_ALLOC | SEC_LINKER_CREATED));
       if (s == NULL)
 	return FALSE;
+      htab->sdynbss = s;
+
+      /* Similarly, but for symbols that were originally in read-only
+	 sections.  */
+      s = bfd_make_section_anyway_with_flags (abfd, ".dynrelro",
+					      (SEC_ALLOC | SEC_READONLY
+					       | SEC_HAS_CONTENTS
+					       | SEC_LINKER_CREATED));
+      if (s == NULL)
+	return FALSE;
+      htab->sdynrelro = s;
 
       /* The .rel[a].bss section holds copy relocs.  This section is not
 	 normally needed.  We need to create it here, though, so that the
@@ -448,6 +459,16 @@ _bfd_elf_create_dynamic_sections (bfd *abfd, struct bfd_link_info *info)
 	  if (s == NULL
 	      || ! bfd_set_section_alignment (abfd, s, bed->s->log_file_align))
 	    return FALSE;
+	  htab->srelbss = s;
+
+	  s = bfd_make_section_anyway_with_flags (abfd,
+						  (bed->rela_plts_and_copies_p
+						   ? ".rela.ro" : ".rel.ro"),
+						  flags | SEC_READONLY);
+	  if (s == NULL
+	      || ! bfd_set_section_alignment (abfd, s, bed->s->log_file_align))
+	    return FALSE;
+	  htab->srelro = s;
 	}
     }
 
diff --git a/ld/scripttempl/elf.sc b/ld/scripttempl/elf.sc
index f0c6439..12cfe8b 100644
--- a/ld/scripttempl/elf.sc
+++ b/ld/scripttempl/elf.sc
@@ -169,7 +169,7 @@ RELA_IPLT=".rela.iplt    ${RELOCATING-0} :
     }"
 DYNAMIC=".dynamic      ${RELOCATING-0} : { *(.dynamic) }"
 RODATA=".${RODATA_NAME}       ${RELOCATING-0} : { *(.${RODATA_NAME}${RELOCATING+ .${RODATA_NAME}.* .gnu.linkonce.r.*}) }"
-DATARELRO=".data.rel.ro : { *(.data.rel.ro.local* .gnu.linkonce.d.rel.ro.local.*) *(.data.rel.ro .data.rel.ro.* .gnu.linkonce.d.rel.ro.*) }"
+DATARELRO=".data.rel.ro : { *(.data.rel.ro.local* .gnu.linkonce.d.rel.ro.local.*) *(.data.rel.ro .data.rel.ro.* .gnu.linkonce.d.rel.ro.*) *(.dynrelro) }"
 DISCARDED="/DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) }"
 if test -z "${NO_SMALL_DATA}"; then
   SBSS=".${SBSS_NAME}         ${RELOCATING-0} :

-- 
Alan Modra
Australia Development Lab, IBM

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Mathias Payer]

[-- Attachment #1.1: Type: text/plain, Size: 1895 bytes --]

>>> The static linker necessarily sees a definition, otherwise it cannot
>>> produce a copy relocation because copy relocations must refer to
>>> objects of known size.
>>
>> Agreed. The static linker knows about the symbol and size but not the
>> permission. That information is discarded after compilation.
> 
> That's not quite true.  At least in the vtable case, the vtable is
> emitted in the .data.rel.ro section, and this information is definitely
> available to the static linker.

(If the linker validates the information from the referenced
library/object.)

> For your class A, the compiler emits the following vtable:
> 
>         .weak   _ZTV1A
>         .section        .data.rel.ro._ZTV1A,"awG",@progbits,_ZTV1A,comdat
>         .align 8
>         .type   _ZTV1A, @object
>         .size   _ZTV1A, 24
> _ZTV1A:
>         .quad   0
>         .quad   _ZTI1A
>         .quad   _ZN1A2a1Ev
> 
> And the static linker, when producing a DSO, puts that into the
> .data.rel.ro section.  (Otherwise, using -fPIC wouldn't server as a
> workaround.)


With format strings it may not work out as well. The original string is
in rodata. Let's assume the executable uses an "extern char str". The
string is then copy relocated to the BSS section in the executable.

---
  .file "test.c"
  .globl  str
  .section  .rodata
  .align 32
  .type str, @object
  .size str, 41
str:
  .string "We expect to print a decimal number: %d\n"
  .text
  .globl  externprint
  .type externprint, @function
externprint:
...
#  (call to printf)
---

When linking the main executable, the linker would have to check the
section information of the library and then infer the permissions of
that section to carry those over. Instead of copying the str into the
BSS section at runtime, the str would have to be allocated in a ro section.

Thanks,
Mathias


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Alan Modra]

On Sat, Dec 24, 2016 at 03:28:02PM +0100, Mathias Payer wrote:
> When linking the main executable, the linker would have to check the
> section information of the library and then infer the permissions of
> that section to carry those over. Instead of copying the str into the
> BSS section at runtime, the str would have to be allocated in a ro section.

Exactly.  You might like to try git master or binutils-2_28-branch,
which should be fixed for aarch64, arm, hppa, i386, metag,
microblaze, mips, mips64, nios2, or1k, ppc, ppc64, s390, s390x, sparc,
sparc64, tic6x, tilegx, tilepro and x86-64.

Note that the fix is only effective when linking with -z relro.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Cary Coutant]

> Exactly.  You might like to try git master or binutils-2_28-branch,
> which should be fixed for aarch64, arm, hppa, i386, metag,
> microblaze, mips, mips64, nios2, or1k, ppc, ppc64, s390, s390x, sparc,
> sparc64, tic6x, tilegx, tilepro and x86-64.
>
> Note that the fix is only effective when linking with -z relro.

Also fixed now in gold.

Nevertheless, I'd like to suggest that we're fixing the wrong problem.
Copy relocations have many problems, and I think we should focus more
on simply eliminating them entirely. The paper talks about that, but
only to the extent of using -fpic, which is overkill. It talks about
how Windows and macOS deal with the problem, but it overlooks some
other Unix platforms like HP-UX that do not use copy relocations at
all.

On HP-UX, the compiler can be told to assume that any undefined data
symbol may be external to the load module, and generates an indirect
reference through the linkage table (aka, GOT). The linker is able to
rewrite the indirect reference as a direct reference if it determines
that the reference is within the same load module. The rewritten
sequence involves an extra register copy, but eliminates a much more
expensive memory load. The compiler can also make the opposite
assumption, and uses "#pragma external" to flag symbols that are known
to be external and should use the indirect sequence. All system header
files on HP-UX are decorated with these pragmas for all exported
variables.

A similar technique could be used on most other platforms that today
require copy relocations. On x86-64 today, both the Gnu ld and gold
already support a similar rewrite, converting an indirect load via the
GOT into a load effective address (LEA) instruction when the target
symbol is known to be local. All the compiler needs to do is:

(a) Provide an option that will generate the PIC sequence only for
non-local data references; and/or

(b) Treat "__attribute__ ((dllimport))" or "__declspec(dllimport)" as
a hint to generate the GOT-indirect sequence, and add dllimport
attributes to exported symbols in system header files. (This is
basically the Windows approach.)

-cary


P.S. Perhaps it's just because I'm a linker person, but I found the
title of the article a bit sensationalistic. The linker isn't
*betraying* anyone, and segregating constant data into read-only
memory is really more of an alarm system that sometimes keeps the
hackers at bay after they've already found a real bug in your code
(e.g., a buffer overrun). Useful, yes, but it's no different from any
other hardening tool that doesn't catch every vulnerability in your
code.


P.P.S. For more background on copy relocations (probably more than you
want), see this thread that started on the binutils mailing list last
March:

   https://sourceware.org/ml/binutils/2016-03/msg00312.html

... continued into April ...

   https://sourceware.org/ml/binutils/2016-04/msg00012.html

... then migrated over the the gcc list ...

   https://gcc.gnu.org/ml/gcc/2016-04/msg00110.html

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Xinyang Ge]

On Tue, Dec 27, 2016 at 9:48 PM, Cary Coutant <ccoutant@gmail.com> wrote:
>
> ... then migrated over the the gcc list ...
>
>    https://gcc.gnu.org/ml/gcc/2016-04/msg00110.html

Cary,

Thanks for the pointer to the email thread.  From the conversation, it
seemed possible that the DSO and the executable can have two different
views of certain variables (presumably due to variable duplication/copy
relocation).  We have considered this possibility before but found
that as long as the DSO uses the GOT to access its exported variables,
the situation will not occur.

Do you have more details on how this situation occurred in practice?

Xinyang

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Cary Coutant]

> Thanks for the pointer to the email thread.  From the conversation, it
> seemed possible that the DSO and the executable can have two different
> views of certain variables (presumably due to variable duplication/copy
> relocation).  We have considered this possibility before but found
> that as long as the DSO uses the GOT to access its exported variables,
> the situation will not occur.
>
> Do you have more details on how this situation occurred in practice?

That would have been the case when the linker would (incorrectly, IMO)
make a copy relocation for a protected symbol, but the compiler would
use a direct reference to the local copy of the variable in the shared
library (legal because it knew the symbol was not pre-emptable). GCC
was patched (also incorrectly, IMO) to always use an indirect
reference for protected symbols, but other compilers (e.g., LLVM,
vendor compilers) were not, so it was still possible for the main
program to reference its copy-relocated copy of the variable, while a
shared library referenced its original copy. With a mixture of
compilers, it's even possible for the shared library to reference both
copies from separate places.

-cary

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Joseph Myers]

On Mon, 26 Dec 2016, Alan Modra wrote:

> On Sat, Dec 24, 2016 at 03:28:02PM +0100, Mathias Payer wrote:
> > When linking the main executable, the linker would have to check the
> > section information of the library and then infer the permissions of
> > that section to carry those over. Instead of copying the str into the
> > BSS section at runtime, the str would have to be allocated in a ro section.
> 
> Exactly.  You might like to try git master or binutils-2_28-branch,
> which should be fixed for aarch64, arm, hppa, i386, metag,
> microblaze, mips, mips64, nios2, or1k, ppc, ppc64, s390, s390x, sparc,
> sparc64, tic6x, tilegx, tilepro and x86-64.
> 
> Note that the fix is only effective when linking with -z relro.

One of these changes appears to have broken building glibc for MIPS64 (n32 
ABI; others untested) with binutils master (not tested 2.28).  Building 
with glibc's build-many-glibcs.py, using mainline GCC and binutils, I see:

collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
compilation terminated.
../Rules:192: recipe for target '/scratch/jmyers/glibc-bot/build/compilers/mips64-linux-gnu/glibc/mips64-linux-gnu-n32/iconv/iconvconfig' failed
make[3]: *** [/scratch/jmyers/glibc-bot/build/compilers/mips64-linux-gnu/glibc/mips64-linux-gnu-n32/iconv/iconvconfig] Error 1

This was working with binutils 4e008fde3ab059a011ec487686b7f3e5324c0a44:

https://sourceware.org/ml/libc-testresults/2016-q4/msg00070.html

and broken as of 5474d94f03aedba2f832006dc7d680cc15792a7b:

https://sourceware.org/ml/libc-testresults/2016-q4/msg00072.html

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Alan Modra]

On Fri, Dec 30, 2016 at 03:11:01PM +0000, Joseph Myers wrote:
> One of these changes appears to have broken building glibc for MIPS64 (n32 
> ABI; others untested) with binutils master (not tested 2.28).  Building 

Thanks for the notification.  A silly omission on my part.

	* elfn32-mips.c (elf_backend_want_dynrelro): Define.

diff --git a/bfd/elfn32-mips.c b/bfd/elfn32-mips.c
index c7ca646..ef09a14 100644
--- a/bfd/elfn32-mips.c
+++ b/bfd/elfn32-mips.c
@@ -3687,6 +3687,7 @@ static const struct ecoff_debug_swap mips_elf32_ecoff_debug_swap = {
 #define elf_backend_ecoff_debug_swap	&mips_elf32_ecoff_debug_swap
 
 #define elf_backend_got_header_size	(4 * MIPS_RESERVED_GOTNO)
+#define elf_backend_want_dynrelro	1
 
 /* MIPS n32 ELF can use a mixture of REL and RELA, but some Relocations
    work better/work only in RELA, so we default to this.  */

-- 
Alan Modra
Australia Development Lab, IBM

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Richard Henderson]

On 12/27/2016 09:48 PM, Cary Coutant wrote:
> Nevertheless, I'd like to suggest that we're fixing the wrong problem.
> Copy relocations have many problems, and I think we should focus more
> on simply eliminating them entirely. The paper talks about that, but
> only to the extent of using -fpic, which is overkill. It talks about
> how Windows and macOS deal with the problem, but it overlooks some
> other Unix platforms like HP-UX that do not use copy relocations at
> all.
>
> On HP-UX, the compiler can be told to assume that any undefined data
> symbol may be external to the load module, and generates an indirect
> reference through the linkage table (aka, GOT). The linker is able to
> rewrite the indirect reference as a direct reference if it determines
> that the reference is within the same load module. The rewritten
> sequence involves an extra register copy, but eliminates a much more
> expensive memory load. The compiler can also make the opposite
> assumption, and uses "#pragma external" to flag symbols that are known
> to be external and should use the indirect sequence. All system header
> files on HP-UX are decorated with these pragmas for all exported
> variables.
>
> A similar technique could be used on most other platforms that today
> require copy relocations.

Indeed, this is exactly what I did for alpha-elf, back in 1996.

It's a bit of a shame that we didn't do the same thing for one of the several 
reincarnations of ppc64(le)-elf, nor the initial aarch64.  Both have ISAs and 
ABIs that would not have suffered at all for having an indirect reference that 
relaxes to a direct reference iff the symbol turns out to be local.


r~

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Richard Henderson]

On 12/27/2016 09:48 PM, Cary Coutant wrote:
> Nevertheless, I'd like to suggest that we're fixing the wrong problem.
> Copy relocations have many problems, and I think we should focus more
> on simply eliminating them entirely. The paper talks about that, but
> only to the extent of using -fpic, which is overkill. It talks about
> how Windows and macOS deal with the problem, but it overlooks some
> other Unix platforms like HP-UX that do not use copy relocations at
> all.
>
> On HP-UX, the compiler can be told to assume that any undefined data
> symbol may be external to the load module, and generates an indirect
> reference through the linkage table (aka, GOT). The linker is able to
> rewrite the indirect reference as a direct reference if it determines
> that the reference is within the same load module. The rewritten
> sequence involves an extra register copy, but eliminates a much more
> expensive memory load. The compiler can also make the opposite
> assumption, and uses "#pragma external" to flag symbols that are known
> to be external and should use the indirect sequence. All system header
> files on HP-UX are decorated with these pragmas for all exported
> variables.
>
> A similar technique could be used on most other platforms that today
> require copy relocations.

Indeed, this is exactly what I did for alpha-elf, back in 1996.

It's a bit of a shame that we didn't do the same thing for one of the several 
reincarnations of ppc64(le)-elf, nor the initial aarch64.  Both have ISAs and 
ABIs that would not have suffered at all for having an indirect reference that 
relaxes to a direct reference iff the symbol turns out to be local.


r~

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Alan Modra]

On Wed, Jan 04, 2017 at 11:47:02AM -0800, Richard Henderson wrote:
> On 12/27/2016 09:48 PM, Cary Coutant wrote:
> >Nevertheless, I'd like to suggest that we're fixing the wrong problem.
> >Copy relocations have many problems, and I think we should focus more
> >on simply eliminating them entirely. The paper talks about that, but
> >only to the extent of using -fpic, which is overkill. It talks about
> >how Windows and macOS deal with the problem, but it overlooks some
> >other Unix platforms like HP-UX that do not use copy relocations at
> >all.
> >
> >On HP-UX, the compiler can be told to assume that any undefined data
> >symbol may be external to the load module, and generates an indirect
> >reference through the linkage table (aka, GOT). The linker is able to
> >rewrite the indirect reference as a direct reference if it determines
> >that the reference is within the same load module. The rewritten
> >sequence involves an extra register copy, but eliminates a much more
> >expensive memory load. The compiler can also make the opposite
> >assumption, and uses "#pragma external" to flag symbols that are known
> >to be external and should use the indirect sequence. All system header
> >files on HP-UX are decorated with these pragmas for all exported
> >variables.
> >
> >A similar technique could be used on most other platforms that today
> >require copy relocations.
> 
> Indeed, this is exactly what I did for alpha-elf, back in 1996.
> 
> It's a bit of a shame that we didn't do the same thing for one of the
> several reincarnations of ppc64(le)-elf, nor the initial aarch64.  Both have
> ISAs and ABIs that would not have suffered at all for having an indirect
> reference that relaxes to a direct reference iff the symbol turns out to be
> local.

Yeah.  The powerpc64 compiler generated GOT (TOC) makes this a bit
more difficult but GNU ld support for the ppc64 relaxation has been
there for quite a while.  We're missing support in gold (*).  I was
hoping to convert powerpc64 gcc away from using a TOC to the more
usual GOT relocs, where this sort of code editing becomes much easier.
Oh well, that never happened.

*) Over the last few days I've been cobbling together the gold
support.  Hopefully should be ready before 2.28 goes out.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)

[Cary Coutant]

> *) Over the last few days I've been cobbling together the gold
> support.  Hopefully should be ready before 2.28 goes out.

Awesome!

-cary