REDHAT-BUG-2465635: Command Injection

AIONLYREPORT package: environment-modules-5.6.1-2.el10 ------ Summary: Command Injection in Bash Completion via Malicious Module Names: attacker-controlled module names can reach Bash compgen -W during completion and execute command substitutions in the completing user's shell. Requirements to exploit: A local attacker must be able to place a maliciously named modulefile in a location that becomes visible in the victim's MODULEPATH, and the victim must use Bash completion for module or ml and trigger completion on affected subcommands. Component affected: environment-modules-5.6.1-2.el10, Bash completion in init/bashcompletion.in (modulecomgenwordsandfiles, moduleavail, modulespider, and related call sites), with module names originating from filesystem entries in tcl/modfind.tcl.in Version affected: environment-modules-5.6.1-2.el10 when Bash completion for module/ml is installed and used, and completion is performed against attacker-influenced module names Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H - 7.3 (HIGH) AV:L - The attacker needs local access to place or expose a malicious module name through a searched module path. AC:L - The payload is a straightforward malicious filename using command substitution syntax. PR:L - The attacker needs low privileges sufficient to create or influence a module entry visible to the victim. UI:R - The victim must trigger shell completion, for example by pressing TAB. S:U - The impact is within the victim user's shell context rather than crossing a privilege boundary. C:H - Arbitrary commands in the victim shell can read the victim's accessible data. I:H - Arbitrary commands in the victim shell can modify the victim's files and shell state. A:H - Arbitrary commands in the victim shell can disrupt the victim session or delete accessible data. Impact: Moderate. Successful exploitation can execute arbitrary commands as the completing user, which can substantially affect that user's confidentiality, integrity, and availability. However, exploitation is conditional on a local attacker being able to influence module names presented through MODULEPATH, Bash completion being in use, and the victim actively triggering completion. This fits Red Hat's Moderate classification because the impact can be serious but reachability is configuration- and workflow-dependent rather than broadly and easily exploitable. Embargo: no Reason: The issue is locally exploitable, requires user interaction, and depends on attacker-influenced module search paths. Disabling the affected completion path or avoiding untrusted module paths provides practical mitigation, so immediate coordinated public remediation is more appropriate than embargo handling. Acknowledgement: Aisle Research Vulnerability Details: The Bash completion helper passes untrusted completion candidates to compgen -W, and Bash performs shell-like parsing of the supplied word list. When a module name contains command substitution syntax such as $(...), that syntax is evaluated during completion rather than treated as inert text. The vulnerable completion path is: bash init/bashcompletion.in modulecomgenwordsandfiles() { ... for val in $(compgen -W "$1" – "$2"); do ... done } ... avail) modulecomgenwordsandfiles "@compavailopts@ $(moduleavail "$cur")" "$cur";;

The module names are derived from filesystem entries without filtering shell metacharacters before they are stored and later emitted through module avail: tcl tcl/modfind.tcl.in set eltlist [glob -nocomplain -directory $dir ] ... set modulename [getModuleNameFromModulepath $element $dir] ... set modlist($modulename) [list modulefile $mtime $element]

Based on the available evidence, the issue is confirmed for environment-modules-5.6.1-2.el10. A broader affected version range was not established here, so this report scopes the finding to the scanned SRPM package. Steps to reproduce: 1. Load the completion script: bash source init/bashcompletion.in 2. Stub module so that module avail returns a malicious module name: bash rm -f /tmp/modulecompletionrepopathpoc module() { [ "$1" = avail ] && printf '%s\n' '$(touch /tmp/modulecompletionrepopathpoc)'; } 3. Trigger the affected completion path directly: bash COMPWORDS=(module avail "") COMPCWORD=2 module module "" avail 4. Verify the side effect: bash test -f /tmp/modulecompletionrepopathpoc && echo "Vulnerable" Optional end-to-end setup using a real module filename: bash mkdir -p /tmp/modpoc printf '#%%Module\n' > '/tmp/modpoc/$(touch /tmp/modulecompletionpoc)' module use /tmp/modpoc then trigger module avail <TAB> in an interactive Bash session with this completion loaded

Mitigation: Until a fix is available, avoid enabling Bash completion for module and ml in environments where untrusted users can influence MODULEPATH, and do not include attacker-writable module directories in shared search paths for other users. Where practical, remove or disable the affected completion script. Proposed Fix: Replace use of compgen -W for untrusted module-name lists with line-oriented filtering that does not evaluate shell syntax from completion candidates. diff diff --git a/init/bashcompletion.in b/init/bashcompletion.in @@ modulecomgenwordsandfiles() { local k=0 local setnospace=1 + local val do not append space to word completed if it is a directory (ends with /)

for val in $(compgen -W "$1" – "$2"); do + # Avoid compgen -W on untrusted module names (it evaluates shell syntax). + while IFS= read -r val; do + [ -z "$val" ] && continue + [[ "$val" == "$2" ]] || continue if [ $setnospace -eq 1 ] && [ "${val: -1:1}" = '/' ]; then

Bash >=4.0 is required for compopt type compopt &>/dev/null && compopt -o nospace setnospace=0 fi COMPREPLY[k++]="$val"

done + done <<< "$1" }

------ This report was generated using AI technology. Always review AI-generated content prior to use