** Description changed:

  [ Impact ]
  
  Remote desktop users authenticating with smartcards can observe crashes in the
  sssd_pam responder due to a use-after-free.
  
  The bug stores a pointer when starting the sssd `p11_child` and dereferences
  that pointer when the `p11_child` completes. However, the pointer may be freed
  by a domain refresh while the `p11_child` is still running, causing a crash
  (this manifests as a GPF in my lab and SEGV for the reporting user).
  
  Remote desktop users are more likely to be affected because the additional
  latency between the smartcard and the machine increases the time the 
`p11_child`
  takes to complete. The issue can be reliably reproduced by artificially
  inflating the runtime of the `p11_child`.
  
  This bug was assigned CVE-2026-12610 as it represents a potential DoS against
  the sssd_pam responder.
  
- [1]
- https://github.com/SSSD/sssd/commit/fa7a55949a30fed064a28ea6f0c801fc5e8c5ba7
+ [1] 
https://github.com/SSSD/sssd/commit/fa7a55949a30fed064a28ea6f0c801fc5e8c5ba7
+ [2] https://www.cve.org/CVERecord?id=CVE-2026-12610
  
  [ Test Plan ]
  
  Testing the fix requires a Yubikey which supports PIV authentication; the
  following assumes that a Yubikey has already been set up with a signed
  certificate using `yubico-piv-tool` or equivalent.
  
  Launch a LXD VM and use `lxc console --type vga` to pass your Yubikey into the
- VM from the host.
- 
- ```sh
- sudo apt install opensc-pkcs11 pcscd sssd sssd-tools libpam-sss pamtester
+ VM from the host (note that the default LXD images for Jammy use the old kvm
+ kernel by default which doesn't have USB drivers; install the generic or
+ generic-hwe kernel to use this method on Jammy).
+ 
+ ```sh
+ sudo apt install opensc-pkcs11 pcscd sssd sssd-tools libpam-sss 
libyubikey-udev pamtester
  ```
  
  Following the Ubuntu Server documentation [1], enable sssd_pam in
  `/etc/sssd/sssd.conf`:
  
  Noble & older:
  
  ```ini
  [sssd]
  enable_files_domain = True
  services = nss, pam
  
  [pam]
  pam_cert_auth = True
  ```
  
  Resolute & newer:
  
  ```ini
  [sssd]
  services = nss, pam
+ domains = files_domain
  
  [domain/files_domain]
  id_provider = proxy
  proxy_lib_name = files
  local_auth_policy = only
  
  [pam]
  pam_cert_auth = True
  ```
  
  Copy your CA certificate to `/etc/sssd/pki/sssd_auth_ca_db.pem`.
  
  Fix perms and restart sssd:
  ```sh
  sudo chmod 600 /etc/sssd/sssd.conf
- sudo systemctl daemon-reload
  sudo systemctl restart sssd
  ```
  
  Override the cert for your local user:
  ```sh
  cert=`openssl x509 -in card_cert.pem -outform der | base64 -w0`
  sudo sss_override user-add wesley --certificate="${cert}"
  sudo systemctl restart sssd
  ```
  
- On Noble:
+ On Noble & newer:
  
  ```sh
  sudo pam-auth-update --disable sss-smart-card-optional --enable 
sss-smart-card-required
  ```
  
  On Jammy:
  
- ```
- TBD
+ Insert this line in `/etc/pam.d/common-auth` before all the other
+ modules:
+ 
+ ```
+ auth    [success=done default=die]    pam_sss.so allow_missing_name 
require_cert_auth
  ```
  
  Verify that authentication works:
  
  ```sh
  pamtester -v login wesley authenticate
  ```
  
  Replace the p11_child binary with a script to widen the window for the
  race:
  
  ```sh
  sudo mv /usr/libexec/sssd/p11_child /usr/libexec/sssd/p11_child.bin
  sudo tee /usr/libexec/sssd/p11_child <<'EOF'
  #!/bin/bash
  sleep 5
  exec /usr/libexec/sssd/p11_child.bin "$@"
  EOF
  sudo chmod 755 /usr/libexec/sssd/p11_child
  ```
  
  To reproduce, note the start time and pid of the sssd_pam responder:
  
  ```
  ps -aux | grep sssd_pam
  root       11081  0.0  0.3  32928 14708 ?        S    16:48   0:00 
/usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files
  ```
  
  Launch pamtester in one terminal and login with a nonsense domain in the other
  **before** the first pamtester has requested a PIN (during the p11_child 
sleep):
  
  ```sh
  pamtester -v login wesley authenticate
  # in another terminal
  pamtester -v login "bogususer@bogusdomain" authenticate
  ```
  
  Expected behavior:
  
- sssd_pam does not crash:
- 
- ```
- ps -aux | grep sssd_pam
+ sssd_pam does not crash and authenticates successfully:
+ 
+ ```
+ $ ps -aux | grep sssd_pam
  root       11081  0.0  0.3  32928 14708 ?        S    16:48   0:00 
/usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files
+ 
+ $ pamtester -v login wesley authenticate
+ pamtester: invoking pam_start(login, wesley, ...)
+ pamtester: performing operation - authenticate
+ PIN for Users:
+ pamtester: successfully authenticated
  ```
  
  Actual behavior:
  
- sssd_pam has been restarted:
+ sssd_pam has been restarted and user detection from the card cert fails:
  
  ```
  $ ps -aux | grep sssd_pam
  root       12608  0.3  0.3  32928 14648 ?        S    17:16   0:00 
/usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files
- ```
- 
- In my lab, this manifests as a GP fault that can be observed on the
- syslog:
+ 
+ $ pamtester -v login wesley authenticate
+ pamtester: invoking pam_start(login, wesley, ...)
+ pamtester: performing operation - authenticate
+ Please insert smart card
+ Please (re)insert (different) Smartcard
+ Please (re)insert (different) Smartcard
+ ```
+ 
+ In my Noble & newer labs, this manifests as a GP fault that can be
+ observed on the syslog:
  
  ```
  2026-07-30T17:16:44.243168-05:00 n0 kernel: traps: sssd_pam[12219] general 
protection fault ip:7e185e52838a sp:7ffd353e9a20 error:0 in 
libsss_certmap.so.0.2.0[7e185e525000+b000]
  ```
+ 
+ Jammy gives an opaque error about the crashed daemon:
+ 
+ ```
+ Jul 31 15:02:53 j0 sssd[563]: Child [616] ('pam':'pam') was terminated by own 
WATCHDOG. Consult corresponding logs to figure out the reason.
+ ```
+ 
+ [1] https://ubuntu.com/server/docs/how-to/security/smart-card-
+ authentication/
  
  [ Where problems could occur ]
  
  The affected codepaths are in the handling of the p11_child process, which 
means
  that any breakage caused by this fix should be limited to users of
  certificate-based smartcard authentication. Breakage would likely manifest as
  inability to determine a certificate for a user where the mapping previously
  worked:
  
  $ pamtester -v login wesley authenticate
  pamtester: invoking pam_start(login, wesley, ...)
  pamtester: performing operation - authenticate
  Please insert smart card
  Please (re)insert (different) Smartcard
  
  (Indeed, this is the behavior exhibited when sssd_pam crashes, so even if the
  fix is broken enough to cause a crash, this is the symptom users would see).
  
  At time or writing the change has not been released upstream; no commits refer
  to it with "Fixes:" or similar.
  
  [ Other information ]
  
  Upstream links:
  - https://github.com/SSSD/sssd/issues/8796
  - https://github.com/SSSD/sssd/pull/8861
  - https://github.com/SSSD/sssd/commit/fa7a55949a30fed064a28ea6f0c801fc5e8c5ba7

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2162577

Title:
  sssd_pam sometimes crashes authenticating through remote desktop

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/2162577/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to