Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-152223

samba-4.23.5-105.el10 — all 41 shared objects and smbd binary missing stack canary and FORTIFY_SOURCE despite %_hardened_build 1

Linking RHIVOS CVEs to...Migration: Automation ...Sync from "Extern...XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Blocker Blocker
    • None
    • CentOS Stream 10
    • samba
    • None
    • None
    • None
    • rhel-idm-uah
    • None
    • None
    • None
    • None
    • None
    • x86_64
    • None

      What were you trying to do that didn't work?

      Auditing RPM packages for binary hardening compliance. The samba package requests a hardened build via %global _hardened_build 1 and passes -with-pie and -with-relro to waf. PIE and RELRO are correctly applied. However, no binary or shared object in the package has stack canary protection (-fstack-protector-strong) or FORTIFY_SOURCE, indicating that waf is not consuming CFLAGS from the RPM build environment for these flags.

      What is the impact of this issue to you?

      samba is the most prominent network-facing daemon in the RHEL ecosystem — SMB file sharing, Active Directory, DCE/RPC — all parsing untrusted network input from remote clients. The package has a documented history of memory corruption vulnerabilities including CVE-2023-5568 (heap buffer overflow) and CVE-2023-34967 (type confusion).

      Without stack canary protection, a stack-based buffer overflow in any samba code path would not be detected at runtime, allowing exploitation without defeating this mitigation. Without FORTIFY_SOURCE, buffer operations that could be checked at compile time are not. These two missing mitigations make exploitation of any future memory corruption vulnerability significantly easier.

      The spec file clearly intends hardened builds:

      • %global _hardened_build 1 is set
      • --with-pie is passed to waf (working — binaries are DYN/PIE)
      • --with-relro is passed to waf (working — BIND_NOW is set)

      But waf does not appear to pick up -fstack-protector-strong or -D_FORTIFY_SOURCE=2 from %{optflags} / CFLAGS, resulting in a gap between intended and actual hardening.

      Please provide the package NVR for which the bug is seen:

      samba-4.23.5-105.el10.x86_64 (also affects samba-libs-4.23.5-105.el10.x86_64)

      How reproducible is this bug?:

      Always — affects every binary in the package.

      Steps to reproduce

      1. Extract the samba package: rpm2cpio samba-4.23.5-105.el10.x86_64.rpm | cpio -idm
      2. Check the main daemon: readelf -s usr/sbin/smbd | grep stack_chk — no output (no stack canary)
      3. Check FORTIFY: readelf -s usr/sbin/smbd | grep FORTIFY — no output
      4. Verify PIE works: readelf -h usr/sbin/smbd | grep Type — shows DYN (PIE enabled, correct)
      5. Verify RELRO works: readelf -d usr/sbin/smbd | grep BIND_NOW — present (correct)
      6. Check all shared objects: for so in $(find . -name "*.so" -type f); do readelf -s "$so" 2>/dev/null | grep -q stack_chk || echo "UNPROTECTED: $so"; done — all 41 .so files are unprotected
      7. Review spec file at https://gitlab.com/redhat/centos-stream/rpms/samba/-/blob/c10s/samba.spec — note %global _hardened_build 1, -with-pie, -with-relro are all present

      Expected results

      All samba binaries and shared objects should be compiled with fstack-protector-strong and -D_FORTIFY_SOURCE=2, consistent with the %_hardened_build 1 directive in the spec file and standard RHEL binary hardening policy. Waf should receive these flags via CFLAGS, or the spec file should explicitly pass them via waf-specific options (analogous to with-pie and -with-relro).

      Actual results

      PIE and RELRO are correctly applied via waf-specific flags. However, stack canary and FORTIFY_SOURCE are absent from all 41 shared objects and the main smbd binary. The RPM CFLAGS containing -fstack-protector-strong and -D_FORTIFY_SOURCE=2 are not being consumed by waf's build system, resulting in two of four standard hardening mitigations missing from the most network-exposed daemon in the RHEL package set.

       

      Note - likely affects all architectures since the waf CFLAGS issue is arch-independent.

              anschnei@redhat.com Andreas Schneider
              rh-ee-clusk Christopher Lusk
              Andreas Schneider Andreas Schneider
              Martin Myska Martin Myska
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated: