ELF executable binary types; dumps by executed libraries

jb.1234abcd · 2019-05-01 17:41:33

$ uname -a
Linux r61i 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20 15:00:46 UTC 2019 x86_64 GNU/Linux

$ file /usr/bin/ls
/usr/bin/ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=a8ff61ef3efee1ff8a611497215c9af0ebe181c1, stripped

$ readelf -h /usr/bin/ls
  Type:                              DYN (Shared object file)

$ hexdump -C -n 32 /usr/bin/ls
00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  03 00 3e 00 01 00 00 00  e0 5a 00 00 00 00 00 00  |..>......Z......|
00000020

per ELF layout:
displ      size     field 
0x10        2       e_type is 0300 ET_DYN, but it should be 0x0200 ET_EXEC

$ readelf -p .comment /usr/bin/ls

String dump of section '.comment':
  [     0]  GCC: (GNU) 8.2.1 20180831
  [    1a]  GCC: (GNU) 8.2.1 20181127

Why is that ?

Last edited by jb.1234abcd (2019-05-02 12:40:20)

Zod · 2019-05-01 17:46:10

What are you trying to do?

Have a look at this.

https://stackoverflow.com/questions/345 … 7#34522357[/url

Last edited by Zod (2019-05-01 17:49:29)

jb.1234abcd · 2019-05-01 17:51:32

@Zod
I am familiar with the layout.
I looked at the elf header and noticed it. Just wondering why ? Can it have any significance (source of other errors) ?

loqs · 2019-05-01 18:11:52

Errors from what specifically?

jb.1234abcd · 2019-05-01 18:32:50

@loqs
It has to do with -PIE compile option.
https://stackoverflow.com/questions/345 … cording-to

Why it could be a source of error in other places ?
I do not know, but If some other piece of software (scripts may 'grep' output of 'readelf'; they do not have access to elf.h internals like C programs to make some further interrogation),
then some decision could be made based on that alone ...
Probably worry too much :-)

Last edited by jb.1234abcd (2019-05-01 18:34:40)

loqs · 2019-05-01 18:37:59

https://gitlab.freedesktop.org/xdg/shar … /issues/11 is the only such issue I am aware of.
There may well be other cases that remain despite PIE being in use for multiple years on Arch, Fedora, Debian e.t.c.

Trilby · 2019-05-01 18:40:20

jb.1234abcd wrote:

Probably worry too much :-)

Too much, or too vaguely.

You are asking if it's possible that some output put through some poorly-crafted grep command in a poorly-written script could give results not expected by a not-so-competant script author?

If that's your question, the answer is clearly "Yes, it's possible".

Are you facing an actual problem you'd like to fix, or is this just entymoskepsis (bug navel gazing).

Last edited by Trilby (2019-05-01 18:43:52)

jb.1234abcd · 2019-05-01 19:10:24

@loqs
Yes, that bug report is a good example.

It links to:
https://bugs.freedesktop.org/show_bug.cgi?id=97226
There, one guy was worried about it:

Yann Droneaud 2017-01-14 16:16:09 UTC Comment# 4
IOTH, glibc's libc.so is a shared object with a valid interpretor, making it a valid program (try it !). Reporting such library as a program might be misleading for end user.

I just tried it for fun:

$ /usr/lib/libc-2.29.so
Segmentation fault (core dumped)

Last edited by jb.1234abcd (2019-05-02 12:33:44)

Trilby · 2019-05-01 19:21:34

FWIW:

$ /usr/lib/libc-2.29.so
GNU C Library (GNU libc) stable release version 2.29.
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 8.2.1 20181127.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
<https://bugs.archlinux.org/>.

jb.1234abcd · 2019-05-02 08:52:58

I have tested some more stuff on different OS for comparison.

Arch Linux:

$ file /usr/bin/ls
/usr/bin/ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=a8ff61ef3efee1ff8a611497215c9af0ebe181c1, stripped

$ readelf -h /usr/bin/ls
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Type:                              DYN (Shared object file)

$ file /usr/lib64/libc-2.29.so
/usr/lib64/libc-2.29.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /usr/lib/ld-linux-x86-64.so.2, BuildID[sha1]=c19c88c33b60742ca906e0f9f96fe31b8b79ea9c, for GNU/Linux 3.2.0, not stripped

$ readelf -h /usr/lib64/libc-2.29.so 
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 
  Type:                              DYN (Shared object file)

$ /usr/lib64/libc-2.29.so
Segmentation fault (core dumped)

$ file /usr/lib64/libz.so.1.2.11 
/usr/lib64/libz.so.1.2.11: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=5bbdb8b0958891549bb245beab9a1b248d97199a, stripped

$ readelf -h /usr/lib64/libz.so.1.2.11 
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Type:                              DYN (Shared object file)

$ /usr/lib64/libz.so.1.2.11
Segmentation fault (core dumped)

Fedora 29:

$ file /usr/bin/ls
/usr/bin/ls: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=ab7f7f0c5ae3308d652e6e6c9f48b11c0781e989, stripped, too many notes (256)

$ readelf -h /usr/bin/ls
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Type:                              DYN (Shared object file)

$ file /usr/lib64/libc-2.28.so 
/usr/lib64/libc-2.28.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=534a2a62ff86a0e893ef6748dff3018af42ab3ab, for GNU/Linux 3.2.0, not stripped, too many notes (256)

$ readelf -h /usr/lib64/libc-2.28.so 
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 
  Type:                              DYN (Shared object file)

$ /usr/lib64/libc-2.28.so 
GNU C Library (GNU libc) stable release version 2.28.

$ file /usr/lib64/libz.so.1.2.11 
/usr/lib64/libz.so.1.2.11: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=b896dead10dda9dd544f9551529ad2acdd1e1bab, stripped

$ readelf -h /usr/lib64/libz.so.1.2.11 
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Type:                              DYN (Shared object file)

$ /usr/lib64/libz.so.1.2.11 
Segmentation fault (core dumped)

Results:
- Arch Linux was tested on two different machines - same results
- file on 'ls' gives different results (LSB pie executable; LSB shared object)
- libc (with interpretter) gives different results w/r to dump when executed
- libz (no interpretter) dumps when executed
- Fedora 30 was released but I do not have it installed yet - it may behave differently than Fedora 29

Last edited by jb.1234abcd (2019-05-02 12:29:44)

Trilby · 2019-05-02 11:50:57

I just double checked, and in every single thread in which you've posted any commands or code, other community members have had to ask you to go back and add code tags. This is at least half a dozen times over the past 6 years. Yet you still refuse to comply with the simplest of community standards.

V1del · 2019-05-02 12:16:10

As has been mentioned, please fix the current and any future posts containing command outputs to make use of code tags.

mmdamin · 2019-05-02 12:51:45

Can I load '/usr/bin/ls' with dlopen then use its functions? As it's a shared object.

jb.1234abcd · 2019-05-02 16:27:08

@mmdamin

The default action of the ld linker is not to export symbols of PIE-compiled /usr/bin/ls, thus dlsym will fail.

Arch Linux

#1 2019-05-01 17:41:33

ELF executable binary types; dumps by executed libraries

#2 2019-05-01 17:46:10

Re: ELF executable binary types; dumps by executed libraries

#3 2019-05-01 17:51:32

Re: ELF executable binary types; dumps by executed libraries

#4 2019-05-01 18:11:52

Re: ELF executable binary types; dumps by executed libraries

#5 2019-05-01 18:32:50

Re: ELF executable binary types; dumps by executed libraries

#6 2019-05-01 18:37:59

Re: ELF executable binary types; dumps by executed libraries

#7 2019-05-01 18:40:20

Re: ELF executable binary types; dumps by executed libraries

#8 2019-05-01 19:10:24

Re: ELF executable binary types; dumps by executed libraries

#9 2019-05-01 19:21:34

Re: ELF executable binary types; dumps by executed libraries

#10 2019-05-02 08:52:58

Re: ELF executable binary types; dumps by executed libraries

#11 2019-05-02 11:50:57

Re: ELF executable binary types; dumps by executed libraries

#12 2019-05-02 12:16:10

Re: ELF executable binary types; dumps by executed libraries

#13 2019-05-02 12:51:45

Re: ELF executable binary types; dumps by executed libraries

#14 2019-05-02 16:27:08

Re: ELF executable binary types; dumps by executed libraries

Board footer