Bug 2284605
Summary: | Ruby is not recognized as hardened | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Vít Ondruch <vondruch> |
Component: | annobin | Assignee: | Nick Clifton <nickc> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | fweimer, jakub, josmyers, nickc, sipoyare, yahmad |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2024-07-11 07:56:30 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Vít Ondruch
2024-06-03 14:52:29 UTC
(In reply to Vít Ondruch from comment #0) Hi Vit, > Just checking fedora-ci.koji-build.rpminspect.static-analysis results [1] > for latest Ruby build, I have noticed that Ruby is not reported as hardened > anymore. Specifically, this is the error: > Hardened: /usr/lib64/libruby.so.3.3.1: FAIL: cf-protection test because > .note.gnu.property section did not contain the necessary flags Yeah - this is sort of an annocheck bug and sort of a Rust problem. The lack of a .note.gnu.property section does indeed mean that that control flow protection is disabled. For Rust code this should not matter as rust is safe enough that it does not need control flow protection. (Well in theory at least). The problem is that libruby.so.3.3.1 contains both code written in Rust and code written in C. The C parts are vulnerable and so control flow protection is a good idea for them. But ... control flow protection is an all or nothing feature. All of the code must be compiled with control flow enabled - and then the protection can be enabled. But if even a single piece of code is compiled without the feature then the protection cannot be enabled. (This is because the feature inserts new instructions at the destination of all branches and procedure calls. If the CPU detects a branch/call to a location that is missing this new instruction it aborts the process. Hence all code must be compiled correctly for the feature to work). So essentially, until the Rust compiler supports the x86_64 control flow feature any part-C/part-Rust executables are going to be vulnerable. Annocheck is supposed to know about this and SKIP the cf-protection test when it finds mixed Rust/C code, but currently it doesn't. (It does skip the test for entirely for executables that are entirely written in Rust). For now I recommend that you waive this result. (I am working on an update to annocheck which will fix the cf-protection test so that it is skipped for mixed C/Rust binaries). > This is detailed output for the `Context.o`: > But this file is written in assembly: > https://github.com/ruby/ruby/blob/17b89849c6076777ccfd014f191f8c97f81f8cae/ > coroutine/amd64/Context.S This is going to be a future problem. Once Rust does support generating the control flow instructions, the Context.S file will still stop the feature from being enabled, since it too needs to be updated. Fortunately there are instructions on how to do this here: https://sourceware.org/annobin/annobin.html/Test-cf-protection.html I hope that this helps. Cheers Nick (In reply to Nick Clifton from comment #1) > (In reply to Vít Ondruch from comment #0) > Hi Vit, > > > Just checking fedora-ci.koji-build.rpminspect.static-analysis results [1] > > for latest Ruby build, I have noticed that Ruby is not reported as hardened > > anymore. Specifically, this is the error: > > > Hardened: /usr/lib64/libruby.so.3.3.1: FAIL: cf-protection test because > > .note.gnu.property section did not contain the necessary flags > > Yeah - this is sort of an annocheck bug and sort of a Rust problem. But this is then also sort of Ruby problem, because use of Rust in the code base is new thing. IOW I can report to Ruby upstream that since the moment Rust was added to the mix, CF is disabled an that is undesirable. > For now I recommend that you waive this result. (I am working on an > update to annocheck which will fix the cf-protection test so that it > is skipped for mixed C/Rust binaries). Do you by a chance have any timeframe for this? > > This is detailed output for the `Context.o`: > > But this file is written in assembly: > > https://github.com/ruby/ruby/blob/17b89849c6076777ccfd014f191f8c97f81f8cae/ > > coroutine/amd64/Context.S > > This is going to be a future problem. Once Rust does support generating > the control flow instructions I think that the Rust bits can be disabled via configuration option. I'll probably try that and report this upstream separately (and attach the link bellow). > the Context.S file will still stop the > feature from being enabled, since it too needs to be updated. Fortunately > there are instructions on how to do this here: > > https://sourceware.org/annobin/annobin.html/Test-cf-protection.html > > I hope that this helps. Definitely. Thx a lot! (In reply to Vít Ondruch from comment #2) > But this is then also sort of Ruby problem, because use of Rust in the code > base is new thing. IOW I can report to Ruby upstream that since the moment > Rust was added to the mix, CF is disabled an that is undesirable. If you think that it will help, then please do. I am not sure how much pressure the Ruby community can exert on the Rust compiler development process, but any > Do you by a chance have any timeframe for this? Today-ish :-) The rawhide build is complete: annobin-12.57-1.fc41 I assume that it will hit the buildroot soon and then pulled into the rpminspect framework (for rawhide). The F40 and F39 builds are in progress, but once they are complete there will still be the Bodhi process to complete, so they will probably become available next week. Cheers Nick (In reply to Nick Clifton from comment #3) > (In reply to Vít Ondruch from comment #2) > > > But this is then also sort of Ruby problem, because use of Rust in the code > > base is new thing. IOW I can report to Ruby upstream that since the moment > > Rust was added to the mix, CF is disabled an that is undesirable. > > If you think that it will help, then please do. I am not sure how much > pressure > the Ruby community can exert on the Rust compiler development process, but > any The thing is Ruby is supposed to support hardening, but apparently nobody checks in the upstream. That is the main problem. And if Rust is problematic, it should have been one of consideration and I doubt it was. And of course, just wider knowledge of the problem might put some pressure on Rust. > > Do you by a chance have any timeframe for this? > > Today-ish :-) > > The rawhide build is complete: annobin-12.57-1.fc41 > > I assume that it will hit the buildroot soon and then pulled into the > rpminspect > framework (for rawhide). > > The F40 and F39 builds are in progress, but once they are complete there will > still be the Bodhi process to complete, so they will probably become > available > next week. Oh wow, you rocks! (In reply to Vít Ondruch from comment #2) > > This is going to be a future problem. Once Rust does support generating > > the control flow instructions > > I think that the Rust bits can be disabled via configuration option. I'll > probably try that and report this upstream separately (and attach the link > bellow). The rust flag to enable cf-protection is unstable at the moment, which is why it is not yet in use by default in Fedora. (In reply to Vít Ondruch from comment #2) > (In reply to Nick Clifton from comment #1) > > (In reply to Vít Ondruch from comment #0) > > > This is detailed output for the `Context.o`: > > > But this file is written in assembly: > > > https://github.com/ruby/ruby/blob/17b89849c6076777ccfd014f191f8c97f81f8cae/ > > > coroutine/amd64/Context.S > > > > This is going to be a future problem. Once Rust does support generating > > the control flow instructions > > I think that the Rust bits can be disabled via configuration option. I'll > probably try that and report this upstream separately (and attach the link > bellow). I have build Ruby RPM with `--without=yjit`, that excludes the Rust bits and yes, it seems the `Context.o` is the only problem then: ~~~ $ annocheck redhat-linux-build/* 2>/dev/null | grep FAIL | less Hardened: Context.o: Overall: FAIL (due to MAYB results). Hardened: libruby-static.a:Context.o: Overall: FAIL (due to MAYB results). Hardened: libruby.so.3.3.1: FAIL: cf-protection test because .note.gnu.property section did not contain the necessary flags Hardened: libruby.so.3.3.1: FAIL: property-note test because a property note was found but it shows that cf-protection is not enabled Hardened: libruby.so.3.3.1: Overall: FAIL. Hardened: miniruby: FAIL: cf-protection test because .note.gnu.property section did not contain the necessary flags Hardened: miniruby: FAIL: property-note test because a property note was found but it shows that cf-protection is not enabled Hardened: miniruby: Overall: FAIL. ~~~ Reported upstream: https://bugs.ruby-lang.org/issues/20527 (In reply to Vít Ondruch from comment #6) > Reported upstream: https://bugs.ruby-lang.org/issues/20527 There is actually older report: https://bugs.ruby-lang.org/issues/18061 (In reply to Siddhesh Poyarekar from comment #5) > The rust flag to enable cf-protection is unstable at the moment, which is > why it is not yet in use by default in Fedora. Is this tracked somewhere? (In reply to Vít Ondruch from comment #8) > (In reply to Siddhesh Poyarekar from comment #5) > > The rust flag to enable cf-protection is unstable at the moment, which is > > why it is not yet in use by default in Fedora. > > Is this tracked somewhere? Setting need info just to get answer for this. Because otherwise, this is resolved: https://bodhi.fedoraproject.org/updates/FEDORA-2024-0cfdd7d439 https://artifacts.dev.testing-farm.io/23ebe952-c1cd-4597-a0d6-73d9a0aa1297/ Here's the upstream issue that tracks stabilization of the cf-protection flag: https://github.com/rust-lang/rust/issues/93754 (In reply to Siddhesh Poyarekar from comment #10) > Here's the upstream issue that tracks stabilization of the cf-protection > flag: https://github.com/rust-lang/rust/issues/93754 Thx a lot 👍 |