Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 18.09.2015 в 03:15, Steve Grubb написа:


I think Florian answered this. Indeed, the --debug-dump option does
find these strings, but they are mixed in with other data. I think that
if there is no canary and flags were passed, its not a problem. If the
flags are absent, the build scripts are suspect.



Hi Steve,
thanks for the pointer.  I have something which I'm not clear about.

For example:

readelf --debug-dump=info /usr/lib/debug/usr/lib64/libmemtailor.so.0.0.0.debug | 
grep "DW_AT_producer"



shows 4 lines where I can clearly see -fstack-protector-strong is used. OTOH


readelf --debug-dump=info /usr/lib/debug/usr/lib64/libmemtailor.so.0.0.0.debug | 
grep "Compilation Unit"


gives me 8 lines.


Can you briefly explain (or point me to relevant reading) what is the difference 
between the two and if it's OK to grep for the DW_AT_producer lines and look at 
the flags there.



Thanks,
Alex

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Florian Weimer]

On 09/17/2015 12:53 PM, Alexander Todorov wrote:

> Is it realistic to request a RFE with this information stored in the
> compiled object and then be read by readelf ? If so I can file bugs in
> bugzilla.redhat.com or upstream .

elfutils would be a more likely choice to implement that tool.

Note that looking for DW_AT_producer is not a complete solution.  You
also need to check that the DWARF information covers all object code.
If you lose the hardening flags, it is quite likely that you lose -g and
-grecord-gcc-switches at the same time.  A simple grep on DWARF dumps
will not show that it is missing.

-- 
Florian Weimer / Red Hat Product Security
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 17.09.2015 в 08:33, Ben Boeckel написа:

On Wed, 16 Sep, 2015 at 16:24:02 GMT, Alexander Todorov wrote:

Please let me know which packages need to genuinely be excluded and what should
we do with these packages ? Some will probably be fixed once they are rebuilt
but that may take a while.

Any package maintainers out there - please fix your packages in Rawhide so we
don't have to file bugs for all of them.


I see lots (probably all) of ghc-* packages, so filing one against
ghc-rpm-macros or ghc itself would probably be the most expedient there.
If it is just a missed flag or something, it can be rolled up with the
7.10.0 rebuild which I believe is planned for Rawhide.



FYI:
https://bugzilla.redhat.com/show_bug.cgi?id=1263957



Of course, if ghc doesn't support everything checksec looks for,
ignoring everything under %{_libdir}/ghc-*/ would be best. Jens?





For any CMake-using projects (I see at least CMake itself and ParaView
in the list), setting the `POSITION_INDEPENDENT_CODE` property[1] on
targets would fix any missing -fPIE. It is initialized with
`CMAKE_POSITION_INDEPENDENT_CODE`, so adding:

 -DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=ON

to %cmake when hardening is enabled should fix -fPIE missing. Anything
with internal static libraries *might* need a scalpel to turn off the
property on those targets.

--Ben

[1]http://www.cmake.org/cmake/help/v3.3/prop_tgt/POSITION_INDEPENDENT_CODE.html



Ben,
is there any way this CMake property be turned on globally ?


--
Alex


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 16.09.2015 в 23:05, Kaleb S. KEITHLEY написа:

On 09/16/2015 01:19 PM, Jason L Tibbitts III wrote:

"AT" == Alexander Todorov  writes:


AT> offending packages. You can find links to the script and execution
AT> log here:
AT> http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/

BTW to see if any packages you own are on the list, you can do:

wget 
https://raw.githubusercontent.com/atodorov/fedora-scripts/master/checksec.log
for i in $(pkgdb-cli list --user tibbs --nameonly); do grep "^$i.*rpm$" 
checksec.log|uniq; done



GlusterFS packages have seven "No canary found" [1]. I get the same
results with gcc-5.1.1 on f22.

However GlusterFS _is_ built with '%global _hardened_build 1' and I have
confirmed that all its sources are compiled with -fstack-protector-strong.

As I read the gcc man page for -fstack-protector,
-fstack-protector-strong, and -fstack-protector-all, it's clear that
with just -fstack-protector-strong it's entirely plausible that these
DSOs would not have the call to __stack_chk_fail, i.e. the canary.

If I compile them with -fstack-protector-all then the resulting .o and
.so files _do_ have the call to __stack_chk_fail.

Off hand I'd say that checksec's test for the canary is wanting.

The glusterfs packages need to be excluded. Or change _hardened_build to
use -fstack-protector-all.




Hi Kaleb,
thanks for pointing this out.

Can somebody comment on the -fstack-protector-all vs -fstack-protector-strong 
issue ? Do we want to change the default for %__global_cflags in 
/usr/lib/rpm/redhat/macros ?



--
Alex




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 16.09.2015 в 21:56, Adam Jackson написа:

On Wed, 2015-09-16 at 18:26 +0100, Peter Robinson wrote:


What is the proper fix to these issues? Having fixed some myself and
ajax having looked at a bunch of them I don't think it's as simple as
just mass rebuilding the packages.


A lot of it is libtool being shit, which is nothing new I suppose. I
suspect this patch will help a lot:

http://lists.gnu.org/archive/html/bug-libtool/2013-10/msg0.html

Apologies for not having looked at this for a while, I've been on a
much-needed vacation for the last few weeks. I'm going to test the
above and see if it magically fixes naive autotools builds, probably it
will.



Adam,
can you update this bug or comment on the mailing list when this is ready ?
https://bugzilla.redhat.com/show_bug.cgi?id=985592


Should we block on ^^^ before doing the mass rebuild ?


--
Alex


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Florian Weimer]

On 09/17/2015 01:03 PM, Alexander Todorov wrote:
> На 17.09.2015 в 12:26, Richard W.M. Jones написа:
>>> As far as I can see most of them report "Partial RELRO" which may
>>> well be fixed as you propose below. If not I can easily exclude
>>> them.
>>
>> They're intermediate files used by developers.  They aren't runnable
>> binaries.  I think everything in %{libdir}/ocaml should be ignored.
>>
> 
> 
> I see .o files, .so files and some .cmxs ones. Should all of them be
> ignored then ?

.o files need to have an empty .note.GNU-stack section.

If they are compiled with GCC (see the .comment section), they need to
have debugging information, and the debugging information must include
the recorded command line options.  Those command line options must have
the required hardening flags.  The debugging information must cover all
object code.

For .so files, similar rules apply, but the debug information may have
been separated.  Instead of section, the non-executable stack is now
controlled by the GNU_STACK program header.  Additionally, there most be
GNU_RELRO program header. and the relocations must not overlap with a
page that is read-write.

checksec cannot check most of this, unfortunately.

I don't know how .cmxs files are used.  They seem similar to .so files,
so the same rules apply.

-- 
Florian Weimer / Red Hat Product Security
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Steve Grubb]

On Thu, 17 Sep 2015 11:07:37 +0300
Alexander Todorov  wrote:

> Can somebody comment on the -fstack-protector-all vs
> -fstack-protector-strong issue ? Do we want to change the default for
> %__global_cflags in /usr/lib/rpm/redhat/macros ?

-all is not needed, -strong is the right balance between security and
performance. For example

int add(int a, int b)
{
return a+b;
}

Does that need a stack canary? This is the nature of why some functions
don't get a canary. Whenever knowledge of a stack frame is passed as a
pointer to a function, then -strong will kick in and do a stack check
on return. 

To know if the right thing is being done is hard to script. You really
need to see what flags are passed to each source file being compiled.
You just can't get at that from readelf.

-Steve
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 17.09.2015 в 13:34, Steve Grubb написа:

On Thu, 17 Sep 2015 11:07:37 +0300
Alexander Todorov  wrote:


Can somebody comment on the -fstack-protector-all vs
-fstack-protector-strong issue ? Do we want to change the default for
%__global_cflags in /usr/lib/rpm/redhat/macros ?


-all is not needed, -strong is the right balance between security and
performance. For example

int add(int a, int b)
{
return a+b;
}

Does that need a stack canary? This is the nature of why some functions
don't get a canary. Whenever knowledge of a stack frame is passed as a
pointer to a function, then -strong will kick in and do a stack check
on return.



Hi Steve,
thanks for the explanation.

So it looks like I should ignore stack canary warnings (assuming the package is 
using the default flags). Should this be ignore for both libraries and 
executable binaries or only libraries ? Or the answer is once again, you can't 
tell that easily ?




To know if the right thing is being done is hard to script. You really
need to see what flags are passed to each source file being compiled.
You just can't get at that from readelf.



Is it realistic to request a RFE with this information stored in the compiled 
object and then be read by readelf ? If so I can file bugs in 
bugzilla.redhat.com or upstream .



--
Alex

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Richard W.M. Jones]

On Thu, Sep 17, 2015 at 02:03:51PM +0300, Alexander Todorov wrote:
> На 17.09.2015 в 12:26, Richard W.M. Jones написа:
> >>As far as I can see most of them report "Partial RELRO" which may
> >>well be fixed as you propose below. If not I can easily exclude
> >>them.
> >
> >They're intermediate files used by developers.  They aren't runnable
> >binaries.  I think everything in %{libdir}/ocaml should be ignored.
> >
> 
> 
> I see .o files, .so files and some .cmxs ones. Should all of them be ignored 
> then ?

Yes.  Everything under here is for developers.  The .so files would
only be run under the bytecode interpreter, and Fedora only builds
those for the benefit of developers.

All Fedora-shipped OCaml applications should use native code, and go
in /usr/bin.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Steve Grubb]

On Wed, 16 Sep 2015 19:24:02 +0300
Alexander Todorov  wrote:

> Including fedora-devel on this topic.
> 
> На 12.09.2015 в 08:48, Dominik 'Rathann' Mierzejewski написа:
> >>>
> >>> Question is how to deal with these because they appear to be in
> >>> the hundreds ?
> >>
> >> How many, exactly? We have around 2 SRPMs in the distribution.
> >
> 
>  From today's Rawhide snapshot my script counted around 4500
> offending packages. You can find links to the script and execution
> log here:
> http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/
> 
> 
> Please let me know which packages need to genuinely be excluded and
> what should we do with these packages ? Some will probably be fixed
> once they are rebuilt but that may take a while.

I have studied this issue for a long time. You cannot say that a
package must have a stack canary. Its quite possible that no function
is eligible for a stack canary. In good cases, stack-protector-strong
only gives 20 - 30% function coverage. It can actually be lower. I have
hints on this in my devconf speech a couple years ago.

As for FORTIFY_SOURCE, same thing. Gcc may decide that there is no size
information available and therefore cannot have a _check function.
FORTIFY_SOURCE coverage is lower than the stack protector.

Also, the full RELRO thing is a bit oversold. You need it if the
executable is PIE, and that's not needed in the general case. There are
far worse problems that are easy to fix that are not getting attention.
With the RELRO thing, you already have to have an exploit that allows
writing arbitrary memory under attacker control. Most vulnerabilities
just don't have this quality about them.

What is more important is preventing common vulnerabilities from
achieving control over execution with simple heap and stack corruption
bugs. Hopefully we can start addressing this in F24.

-Steve
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 17.09.2015 в 12:26, Richard W.M. Jones написа:

As far as I can see most of them report "Partial RELRO" which may
well be fixed as you propose below. If not I can easily exclude
them.


They're intermediate files used by developers.  They aren't runnable
binaries.  I think everything in %{libdir}/ocaml should be ignored.




I see .o files, .so files and some .cmxs ones. Should all of them be ignored 
then ?

Looking at other replies on this thread it may even be better to focus only on 
executable binaries and as Steve Grubb says this also may not be a big deal 
after all.



--
Alex

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 17.09.2015 в 06:28, Jerry James написа:

On Wed, Sep 16, 2015 at 10:24 AM, Alexander Todorov  wrote:

Please let me know which packages need to genuinely be excluded and what
should we do with these packages ? Some will probably be fixed once they are
rebuilt but that may take a while.


Some language environments provide their own memory managers that
don't take kindly to address randomization, such as:
- gcl
- polyml
- xemacs


Hi Jerry,
how about other offenses like "No PIE" or "No canary found" ?

xemacs and polyml appear to have files with both good and bad values.


--
Alex




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Richard W.M. Jones]

On Thu, Sep 17, 2015 at 11:27:36AM +0300, Alexander Todorov wrote:
> На 16.09.2015 в 22:59, Richard W.M. Jones написа:
> >The majority of the packages of mine on this list fall into
> >three groups:
> >
> >  - erlang packages
> >
> >  - mingw packages
> >
> >  - ocaml packages
> >
> >I'm pretty sure mingw packages should all be excluded.  Who knows what
> >Windows uses (and who cares).
> >
> 
> Hi Richard,
> please correct me if I'm wrong but aren't these mingw* packages
> supposed to facilitate development of Windows applications on Linux
> ? IOW they are supposed to be working on Linux. As such I'd say they
> should also be hardened, but this is probably a low priority item.

Actually yes that's correct.  For some reason I thought it was looking
at the Windows DLLs, but it's looking at the native Linux binaries.

> >For OCaml, I think you should ignore anything under %{libdir}/ocaml/
> >since those are development files.  (Their contents may eventually end
> >up in a binary, but we can worry about that when we see the binary).
> >That removes most of the failures.
> >
> 
> As far as I can see most of them report "Partial RELRO" which may
> well be fixed as you propose below. If not I can easily exclude
> them.

They're intermediate files used by developers.  They aren't runnable
binaries.  I think everything in %{libdir}/ocaml should be ignored.

> >For OCaml binaries, it seems as if most of them are like this:
> >
> >   Partial RELRO   Canary found   NX enabled  No PIE   No RPATH  No RUNPATH  
> > ./usr/bin/ocamlc.opt
> >
> >As far as I understand it, the only problems there are "Partial RELRO"
> >which should in an ideal world be "Full RELRO"; and "No PIE".
> >
> >I guess we can fix the RELRO problem by linking with -z now.  It may
> >require a compiler patch.
> >
> 
> Please post a link if you file a bug upstream.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 16.09.2015 в 22:59, Richard W.M. Jones написа:

The majority of the packages of mine on this list fall into
three groups:

  - erlang packages

  - mingw packages

  - ocaml packages

I'm pretty sure mingw packages should all be excluded.  Who knows what
Windows uses (and who cares).



Hi Richard,
please correct me if I'm wrong but aren't these mingw* packages supposed to 
facilitate development of Windows applications on Linux ? IOW they are supposed 
to be working on Linux. As such I'd say they should also be hardened, but this 
is probably a low priority item.




Erlang code generation is an unknown quantity.


So I take this we should treat erlang packages as genuine errors until we know 
better.




For OCaml, I think you should ignore anything under %{libdir}/ocaml/
since those are development files.  (Their contents may eventually end
up in a binary, but we can worry about that when we see the binary).
That removes most of the failures.



As far as I can see most of them report "Partial RELRO" which may well be fixed 
as you propose below. If not I can easily exclude them.



For OCaml binaries, it seems as if most of them are like this:

   Partial RELRO   Canary found   NX enabled  No PIE   No RPATH  No RUNPATH  
./usr/bin/ocamlc.opt

As far as I understand it, the only problems there are "Partial RELRO"
which should in an ideal world be "Full RELRO"; and "No PIE".

I guess we can fix the RELRO problem by linking with -z now.  It may
require a compiler patch.



Please post a link if you file a bug upstream.



--
Alex

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 17.09.2015 в 06:28, Jerry James написа:

I am baffled as to why some of my packages show up on this list, as
they use %configure or invoke gcc with both $RPM_OPT_FLAGS and
$RPM_LD_FLAGS.  For example, memtailor, which I just built yesterday,
shows as lacking a canary, but it uses the %configure macro.  What is
going on there?



Probably because memtailor builds with -fstack-protector-strong, see previous 
message from Kaleb about this.


--
Alex

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Ben Boeckel]

On Thu, Sep 17, 2015 at 10:57:28 +0300, Alexander Todorov wrote:
> FYI:
> https://bugzilla.redhat.com/show_bug.cgi?id=1263957

Thanks.

> > [1]http://www.cmake.org/cmake/help/v3.3/prop_tgt/POSITION_INDEPENDENT_CODE.html
> 
> Ben,
> is there any way this CMake property be turned on globally ?

When a target is made, the POSITION_INDEPENDENT_CODE property is set to
the value of CMAKE_POSITION_INDEPENDENT_CODE and may then be overridden
manually. Anything that turns it or the property off explicitly will
have to be patched. Or do you mean more globally than "this one CMake
build"?

--Ben
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 17.09.2015 в 16:24, Ben Boeckel написа:


Ben,
is there any way this CMake property be turned on globally ?


When a target is made, the POSITION_INDEPENDENT_CODE property is set to
the value of CMAKE_POSITION_INDEPENDENT_CODE and may then be overridden
manually. Anything that turns it or the property off explicitly will
have to be patched. Or do you mean more globally than "this one CMake
build"?



I meant turning it on globally as in "everything built with CMake in Fedora", 
like updating the default flags in a RPM macro or updating the default CMake 
config in Fedora. Which will change all the packages using CMake once they are 
rebuilt.


--
Alex


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Ben Boeckel]

On Thu, Sep 17, 2015 at 16:45:46 +0300, Alexander Todorov wrote:
> I meant turning it on globally as in "everything built with CMake in Fedora", 
> like updating the default flags in a RPM macro or updating the default CMake 
> config in Fedora. Which will change all the packages using CMake once they 
> are 
> rebuilt.

Sorry, my first email may have been too subtle. From my first email:

> so adding:
>
>  -DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=ON
>
> to %cmake when hardening is enabled should fix -fPIE missing.

The %cmake macro is defined in macros.cmake which is the CMake version
of %configure. It is part of the cmake package, so a bug there would be
best.

--Ben
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Adam Jackson]

On Thu, 2015-09-17 at 12:00 +0100, Steve Grubb wrote:

> Also, the full RELRO thing is a bit oversold. You need it if the
> executable is PIE, and that's not needed in the general case. There are
> far worse problems that are easy to fix that are not getting attention.
> With the RELRO thing, you already have to have an exploit that allows
> writing arbitrary memory under attacker control. Most vulnerabilities
> just don't have this quality about them.

Honestly the security benefits are a sideshow to me. Full relro and
eager binding means that C's const keyword actually works. That alone
justifies the effort to me.

> What is more important is preventing common vulnerabilities from
> achieving control over execution with simple heap and stack corruption
> bugs. Hopefully we can start addressing this in F24.

I look forward to your patches.

- ajax
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Steve Grubb]

On Thu, 17 Sep 2015 13:53:38 +0300
Alexander Todorov  wrote:

> На 17.09.2015 в 13:34, Steve Grubb написа:
> > On Thu, 17 Sep 2015 11:07:37 +0300
> > Alexander Todorov  wrote:
> >
> >> Can somebody comment on the -fstack-protector-all vs
> >> -fstack-protector-strong issue ? Do we want to change the default
> >> for %__global_cflags in /usr/lib/rpm/redhat/macros ?
> >
> > -all is not needed, -strong is the right balance between security
> > and performance. For example
> >
> > int add(int a, int b)
> > {
> > return a+b;
> > }
> >
> > Does that need a stack canary? This is the nature of why some
> > functions don't get a canary. Whenever knowledge of a stack frame
> > is passed as a pointer to a function, then -strong will kick in and
> > do a stack check on return.
> >
> 
> Hi Steve,
> thanks for the explanation.
> 
> So it looks like I should ignore stack canary warnings (assuming the
> package is using the default flags). Should this be ignore for both
> libraries and executable binaries or only libraries ? Or the answer
> is once again, you can't tell that easily ?

Not completely. See below.


> > To know if the right thing is being done is hard to script. You
> > really need to see what flags are passed to each source file being
> > compiled. You just can't get at that from readelf.
> >
> 
> Is it realistic to request a RFE with this information stored in the
> compiled object and then be read by readelf ? If so I can file bugs
> in bugzilla.redhat.com or upstream .
> 

I think Florian answered this. Indeed, the --debug-dump option does
find these strings, but they are mixed in with other data. I think that
if there is no canary and flags were passed, its not a problem. If the
flags are absent, the build scripts are suspect.

-Steve
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

Including fedora-devel on this topic.

На 12.09.2015 в 08:48, Dominik 'Rathann' Mierzejewski написа:


Question is how to deal with these because they appear to be in the hundreds ?


How many, exactly? We have around 2 SRPMs in the distribution.




From today's Rawhide snapshot my script counted around 4500 offending packages. 
You can find links to the script and execution log here:

http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/


Please let me know which packages need to genuinely be excluded and what should 
we do with these packages ? Some will probably be fixed once they are rebuilt 
but that may take a while.


Any package maintainers out there - please fix your packages in Rawhide so we 
don't have to file bugs for all of them.



Thanks,
Alex
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Tom Hughes]

On 16/09/15 18:19, Jason L Tibbitts III wrote:


Of course, several packages I comaintain are on the list (mainly due to
Partial RELRO) and I have zero idea how to fix them.  I read about what
RELRO means from the blog post but that doesn't tell me what I actually
need to do to make the errors go away, or even how to see what's causing
them.


The key thing to get full RELO rather than partial seems to be linking 
with "-z now" but the way that happens with rpmbuild appears to be 
extremely fragile...


Basically if you use %configure and the package uses libtool then 
ltmain.sh will get edited with sed to add this to the compiler flags:


  -specs=/usr/lib/rpm/redhat/redhat-hardened-ld

In turn that specs file adds "-z now" to the linker flags.

So if you're building a package that doesn't use autoconf, or does but 
doesn't use libtool, then it likely won't happen and you will only get 
partial RELRO.


What I'm not sure about is why it's done like that rather than editing 
LDFLAGS as is done for the -zrelro that gets you partial RELRO.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Richard W.M. Jones]

On Wed, Sep 16, 2015 at 07:24:02PM +0300, Alexander Todorov wrote:
> Including fedora-devel on this topic.
> 
> На 12.09.2015 в 08:48, Dominik 'Rathann' Mierzejewski написа:
> >>>
> >>>Question is how to deal with these because they appear to be in the 
> >>>hundreds ?
> >>
> >>How many, exactly? We have around 2 SRPMs in the distribution.
> >
> 
> From today's Rawhide snapshot my script counted around 4500
> offending packages. You can find links to the script and execution
> log here:
> http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/

The majority of the packages of mine on this list fall into
three groups:

 - erlang packages

 - mingw packages

 - ocaml packages

I'm pretty sure mingw packages should all be excluded.  Who knows what
Windows uses (and who cares).

Erlang code generation is an unknown quantity.

For OCaml, I think you should ignore anything under %{libdir}/ocaml/
since those are development files.  (Their contents may eventually end
up in a binary, but we can worry about that when we see the binary).
That removes most of the failures.

For OCaml binaries, it seems as if most of them are like this:

  Partial RELRO   Canary found   NX enabled  No PIE   No RPATH  No RUNPATH  
./usr/bin/ocamlc.opt

As far as I understand it, the only problems there are "Partial RELRO"
which should in an ideal world be "Full RELRO"; and "No PIE".

I guess we can fix the RELRO problem by linking with -z now.  It may
require a compiler patch.

The OCaml compiler doesn't support PIE but it does support -fPIC.  I'm
not clear if there would be some way to link the -fPIC objects into a
PIE executable?

In general OCaml is much more robust against these kinds of attacks,
since you have to deliberately let your pointers "go wild" by using
special "unsafe_*" functions, and that's an immediate red flag when
reviewing code.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Orion Poplawski]

On 09/16/2015 11:08 AM, Orion Poplawski wrote:
> On 09/16/2015 10:24 AM, Alexander Todorov wrote:
>> From today's Rawhide snapshot my script counted around 4500 offending
>> packages. You can find links to the script and execution log here:
>> http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/
>>
>>
>> Please let me know which packages need to genuinely be excluded and what
>> should we do with these packages ? Some will probably be fixed once they are
>> rebuilt but that may take a while.
>>
>> Any package maintainers out there - please fix your packages in Rawhide so we
>> don't have to file bugs for all of them.
> 
> I think we may have an issue with libtool throwing away the
> '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' option:
> 
> /bin/sh ../libtool  --tag=CC   --mode=link gcc -ansi -pedantic -Wall -W
> -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align
> -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-prototypes
> -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs
> -Winline -O -fomit-frame-pointer -finline-functions -O2 -g -pipe -Wall
> -Werror=format-s
> ecurity -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
> -version-info 10:1 :0  -Wl,-z,relro
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o libhdf5.la -rpath /usr/lib64
> H5.lo H5Ztrans.lo  -lz -ldl -lm
> 
> libtool: link: gcc -shared  -fPIC -DPIC  .libs/H5.o ... .libs/H5Ztrans.o   -lz
> -ldl -lm  -O -O2 -g -fstack-protector-strong -grecord-gcc-switches -m64
> -mtune=generic -Wl,-z -Wl,relro   -Wl,-soname -Wl,libhdf5.so.10 -o
> .libs/libhdf5.so.10.0.1
> 

Looks like this has been known for two years:

Bug 985592 libtool + %global _hardened_build 1 = no full hardening -
https://bugzilla.redhat.com/985592

Reported upstream but no response:

http://lists.gnu.org/archive/html/bug-libtool/2013-10/msg0.html

Work around would be to use -Wc,-specs=...


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Adam Jackson]

On Wed, 2015-09-16 at 18:26 +0100, Peter Robinson wrote:

> What is the proper fix to these issues? Having fixed some myself and
> ajax having looked at a bunch of them I don't think it's as simple as
> just mass rebuilding the packages.

A lot of it is libtool being shit, which is nothing new I suppose. I
suspect this patch will help a lot:

http://lists.gnu.org/archive/html/bug-libtool/2013-10/msg0.html

Apologies for not having looked at this for a while, I've been on a
much-needed vacation for the last few weeks. I'm going to test the
above and see if it magically fixes naive autotools builds, probably it
will.

F24 has gcc 5.2.1 in package git, so I'm assuming once it builds on arm
we'll be planning a mass rebuild anyway. So if the above libtool fix
works it'll probably be sufficient to focus on non-autotools packages.
I don't know of any systemic failures like that in cmake or whatever,
but I suppose anything is possible.

- ajax

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Jerry James]

On Wed, Sep 16, 2015 at 10:24 AM, Alexander Todorov  wrote:
> Please let me know which packages need to genuinely be excluded and what
> should we do with these packages ? Some will probably be fixed once they are
> rebuilt but that may take a while.

Some language environments provide their own memory managers that
don't take kindly to address randomization, such as:
- gcl
- polyml
- xemacs

Programs that use a plugin architecture have a distressing tendency to
be broken by full RELRO.  I maintain several packages like that:
- bigloo
- clisp
- libpuma
- polybori
- polymake

Richard already talked about ocaml programs.  I've got a few of those:
- coq
- frama-c
- gappalib-coq
- ocaml-menhir
- ocaml-ocamlgraph
- ocaml-tplib
- ocaml-zarith
- why
- why3
- z3
- zenon

We do some fancy aliasing inside cddlib to allow mixing the
gmp-compiled version and the non-gmp-compiled version, since polymake
wants to link against both.  That aliasing did not interact well with
-z now when trying to build gfan, so I turned -z now off for gfan
until I can understand the problem better, or find a better way of
giving polymake what it wants.

I am baffled as to why some of my packages show up on this list, as
they use %configure or invoke gcc with both $RPM_OPT_FLAGS and
$RPM_LD_FLAGS.  For example, memtailor, which I just built yesterday,
shows as lacking a canary, but it uses the %configure macro.  What is
going on there?

Regards,
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Ben Boeckel]

On Wed, 16 Sep, 2015 at 16:24:02 GMT, Alexander Todorov wrote:
> Please let me know which packages need to genuinely be excluded and what 
> should 
> we do with these packages ? Some will probably be fixed once they are rebuilt 
> but that may take a while.
>
> Any package maintainers out there - please fix your packages in Rawhide so we 
> don't have to file bugs for all of them.

I see lots (probably all) of ghc-* packages, so filing one against
ghc-rpm-macros or ghc itself would probably be the most expedient there.
If it is just a missed flag or something, it can be rolled up with the
7.10.0 rebuild which I believe is planned for Rawhide.

Of course, if ghc doesn't support everything checksec looks for,
ignoring everything under %{_libdir}/ghc-*/ would be best. Jens?

For any CMake-using projects (I see at least CMake itself and ParaView
in the list), setting the `POSITION_INDEPENDENT_CODE` property[1] on
targets would fix any missing -fPIE. It is initialized with
`CMAKE_POSITION_INDEPENDENT_CODE`, so adding:

-DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=ON

to %cmake when hardening is enabled should fix -fPIE missing. Anything
with internal static libraries *might* need a scalpel to turn off the
property on those targets.

--Ben

[1]http://www.cmake.org/cmake/help/v3.3/prop_tgt/POSITION_INDEPENDENT_CODE.html

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Kaleb S. KEITHLEY]

On 09/16/2015 01:19 PM, Jason L Tibbitts III wrote:
>> "AT" == Alexander Todorov  writes:
> 
> AT> offending packages. You can find links to the script and execution
> AT> log here:
> AT> http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/
> 
> BTW to see if any packages you own are on the list, you can do:
> 
> wget 
> https://raw.githubusercontent.com/atodorov/fedora-scripts/master/checksec.log
> for i in $(pkgdb-cli list --user tibbs --nameonly); do grep "^$i.*rpm$" 
> checksec.log|uniq; done
> 

GlusterFS packages have seven "No canary found" [1]. I get the same
results with gcc-5.1.1 on f22.

However GlusterFS _is_ built with '%global _hardened_build 1' and I have
confirmed that all its sources are compiled with -fstack-protector-strong.

As I read the gcc man page for -fstack-protector,
-fstack-protector-strong, and -fstack-protector-all, it's clear that
with just -fstack-protector-strong it's entirely plausible that these
DSOs would not have the call to __stack_chk_fail, i.e. the canary.

If I compile them with -fstack-protector-all then the resulting .o and
.so files _do_ have the call to __stack_chk_fail.

Off hand I'd say that checksec's test for the canary is wanting.

The glusterfs packages need to be excluded. Or change _hardened_build to
use -fstack-protector-all.


[1] excerpted from
https://raw.githubusercontent.com/atodorov/fedora-scripts/master/checksec.log

...
--
glusterfs-3.7.4-2.fc24.src.rpm
/mnt/fedora/Packages/g/glusterfs-api-3.7.4-2.fc24.x86_64.rpm
RELRO   STACK CANARY  NXPIE RPATH
   RUNPATH  FILE
Full RELRO  No canary found   NX enabledDSO No RPATH
  No RUNPATH   ./usr/lib64/glusterfs/3.7.4/xlator/mount/api.so



--
glusterfs-3.7.4-2.fc24.src.rpm
/mnt/fedora/Packages/g/glusterfs-client-xlators-3.7.4-2.fc24.x86_64.rpm
RELRO   STACK CANARY  NXPIE RPATH
   RUNPATH  FILE
Full RELRO  No canary found   NX enabledDSO No RPATH
  No RUNPATH   ./usr/lib64/glusterfs/3.7.4/xlator/features/ganesha.so



--
glusterfs-3.7.4-2.fc24.src.rpm
/mnt/fedora/Packages/g/glusterfs-extra-xlators-3.7.4-2.fc24.x86_64.rpm
RELRO   STACK CANARY  NXPIE RPATH
   RUNPATH  FILE
Full RELRO  No canary found   NX enabledDSO No RPATH
  No RUNPATH   ./usr/lib64/glusterfs/3.7.4/xlator/encryption/rot-13.so
Full RELRO  No canary found   NX enabledDSO No RPATH
  No RUNPATH   ./usr/lib64/glusterfs/3.7.4/xlator/features/prot_dht.so
Full RELRO  No canary found   NX enabledDSO No RPATH
  No RUNPATH   ./usr/lib64/glusterfs/3.7.4/xlator/features/prot_server.so
Full RELRO  No canary found   NX enabledDSO No RPATH
  No RUNPATH   ./usr/lib64/glusterfs/3.7.4/xlator/features/quiesce.so
Full RELRO  No canary found   NX enabledDSO No RPATH
  No RUNPATH
./usr/lib64/glusterfs/3.7.4/xlator/testing/features/template.so


...


-- 

Kaleb
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Jason L Tibbitts III]

> "AT" == Alexander Todorov  writes:

AT> offending packages. You can find links to the script and execution
AT> log here:
AT> http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/

BTW to see if any packages you own are on the list, you can do:

wget 
https://raw.githubusercontent.com/atodorov/fedora-scripts/master/checksec.log
for i in $(pkgdb-cli list --user tibbs --nameonly); do grep "^$i.*rpm$" 
checksec.log|uniq; done

Use your FAS ID instead of mine, of course.  You can also add --poc to
the pkgdb-cli command line to limit it to just the primary maintainer.

Of course, several packages I comaintain are on the list (mainly due to
Partial RELRO) and I have zero idea how to fix them.  I read about what
RELRO means from the blog post but that doesn't tell me what I actually
need to do to make the errors go away, or even how to see what's causing
them.

 - J<
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Peter Robinson]

> На 12.09.2015 в 08:48, Dominik 'Rathann' Mierzejewski написа:


 Question is how to deal with these because they appear to be in the
 hundreds ?
>>>
>>>
>>> How many, exactly? We have around 2 SRPMs in the distribution.
>>
>>
>
> From today's Rawhide snapshot my script counted around 4500 offending
> packages. You can find links to the script and execution log here:
> http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/
>
>
> Please let me know which packages need to genuinely be excluded and what
> should we do with these packages ? Some will probably be fixed once they are
> rebuilt but that may take a while.
>
> Any package maintainers out there - please fix your packages in Rawhide so
> we don't have to file bugs for all of them.

What is the proper fix to these issues? Having fixed some myself and
ajax having looked at a bunch of them I don't think it's as simple as
just mass rebuilding the packages.

If it is as simple as a mass rebuild please co-ordinate this with
rel-eng [1] so it can be completed as part of any F-24 mass rebuild
that's needed to minimise  the churn.

Peter

[1] https://fedorahosted.org/rel-eng/newticket
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct