Security: predictible tempfile names

[cboltz]

While checking my AppArmor logs, I noticed that git accesses

/tmp/git-index-private* r,
/tmp/git-index-private*.lock rw,

where * is the pid of bash.

After some searching, I found that gitprompt.sh uses this predictable filename:

function createPrivateIndex {
  [...]
  __GIT_INDEX_PRIVATE="${TMPDIR:-/tmp}/git-index-private$$"
  command cp "${__GIT_INDEX_FILE}" "${__GIT_INDEX_PRIVATE}" 2>/dev/null
  echo "${__GIT_INDEX_PRIVATE}"
}

A pid-based filename is predictable, and can be used by attackers, for example to do a symlink attack - which results in cp overwriting an attacker-chosen file. (In this specific case, the attacker doesn't need to be very fast, since bash is typically running for quite a while, and the attacker can easily find the bash pid using ps.)

I'd recommend to use a mktemp-generated filename to avoid this problem.

Something I couldn't find in the script is the creator of the *.lock file, so I can only guess that git does it. This somewhat bypasses the mktemp-generated filename.

If you want to be on the safe side, create a temporary directory with mktemp -d and copy the file into that directory. With that, the *.lock file should also end up in that directory.

Please let me know if you have any questions.

[rakotomandimby]

@cboltz , thank you for your time. I pushed a fix attempt: https://github.com/magicmonty/bash-git-prompt/commit/71d17f56473c9aa97f1828fa29a80ca983e2b580

Note: I am very very sorry to directly push on master, I promise I wont do it again.

[rakotomandimby]

I think I broke it on some setup (not all). Checking what is wrong...

[eku]

I am very very sorry to directly push on master, I promise I wont do it again.

Should actually be prevented.

[rakotomandimby]

@eku @cboltz , faulty commit reverted

[mgerstner]

It seems this issue has lost attention. I just stumbled over the same finding and it is rather problematic:

This is an especially bad case of predictable /tmp file usage, because the PID of the long-running interactive shell process is used here, and thus not only used once, but reused every time the git bash prompt is updated.

There is no errexit option set and errors are not checked when creating the file in this path. This results in the following possible local security issues:

• denial-of-service: if an attacker pre-creates this file in /tmp, the bash-git-prompt will not work when trying to use this index file.
• integrity violation: if an attacker places crafted data in this file, bash-git-prompt will use it when invoking git with unspecified effects. It could cause crafted data to appear in the prompt or lead to even worse outcomes, like data loss.
• information leak: the regular umask for users is 0022, which means that the temporary file will be world-readable, thus leaking information about the Git repository the user is operating in to other users in the system.
• if the Linux kernel's protected_symlinks / protected_fifos setting is not enabled, then FIFOs or symlinks can be placed in this path, leading to a denial-of-service (bash blocking forever on a FIFO) or creation of the git index copy in arbitrary locations that are accessible to the user running bash-git-prompt.

I believe fixing this should not be hard, by simply using mktemp instead of the predictable path.

I believe this issue also deserves assigning a CVE to make users and packagers of bash-git-prompt aware of this issue, which should be fixed in all installations. If you want we can provide a CVE for you (I am from the SUSE security team, and we are a CVE CNA).

[mgerstner]

We requested a CVE from Mitre and this issue is now tracked as CVE-2025-61659.

I analyzed the issue a bit more closely by now. The problematic temporary file is created after every interactive command that is entered in the shell, provided the user is located in a Git repository. This gives ample opportunity to local unprivileged attackers to exploit the issue.

On OpenSUSE we now apply this simple patch to employ safe temporary file creation and avoid an information leak.

The issue was introduced in commit 38f7dbc0bb8 and has been present since version 2.6.1 of bash-git-prompt.