Project

General

Profile

Bug #15335

Ruby 2.6.0 is not properly fortified

Added by vo.x (Vit Ondruch) 12 months ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Target version:
-
ruby -v:
ruby 2.6.0dev (2018-11-22 trunk 65928) [x86_64-linux]
[ruby-core:90000]

Description

For some while, we carry this test in Fedora package 1:

checksec -f libruby.so.%{ruby_version} | \  
  grep "Full RELRO.*Canary found.*NX enabled.*DSO.*No RPATH.*No RUNPATH.*Yes.*\d*.*\d*.*libruby.so.%{ruby_version}"

This should ensure, that the library is properly fortified 2. This test was passing with preview3, but it started to fail, testing with r65928:

$ checksec -f libruby.so.2.6.0
WARNING: 'openssl' not found! It's required for most checks.

WARNING: Not all necessary commands found. Some tests might not work!

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH  FORTIFY Fortified Fortifiable  FILE
Full RELRO      Canary found      NX disabled   DSO             No RPATH   No RUNPATH   Yes 16      42  libruby.so.2.6.0

The NX disabled is the difference. Looking at the log, it is definitely not about configuration options. So if I should point finger at something, it seems to me that this must be it:

... snip ...

assembling coroutine/amd64/Context.s
gcc -I. -I.ext/include/x86_64-linux -I./include -I. -I./enc/unicode/10.0.0 -o coroutine/amd64/Context.o -c coroutine/amd64/Context.s

... snip ...

gcc -shared -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-soname,libruby.so.2.6 -fstack-protector-strong  -m64 dln.o localeinit.o loadpath.o array.o ast.o bignum.o class.o compar.o compile.o complex.o cont.o debug.o debug_counter.o dir.o dln_find.o encoding.o enum.o enumerator.o error.o eval.o file.o gc.o hash.o inits.o io.o iseq.o load.o marshal.o math.o mjit.o mjit_compile.o node.o numeric.o object.o pack.o parse.o proc.o process.o random.o range.o rational.o re.o regcomp.o regenc.o regerror.o regexec.o regparse.o regsyntax.o ruby.o safe.o signal.o sprintf.o st.o strftime.o string.o struct.o symbol.o thread.o time.o transcode.o transient_heap.o util.o variable.o version.o vm.o vm_backtrace.o vm_dump.o vm_trace.o coroutine/amd64/Context.o probes.o enc/ascii.o enc/us_ascii.o enc/unicode.o enc/utf_8.o enc/trans/newline.o setproctitle.o strlcat.o strlcpy.o addr2line.o  prelude.o dmyext.o dmyenc.o -lpthread -lrt -lrt -lgmp -ldl -lcrypt -lm   -o libruby.so.2.6.0

... snip ...

I.e. the coroutines assembly. Not sure how to prove it nor fix it.

Associated revisions

Revision dc6908ab
Added by samuel 11 months ago

Ensure x86 stack is fortified, fixed #15335.

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66341 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

Revision 66341
Added by samuel 11 months ago

Ensure x86 stack is fortified, fixed #15335.

Revision 66341
Added by samuel 11 months ago

Ensure x86 stack is fortified, fixed #15335.

History

Updated by mame (Yusuke Endoh) 12 months ago

  • Assignee set to ioquatix (Samuel Williams)
  • Status changed from Open to Assigned

Updated by ioquatix (Samuel Williams) 12 months ago

How can we solve this problem?

Updated by normalperson (Eric Wong) 12 months ago

https://bugs.ruby-lang.org/issues/15335#change-75132

samuel@oriontransfer.net wrote:

How can we solve this problem?

Fedora can configure with --disable-fiber-coroutine option
as a stopgap...

I.e. the coroutines assembly. Not sure how to prove it nor fix it.

Maybe this can help?
https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart

Updated by ioquatix (Samuel Williams) 12 months ago

Thanks Eric. Those two suggestions are really helpful. I'll investigate it now.

Updated by ioquatix (Samuel Williams) 12 months ago

I'm attempting to fix this issue here: https://github.com/ruby/ruby/pull/2027

vo.x (Vit Ondruch) do you mind trying to build that PR?

Updated by ioquatix (Samuel Williams) 12 months ago

I've merged the first set of changes into trunk, for amd64 - vo.x (Vit Ondruch) if you confirm this has fixed the issue I will extend to other architectures.

Updated by vo.x (Vit Ondruch) 12 months ago

Thx. I hope I'll be able to check it on Monday.

Updated by vo.x (Vit Ondruch) 12 months ago

Testing with r65990 on x86_64 and the test passed. I guess I should not try to build on other arches yet, right?

Updated by vo.x (Vit Ondruch) 12 months ago

Just FTR trying to build r66092 on Fedora Rawhide 1, x86_64, ppc64le, aarch64, s390x, and armv7hl were properly fortified while only i686 failed to pass 2 the fortification test.

#10

Updated by Anonymous 11 months ago

  • Status changed from Assigned to Closed

Applied in changeset trunk|r66341.


Ensure x86 stack is fortified, fixed #15335.

Updated by ioquatix (Samuel Williams) 11 months ago

I've fixed x86 implementation too, now that it was confirmed the previous effort to fix x64 worked as expected. This issue should be completely resolved now (dc6908ab44c3a3fc78319422410b57d3b7fb6c0c / r66341).

Updated by vo.x (Vit Ondruch) 10 months ago

ioquatix (Samuel Williams) wrote:

I've fixed x86 implementation too.

Thx, I can build Ruby 2.6.0 on all platforms just fine.

Also available in: Atom PDF