yara-4.3.0-rc1 test-pe fails on RHEL9 having OpenSSL with disabled SHA1 cert validation

[xambroz]

Describe the bug
When building the yara-4.3.0-rc1 the test-pe fails on RHEL9/Centos9 on the x86-64-v2 platform.

+ cat ./test-suite.log
==================================
   yara 4.3.0: ./test-suite.log
==================================
# TOTAL: 20
# PASS:  19
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: test-pe
=============
tests/test-pe.c:336: rule does not match contents of'tests/data/079a472d22290a94ebb212aa8015cdc8dd28a968c6b4d3b88acdd58ce2d3b885' (but should)
FAIL test-pe (exit status: 1)

The same test/file fails on the Fedora Rawhide + s390x platform so this might or might not be related.
#1855

To Reproduce
Steps to reproduce the behavior:
Issue demonstrates consistently on the FedoraProject Copr environment, building the yara from the https://copr.fedorainfracloud.org/coprs/rebus/infosec/package/yara/ respectively from https://github.com/xambroz/rpms-infosec/yara for the epel-9-x86_64 platform.

I guess it should be possible to reproduce it on RHEL9/Centos9 manually doing this.

dnf -y install rpm-build rpmdevtools git
git clone https://github.com/xambroz/rpms-infosec/
cd rpms-infosec/yara
sudo yum-builddep -y yara.spec --enablerepo=crb
spectool -g yara.spec
mkdir -p ~/rpmbuild/SOURCES/
ln -s $(pwd)/yara-4.3.0-rc1.tar.gz ~/rpmbuild/SOURCES/
ln -s $(pwd)/yara-docs-theme.patch ~/rpmbuild/SOURCES/
rpmbuild -ba yara.spec

Expected behavior
Test should pass (as it is passing on other platforms)

Full build log
https://download.copr.fedorainfracloud.org/results/rebus/infosec/epel-9-x86_64/05252025-yara/build.log.gz
If applicable, add screenshots to help explain your problem.

Please complete the following information:

• OS: RHEL9/Centos9 -m64 -march=x86-64-v2
• YARA version: 4.3.0-rc1

Additional context
Hardening flags used for the compilation on the RHEL9

CFLAGS='-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 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
export CFLAGS
CXXFLAGS='-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 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
export CXXFLAGS
FFLAGS='-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 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules'
export FFLAGS
FCFLAGS='-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 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules'
export FCFLAGS
LDFLAGS='-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 '
export LDFLAGS
LT_SYS_LIBRARY_PATH=/usr/lib64:

[xambroz]

I have tried to reproduce this in DigitalOcean cloud machine with Centos9 and failed. The test-pe was not failing there.
So it is more specific to some hw nuinces rather than just RHEL9/Centos9.

[xambroz]

Fails on AMD EPYC 7302 16-Core Processor

echo '===== /proc/cpu'
+ head -n 35 /proc/cpuinfo
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 23
model		: 49
model name	: AMD EPYC 7302 16-Core Processor
stepping	: 0
microcode	: 0x8301055
cpu MHz		: 2994.372
cache size	: 512 KB
physical id	: 0
siblings	: 1
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 16
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw perfctr_core ssbd ibrs ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves clzero xsaveerptr wbnoinvd arat npt nrip_save tsc_scale vmcb_clean umip rdpid arch_capabilities
bugs		: sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass retbleed
bogomips	: 5988.74
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management:
processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 23
model		: 49
model name	: AMD EPYC 7302 16-Core Processor
stepping	: 0
microcode	: 0x8301055
===== /etc/os-release
+ echo '===== /etc/os-release'
+ cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="9.1 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.1"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.1 (Plow)"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/red_hat_enterprise_linux/9/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 9"
REDHAT_BUGZILLA_PRODUCT_VERSION=9.1
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.1"
===== uname -a
+ echo '===== uname -a'
+ uname -a
Linux 0cdf3c3e2caa4afdb0e0805e8ad2a3ca 6.0.8-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 11 15:09:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Tested also on 2 Intel and 1 another AMD processor + Centos9 and the issue didn't demonstrate there.

[plusvic]

I managed to reproduce the issue in CentOS using your instructions. The problem seems related to the PE signature validation. I'll investigate further.

[plusvic]

More specifically, by removing the following 3 lines from this test case, the issue goes away.

pe.is_signed and
pe.signatures[0].verified and 
pe.signatures[0].countersignatures[0].verified

@HoundThe you may be interesting in taking a look at this. I've reproduced the issue, so if you want me to do some specific test let me know. I'll keep investigating.

[xambroz]

I am bit worried it could be some compatibility hw bug in "AMD EPYC 7302 16-Core Processor" (as it works on other x64 platforms). I have tried to change build from march from x86-64-v2 to x86-64 in suspicion it could be related to the SSE4. 2, SSSE3 instruction sets (possibly used for code signing procedures). But even doing that didn't fix the problem.

CFLAGS='-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 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
export CFLAGS

It could be potentially in the openssl/libcrypto library (optimized with march=x86-64-v2).
Or it could possibly be a compliance fault in some standard x86-64 instruction of "AMD EPYC" procesor..

[plusvic]

I can confirm that this call to PKCS7_signatureVerify is returning -1 instead of 1.

yara/libyara/modules/pe/authenticode-parser/authenticode.c

Line 302 in 26cca74

bool isValid = PKCS7_signatureVerify(p7bio, p7, si, signCert) == 1;

So, either it's a bug in YARA itself that is passing different information to this function, or it's some issue with specific versions of OpenSSL. Another option is that PKCS7_signatureVerify is relying on CA certificates installed on the machine, and a difference in the certificates installed by default on different OSes produce different results.

@HoundThe do you know if PKCS7_signatureVerify relies on CA certificates present on the machine as WinVerifyTrust does in Windows?

UPDATE: error message obtained by adding ERR_print_errors_fp(stdout); after the call to PKCS7_signatureVerify:

4077A4CD4C7F0000:error:03000098:digital envelope routines:evp_pkey_ctx_set_md:invalid digest:crypto/evp/pmeth_lib.c:959:
4077A4CD4C7F0000:error:10800069:PKCS7 routines:PKCS7_signatureVerify:signature failure:crypto/pkcs7/pk7_doit.c:1122:

[plusvic]

I've found the root cause of this issue. Searching in Google for evp_pkey_ctx_set_md:invalid digest I found this issue which coincidentally happened in RHEL9/CentOS9:

dotnet/runtime#65874

The issue above mentions that RHEL9/CentOS9 introduced a patch in OpenSSL that disables the validation of signatures based in SHA1:

https://gitlab.com/redhat/centos-stream/rpms/openssl/-/commit/78fb78d30755ae18fdaef28ef392f4e67c662ff6

By reading the changes I've noticed the introduction of an environment variable OPENSSL_ENABLE_SHA1_SIGNATURES, that controls whether SHA1 signatures are validated or not. If you run the test cases with OPENSSL_ENABLE_SHA1_SIGNATURES=yes the issue goes a away.

OPENSSL_ENABLE_SHA1_SIGNATURES=yes make check

[xambroz]

WOW ... OK ... seems you nailed it again. It really is like you said - thank you.
It seems that it was indeed some local configuration of OpenSSL on the builder machines. I guess that this finding will be soon usefull to oher platforms as well as SHA1 is phasing out everywhere, but not the PE signatures so far.

Both Koji (Intel) and Copr (AMD EPYC) builds are OK now on x86-64-2 on RHEL9:
https://copr.fedorainfracloud.org/coprs/rebus/infosec/build/5286422/
https://koji.fedoraproject.org/koji/taskinfo?taskID=96597374

[HoundThe]

Sorry for the delay, I see it solved, just to answer the question PKCS7_signatureVerify() doesn't verify the certificates chain of trust, so no CA certificates should affect it.

[jamminjames]

@plusvic, We have a RHEL 9 server with OpenSSL 3.0.7 and want to install Bacula-Community from its repo, but can't, as it needs a signed key that requires SHA-1.

To sign that key, I need to run:
rpm --import Bacula-4096-Distribution-Verification-key.asc
... but when I do, I get:

warning: Signature not supported. Hash algorithm SHA1 not available.
error: Bacula-4096-Distribution-Verification-key.asc: key 1 import failed.

So, am I to understand I could use the command
OPENSSL_ENABLE_SHA1_SIGNATURES=yes make check
and it should allow it?

When I run that command, I get:
make: *** No rule to make target 'check'. Stop.

Or how can an exception be made to install this repo? Thank you!