Skip to content
Patch Next
Sign inAdd to your agent

← Public intelligence

crates.io package

pam-bindings

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

1 actionable advisory, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Unratedcrates.ioPublished

    PamHandle::get_user can cause an authentication bypass

    Affected
    • crates.io pam-bindings >= 0.0.0-0, < 0.1.2
    Fixed in
    0.1.2· Vendor fix available
    Issue
    In affected versions, `PamHandle::get_user` can return `Err(PAM_SUCCESS)` after it gets the username successfully. PAM modules that return this "error" code from `sm_authenticate` or `sm_acct_mgmt` early-return a success code to PAM without doing any further verification. This means a user could log in when they shouldn't be able to (e.g., if the module is `sufficient`). The `pam_try!` macro of this crate early-returns the code in this exact way: ```rust fn sm_authenticate(pamh: &mut PamHandle, args: Vec , flags: PamFlag) -> PamResultCode { let user = pam_try!(pamh.get_user(None)); // Can return PAM_SUCCESS here. // If it does, the module does not get to this line. } ``` The root cause is an [incorrect FFI declaration][ffi-decl] for [`pam_get_user(3)`][pam-get-user]. This C function writes a pointer to the username through its `user` argument (of type `const char **user`). This crate's binding declared this argument as a shared reference (`&*mut c_char`). Writing through a shared…

    Recommended action: Upgrade to 0.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.devSource checked Evidence →