Hi Phil,

  I think that this is a build problem.  Possibly spec file related, although I have not checked.

  The -fstack-clash-protection flag is present when the object files are being built, but it is
  absent when the link is performed.  For example in the output you quoted in the description:

libtool: link: gcc -shared  -fPIC -DPIC  .libs/libip4tc.o   -lpcap -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -O2 -flto=auto -g -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld   -Wl,-soname -Wl,libip4tc.so.2 -o .libs/libip4tc.so.2.0.0

  Note how -fstack-clash-protection is absent from this command line.  This matters because
  the link is being performed in LTO mode, so the object files will be recompiled, and this
  time without stack clash protection enabled....

  So ... how is this libtool command line constructed ?

Cheers
  Nick

Hi, I'm seeing something similar with libknet (package kronosnet), but I can see -fstack-flash-protection on the link command-line as well as the compile commands.

Hardened: libknet.so.1.4.0: FAIL: cf-protection test because no protection enabled (function: knet_get_compress_list) 
Hardened: libknet.so.1.4.0: FAIL: stack-clash test because -fstack-clash-protection not enabled (function: knet_get_compress_list) 
Hardened: libknet.so.1.4.0: FAIL: cf-protection test because no protection enabled (function: knet_send_sync) 
Hardened: libknet.so.1.4.0: FAIL: stack-clash test because -fstack-clash-protection not enabled (function: knet_send_sync) 
Hardened: libknet.so.1.4.0: FAIL: cf-protection test because no protection enabled (function: knet_get_compress_list) 

This link command-line is from the RPM build:
/bin/sh ../libtool  --tag=CC   --mode=link gcc -O3 -ggdb3 -Werror -Wall -Wextra -Wno-unused-parameter -pthread  -pthread -DPLUGINPATH="\"/usr/lib64/kronosnet\"" -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wl,--enable-new-dtags -Wl,--as-needed -Wl,--version-script=./libknet_exported_syms -version-info 5:0:4 -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -o libknet.la -rpath /usr/lib64 libknet_la-common.lo libknet_la-compat.lo libknet_la-compress.lo libknet_la-crypto.lo libknet_la-handle.lo libknet_la-handle_api.lo libknet_la-host.lo libknet_la-lib_config.lo libknet_la-links.lo libknet_la-links_acl.lo libknet_la-links_acl_ip.lo libknet_la-links_acl_loopback.lo libknet_la-logging.lo libknet_la-netutils.lo libknet_la-onwire.lo libknet_la-threads_common.lo libknet_la-threads_dsthandler.lo libknet_la-threads_heartbeat.lo libknet_la-threads_pmtud.lo libknet_la-threads_rx.lo libknet_la-threads_tx.lo libknet_la-transports.lo libknet_la-transport_common.lo libknet_la-transport_loopback.lo libknet_la-transport_udp.lo libknet_la-transport_sctp.lo  -ldl   -lm  


Oddly I Only get this with the RPM builds and not when the library is built in-tree, even though the in-tree builds actually DON'T have -fstack-clash-protection enabled.

This command-line is from the in-tree build:
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -O3 -ggdb3 -Werror -Wall -Wextra -Wno-unused-parameter -pthread -pthread -MT libknet_la-threads_tx.lo -MD -MP -MF .deps/libknet_la-threads_tx.Tpo -c threads_tx.c  -fPIC -DPIC -o .libs/libknet_la-threads_tx.o
 (lots of other similar files cut)
libtool: link: gcc -shared  -fPIC -DPIC  .libs/libknet_la-common.o .libs/libknet_la-compat.o .libs/libknet_la-compress.o .libs/libknet_la-crypto.o .libs/libknet_la-handle.o .libs/libknet_la-handle_api.o .libs/libknet_la-host.o .libs/libknet_la-links.o .libs/libknet_la-links_acl.o .libs/libknet_la-links_acl_ip.o .libs/libknet_la-links_acl_loopback.o .libs/libknet_la-logging.o .libs/libknet_la-netutils.o .libs/libknet_la-onwire.o .libs/libknet_la-onwire_v1.o .libs/libknet_la-threads_common.o .libs/libknet_la-threads_dsthandler.o .libs/libknet_la-threads_heartbeat.o .libs/libknet_la-threads_pmtud.o .libs/libknet_la-threads_rx.o .libs/libknet_la-threads_tx.o .libs/libknet_la-transports.o .libs/libknet_la-transport_common.o .libs/libknet_la-transport_loopback.o .libs/libknet_la-transport_udp.o .libs/libknet_la-transport_sctp.o   -ldl -lm  -O3 -ggdb3 -pthread -pthread -Wl,--enable-new-dtags -Wl,--as-needed -Wl,--version-script=./libknet_exported_syms -Wl,-rpath=/usr/lib64/kronosnet   -pthread -Wl,-soname -Wl,libknet.so.2 -o .libs/libknet.so.2.0.0

Nick,

(In reply to Nick Clifton from comment #1)
>   I think that this is a build problem.  Possibly spec file related,
> although I have not checked.
> 
>   The -fstack-clash-protection flag is present when the object files are
> being built, but it is
>   absent when the link is performed.  For example in the output you quoted
> in the description:
> 
> libtool: link: gcc -shared  -fPIC -DPIC  .libs/libip4tc.o   -lpcap
> -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -O2 -flto=auto -g
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
> -mbranch-protection=standard -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld   -Wl,-soname
> -Wl,libip4tc.so.2 -o .libs/libip4tc.so.2.0.0

This is output from libtool itself. The call to libtool from the build system
is the line above, starting with '/bin/sh ../libtool  --tag=CC   --mode=link'.
There you see -fstack-clash-protection is indeed passed to the call. So it
looks like libtool is stripping the flag.

>   Note how -fstack-clash-protection is absent from this command line.  This
> matters because
>   the link is being performed in LTO mode, so the object files will be
> recompiled, and this
>   time without stack clash protection enabled....

Sounds like this is the culprit.

>   So ... how is this libtool command line constructed ?

In iptables.spec, there's just '%make_build' macro. In iptables sources, there's libiptc/Makefile.am which contains:

| lib_LTLIBRARIES     = libip4tc.la libip6tc.la
| libip4tc_la_SOURCES = libip4tc.c
| libip4tc_la_LDFLAGS = -version-info 2:0:0
| libip6tc_la_SOURCES = libip6tc.c
| libip6tc_la_LDFLAGS = -version-info 2:0:0

This does not look terribly wrong to me and the quoted call to libtool
indicates the flag makes it through the build system.

Christine,

(In reply to Christine Caulfield from comment #2)
> Hi, I'm seeing something similar with libknet (package kronosnet), but I can
> see -fstack-flash-protection on the link command-line as well as the compile
> commands.
> 
> Hardened: libknet.so.1.4.0: FAIL: cf-protection test because no protection
> enabled (function: knet_get_compress_list) 
> Hardened: libknet.so.1.4.0: FAIL: stack-clash test because
> -fstack-clash-protection not enabled (function: knet_get_compress_list) 
> Hardened: libknet.so.1.4.0: FAIL: cf-protection test because no protection
> enabled (function: knet_send_sync) 
> Hardened: libknet.so.1.4.0: FAIL: stack-clash test because
> -fstack-clash-protection not enabled (function: knet_send_sync) 
> Hardened: libknet.so.1.4.0: FAIL: cf-protection test because no protection
> enabled (function: knet_get_compress_list) 
> 
> This link command-line is from the RPM build:
> /bin/sh ../libtool  --tag=CC   --mode=link gcc -O3 -ggdb3 -Werror -Wall
> -Wextra -Wno-unused-parameter -pthread  -pthread
> -DPLUGINPATH="\"/usr/lib64/kronosnet\"" -O2 -flto=auto -ffat-lto-objects
> -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -Wl,--enable-new-dtags -Wl,--as-needed
> -Wl,--version-script=./libknet_exported_syms -version-info 5:0:4
> -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -o libknet.la -rpath
> /usr/lib64 libknet_la-common.lo libknet_la-compat.lo libknet_la-compress.lo
> libknet_la-crypto.lo libknet_la-handle.lo libknet_la-handle_api.lo
> libknet_la-host.lo libknet_la-lib_config.lo libknet_la-links.lo
> libknet_la-links_acl.lo libknet_la-links_acl_ip.lo
> libknet_la-links_acl_loopback.lo libknet_la-logging.lo
> libknet_la-netutils.lo libknet_la-onwire.lo libknet_la-threads_common.lo
> libknet_la-threads_dsthandler.lo libknet_la-threads_heartbeat.lo
> libknet_la-threads_pmtud.lo libknet_la-threads_rx.lo
> libknet_la-threads_tx.lo libknet_la-transports.lo
> libknet_la-transport_common.lo libknet_la-transport_loopback.lo
> libknet_la-transport_udp.lo libknet_la-transport_sctp.lo  -ldl   -lm  

What's the line following this one? It should be printed by libtool, starting
with "libtool: link:". Does it contain -fstack-clash-protection flag?

I'm not sure if appending your problem with libknet to this ticket is a good
idea, maybe filing a separate ticket would help prevent it from getting lost in
traffic.

(In reply to Phil Sutter from comment #3)

> There you see -fstack-clash-protection is indeed passed to the call. So it
> looks like libtool is stripping the flag.
> 
> >   Note how -fstack-clash-protection is absent from this command line.  This
> > matters because
> >   the link is being performed in LTO mode, so the object files will be
> > recompiled, and this
> >   time without stack clash protection enabled....
> 
> Sounds like this is the culprit.

In which case I would like to reassign this BZ to libtool.  Is that OK with you ?

It appears as if annobin has actually picked up a real potential security problem if these executables really are being (re-)compiled without stack clash protection.

(In reply to Christine Caulfield from comment #2)

> This link command-line is from the RPM build:
> /bin/sh ../libtool  --tag=CC   --mode=link gcc -O3 -ggdb3 -Werror -Wall
[...]
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection

If, as Phil has suggested, the -fstack-clash-protection option is also present on the following line, then please could you file a separate BZ ?  This would mean that the binaries were compiled correctly, but annocheck is wrong in saying that they were mis-built.

(In reply to Nick Clifton from comment #6)
> (In reply to Christine Caulfield from comment #2)
> 
> > This link command-line is from the RPM build:
> > /bin/sh ../libtool  --tag=CC   --mode=link gcc -O3 -ggdb3 -Werror -Wall
> [...]
> > -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> 
> If, as Phil has suggested, the -fstack-clash-protection option is also
> present on the following line, then please could you file a separate BZ ? 
> This would mean that the binaries were compiled correctly, but annocheck is
> wrong in saying that they were mis-built.

Thanks, I checked that and it looks like we are a victim of the same libtool bug as you, so I don't think I need to file a new BZ

(In reply to Nick Clifton from comment #5)
> (In reply to Phil Sutter from comment #3)
> 
> > There you see -fstack-clash-protection is indeed passed to the call. So it
> > looks like libtool is stripping the flag.
> > 
> > >   Note how -fstack-clash-protection is absent from this command line.  This
> > > matters because
> > >   the link is being performed in LTO mode, so the object files will be
> > > recompiled, and this
> > >   time without stack clash protection enabled....
> > 
> > Sounds like this is the culprit.
> 
> In which case I would like to reassign this BZ to libtool.  Is that OK with
> you ?

Yes, perfectly fine.

> It appears as if annobin has actually picked up a real potential security
> problem if these executables really are being (re-)compiled without stack
> clash protection.

Sure, this actually proves annocheck value and correctness. :)

Clearing needinfo as I think that the question has been answered.

Hi,

currently I am not able to reproduce the issue with rpminspect. I have used the latest build of iptables [1], ran rpminspect through it and received no error. Attaching log from rpminspect.

What comes in my mind, that previously gcc-11.0.1 was used, as currently gcc-11.1.1 is used, which can have effect on the problem.

Phil, Nick, can you please confirm the problem is not reproducible anymore ? If it is, can you please provide a reproducer ?

Thank you.

[1] https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=38200694

Created attachment 1803571 [details]
latest-rpminspect.txt

I am also unable to reproduce the problem with the specific version, which failed previously (iptables-1.8.7-11.el9). There was also a new version of rpminspect released and probably also used (currently 1.6, previously 1.5). I am checking this with rpminspect maintainer. I will keep you updated.

(In reply to Ondrej Dubaj from comment #10)

> Phil, Nick, can you please confirm the problem is not reproducible anymore ?
> If it is, can you please provide a reproducer ?

I cannot reproduce it. :-}

I think that the problem was fixed by the 9.78 update of annobin, (which was created to fix #1958954).

The issue was that when compiling in LTO mode the compiler is run twice.  Once when the object files are built and then again when the final link takes place.  I mistakenly thought that security options like -fstack-clash-protection had to be specified during the second compilation, and if they were not, then the annobin plugin would record them as missing.  It turns out however that these options only need to be specified during the first compilation, not the second.  So the 9.78 annobin update fixes the plugin to handle this situation.

Thank you for clarification! Closing this as NOTABUG.

Yes, the problem is gone.

Hello, I see the problem on RHEL 9 compose on all architectures, filed as bug 1988402.