unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: Andreas Schwab <schwab@suse.de>, libc-alpha@sourceware.org
Subject: Re: [PATCH v3 00/32] RELRO linkmaps
Date: Tue, 12 Mar 2024 09:51:59 -0300	[thread overview]
Message-ID: <c1031f90-c32a-4a6b-a67e-94c536f5c28c@linaro.org> (raw)
In-Reply-To: <87r0gglm0z.fsf@oldenburg.str.redhat.com>



On 11/03/24 14:24, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> On 07/12/23 07:56, Florian Weimer wrote:
>>> * Andreas Schwab:
>>>
>>>> Can you please provide a summary?
>>>
>>> The original cover letter is quite elaborate:
>>>
>>>   <https://inbox.sourceware.org/libc-alpha/cover.1688499219.git.fweimer@redhat.com/>
>>>
>>> Please let me know if you need something else.
>>
>> Also could you describe with more details the possible attack that targets
>> l_info[DT_FINI] and l_infi[DT_FINI_ARRAY]?  I would like to understand
>> better the attack vector mainly because this patchset re-adds a potential
>> startup failure (the _dl_protmem_bootstrap) now that we just removed it
>> from tunable initialization.
> 
> I think this has some details:
> 
>   Nightmare: One Byte to ROP // Alternate Solution
>   <https://github.com/LMS57/Nightmare-Writeup>
> 
> I'm not sure if the first write-up that was shared with me is public.

But how feasible is this attack in real work case? Reading through the
report, it requires some access no only to the binary, but to the
runtime as well to brute force the addresses, and it also seems to
rely on lazy resolution. With this reports, it does not indicate 
how useful is this kind of attack without adding a lot of priors.

      reply	other threads:[~2024-03-12 12:52 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 10:30 [PATCH v3 00/32] RELRO linkmaps Florian Weimer
2023-12-07 10:30 ` [PATCH v3 01/32] support: Add <support/memprobe.h> for protection flags probing Florian Weimer
2024-02-22 22:39   ` Joseph Myers
2023-12-07 10:30 ` [PATCH v3 02/32] misc: Enable internal use of memory protection keys Florian Weimer
2024-02-22  1:06   ` Joseph Myers
2023-12-07 10:31 ` [PATCH v3 03/32] elf: Remove _dl_sysdep_open_object hook function Florian Weimer
2024-01-31 13:10   ` Joseph Myers
2024-03-11 17:19     ` Florian Weimer
2024-03-11 17:33       ` Joseph Myers
2024-03-11 17:46         ` Florian Weimer
2024-03-11 18:02           ` Joseph Myers
2024-03-11 18:16             ` Florian Weimer
2023-12-07 10:31 ` [PATCH v3 04/32] elf: Eliminate second loop in find_version in dl-version.c Florian Weimer
2024-02-19 22:17   ` Joseph Myers
2023-12-07 10:31 ` [PATCH v3 05/32] elf: In rtld_setup_main_map, assume ld.so has a DYNAMIC segment Florian Weimer
2024-02-19 22:18   ` Joseph Myers
2023-12-07 10:31 ` [PATCH v3 06/32] elf: Remove version assert in check_match in elf/dl-lookup.c Florian Weimer
2024-03-04 23:22   ` Joseph Myers
2023-12-07 10:31 ` [PATCH v3 07/32] elf: Disambiguate some failures in _dl_load_cache_lookup Florian Weimer
2024-02-19 23:07   ` Joseph Myers
2023-12-07 10:31 ` [PATCH v3 08/32] elf: Eliminate alloca in open_verify Florian Weimer
2024-02-19 23:26   ` Joseph Myers
2023-12-07 10:31 ` [PATCH v3 09/32] Do not export <alloc_buffer.h> functions from libc Florian Weimer
2024-02-21 17:13   ` Joseph Myers
2023-12-07 10:31 ` [PATCH v3 10/32] elf: Make <alloc_buffer.h> usable in ld.so Florian Weimer
2024-02-21 17:19   ` Joseph Myers
2023-12-07 10:31 ` [PATCH v3 11/32] elf: Merge the three implementations of _dl_dst_substitute Florian Weimer
2024-02-28 17:52   ` Joseph Myers
2023-12-07 10:31 ` [PATCH v3 12/32] elf: Move __rtld_malloc_init_stubs call into _dl_start_final Florian Weimer
2024-02-22 22:30   ` Joseph Myers
2024-02-22 23:06   ` Andreas Schwab
2023-12-07 10:31 ` [PATCH v3 13/32] elf: Merge __dl_libc_freemem into __rtld_libc_freeres Florian Weimer
2024-02-22 23:23   ` Joseph Myers
2023-12-07 10:31 ` [PATCH v3 14/32] elf: Use struct link_map_private for the internal link map Florian Weimer
2024-02-22 23:36   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 15/32] elf: Remove run-time-writable fields from struct link_map_private Florian Weimer
2024-02-23  0:09   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 16/32] elf: Move l_tls_offset into read-write part of link map Florian Weimer
2024-02-26 21:57   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 17/32] elf: Allocate auditor state after read-write " Florian Weimer
2024-02-26 22:01   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 18/32] elf: Move link map fields used by dependency sorting to writable part Florian Weimer
2024-02-27 17:51   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 19/32] elf: Split _dl_lookup_map, _dl_map_new_object from _dl_map_object Florian Weimer
2024-02-27 17:56   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 20/32] elf: Add l_soname accessor function for DT_SONAME values Florian Weimer
2024-02-27 22:14   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 21/32] elf: _dl_rtld_map should not exist in static builds Florian Weimer
2024-02-28 12:38   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 22/32] elf: Introduce GLPM accessor for the protected memory area Florian Weimer
2024-02-28 12:44   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 23/32] elf: Bootstrap allocation for future protected memory allocator Florian Weimer
2024-02-28 15:04   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 24/32] elf: Implement a basic " Florian Weimer
2024-02-28 18:46   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 25/32] elf: Move most of the _dl_find_object data to the protected heap Florian Weimer
2024-02-28 19:06   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 26/32] elf: Switch to a region-based protected memory allocator Florian Weimer
2024-03-05 23:36   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 27/32] elf: Determine the caller link map in _dl_open Florian Weimer
2024-02-28 19:23   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 28/32] elf: Add fast path to dlopen for fully-opened maps Florian Weimer
2024-02-28 19:26   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 29/32] elf: Use _dl_find_object instead of _dl_find_dso_for_object in dlopen Florian Weimer
2024-02-28 19:27   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 30/32] elf: Put critical _dl_find_object pointers into protected memory area Florian Weimer
2024-03-04 21:39   ` Joseph Myers
2023-12-07 10:32 ` [PATCH v3 31/32] elf: Add hash tables to speed up DT_NEEDED, dlopen lookups Florian Weimer
2024-03-06  0:04   ` Joseph Myers
2023-12-07 10:33 ` [PATCH v3 32/32] elf: Use memory protection keys for the protected memory allocator Florian Weimer
2024-03-06  0:11   ` Joseph Myers
2023-12-07 10:53 ` [PATCH v3 00/32] RELRO linkmaps Andreas Schwab
2023-12-07 10:56   ` Florian Weimer
2023-12-07 11:34     ` Andreas Schwab
2024-03-01 14:45     ` Adhemerval Zanella Netto
2024-03-11 17:24       ` Florian Weimer
2024-03-12 12:51         ` Adhemerval Zanella Netto [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c1031f90-c32a-4a6b-a67e-94c536f5c28c@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=schwab@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).