Bug 1238804 - /usr/bin/perl is not linked with -z now and -pie, perl crashes with -pie
Summary: /usr/bin/perl is not linked with -z now and -pie, perl crashes with -pie
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: perl
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Pisar
QA Contact: Fedora Extras Quality Assurance
URL: http://permalink.gmane.org/gmane.linu...
Whiteboard:
: 984185 1283947 (view as bug list)
Depends On:
Blocks: harden-failure 1242769 1242802
TreeView+ depends on / blocked
 
Reported: 2015-07-02 16:15 UTC by Petr Pisar
Modified: 2017-08-07 06:04 UTC (History)
14 users (show)

Fixed In Version: perl-5.26.0-392.fc27
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-07 06:04:02 UTC


Attachments (Terms of Use)
screenshot bugzilla (112.56 KB, image/png)
2016-11-24 12:30 UTC, Harald Reindl
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1478470 None CLOSED Full RELRO check does not support new dtags 2018-12-17 15:01:04 UTC

Internal Links: 1478470

Description Petr Pisar 2015-07-02 16:15:47 UTC
/usr/bin/perl is not linked with -z now. The -z now is defined by -specs=/usr/lib/rpm/redhat/redhat-hardened-ld:

gcc -o libperl.so -shared -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib -Wl,-soname -Wl,libperl.so.5.22 op.o perl.o  gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o  perldtrace.o DynaLoader.o -lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc
Processing extracted/DCombiningClass.txt
Processing extracted/DNumType.txt
gcc -o perl -fstack-protector-strong -L/usr/local/lib -Wl,--enable-new-dtags perlmain.o  libperl.so `cat ext.libs` -lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc

The reason is we configure perl as:

/bin/sh Configure -des -Doptimize="$RPM_OPT_FLAGS" \
        -Dccdlflags="-Wl,--enable-new-dtags" \
        -Dlddlflags="-shared $RPM_OPT_FLAGS $RPM_LD_FLAGS" \

The $RPM_LD_FLAGS should go into ccdlflags too. ccdlflags is for linking programs dynamycally, lddlflags if for linking libraries dynamically.

Configure supports ldflags, but I worry this is has to be actively used by Makefile.PLs, so it is not much helpful.

Comment 1 Petr Pisar 2015-07-16 07:02:20 UTC
The issue is some perl packages fails tests or the interpreter segfaults if /usr/bin/perl is linked with -pie option.

This must be fixed or reverted.

Comment 2 Petr Pisar 2015-07-16 13:37:19 UTC
Known failures:

smartmatch-engine-core: tests segfaul on x86_64
perl-Algorithm-CurveFit: tests fails in this pure Perl code
perl-B-Utils: tests fail on x86
perl-PDL-Graphics-PLplot: tests segfault on x86_64

I will disable hardening in perl.spec and I will work with upstream and Fedora toolchain maintainers to identify and fix the cause.

Comment 3 Petr Pisar 2015-07-16 15:20:25 UTC
Hardening disabled in:

perl-5.22.0-349.fc23
perl-5.22.0-349.fc24

Comment 4 Petr Pisar 2015-11-20 11:34:26 UTC
*** Bug 1283947 has been marked as a duplicate of this bug. ***

Comment 5 Harald Reindl 2015-12-05 13:45:26 UTC
PIE is one thing

Full RELRO is another one
http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html


[root@localhost:~]$ hardening-check /usr/bin/perl
/usr/bin/perl:
 Position Independent Executable: no, normal executable!
 Stack protected: no, not found!
 Fortify Source functions: unknown, no protectable libc functions used
 Read-only relocations: yes
 Immediate binding: no, not found!

Comment 6 Fedora End Of Life 2016-11-24 11:59:09 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 7 Harald Reindl 2016-11-24 12:08:57 UTC
and why can't i change the realse from 23 to 24 here?

Comment 8 Petr Pisar 2016-11-24 12:27:31 UTC
You can.

Comment 9 Harald Reindl 2016-11-24 12:30:12 UTC
Created attachment 1223847 [details]
screenshot bugzilla

no i can't - see screenshot - on top of this bugreport all options are missing

Comment 10 Petr Pisar 2016-11-24 13:18:22 UTC
I have no idea what's wrong.

Comment 11 Emmanuel Seyman 2016-11-24 13:37:24 UTC
(In reply to Harald Reindl from comment #7)
> and why can't i change the realse from 23 to 24 here?

The two main possibilities are:

1) Bugzilla sees you as logged out despite the fact that you're logged in.

2) You're logged in but don't have the necessary permissions to edit this bug.

You can check your permissions at https://bugzilla.redhat.com/userprefs.cgi?tab=permissions

Comment 12 Petr Pisar 2017-07-26 09:05:59 UTC
*** Bug 984185 has been marked as a duplicate of this bug. ***

Comment 13 Petr Pisar 2017-08-04 11:53:48 UTC
/usr/bin/perl is now built with all necessary options, but the resulting executable differs from other executables:

$ readelf -d /usr/bin/rpm | grep NOW
 0x0000000000000018 (BIND_NOW)           
 0x000000006ffffffb (FLAGS_1)            Flags: NOW PIE
$ readelf -d /usr/bin/perl | grep NOW
 0x000000000000001e (FLAGS)              BIND_NOW
 0x000000006ffffffb (FLAGS_1)            Flags: NOW PIE

I need to figure out if this is a problem or not.

Comment 14 Harald Reindl 2017-08-04 12:16:31 UTC
BIND_NOW is -z now aka "Full RELRO"
http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html

it's peferred but not always possible

Comment 15 Petr Pisar 2017-08-04 15:20:59 UTC
I've already got response from Florian Weimer. Because the perl was built with -Wl,--enable-new-dtags, the way how binding metadata are expresses is a little bit different, but still perfectly valid and secure.

Comment 16 Petr Pisar 2017-08-04 15:43:31 UTC
I reported bug #1478470 against rpmgrill.


Note You need to log in before you can comment on or make changes to this bug.