Secured variables indirectly leak in logs

Issue #16131 wontfix
Rodrigo Saboya
created an issue

When using secured environment variables in Bitbucket Pipelines, if you set a variable to a value that is outputted to a known value in the build log, you can infer the secured value.

Apparently the log output is secured through a find and replace of the secured variables value. This naive approach can lead to information leaking when the value is the same as some other known string, like the organization name for example.

If you have SECURED_VARIABLE=myorganization and your organization is called myorganization, this will lead to the following output in the build log:

+ umask 000

+ GIT_LFS_SKIP_SMUDGE=1 git clone --branch="test" --depth 50 https://x-token-auth:$$SECURED_VARIABLE/project.git $BUILD_DIR ; git reset --hard <hash> ; git remote set-url origin$SECURED_VARIABLE/project.git
Cloning into '/opt/atlassian/pipelines/agent/build'...
HEAD is now at <hash> <message>.

+ chmod 777 $BUILD_DIR

Since the organization name is a known value, you can infer that $SECURED_VARIABLE is myorganization.

While there's no 100% safe way to do this since a lot of the output can be generated by the user, it's possible to omit those substitutions in places where the output is 100% generated by Atllassian, such as the repository checkout stage, before the user script even begins.

Comments (2)

  1. Aneita Yang staff

    Hey Rodrigo,

    Thanks for reaching out.

    This behaviour is by design - given secured variables are used for sensitive data like passwords, we mask every instance of the value of a secured environment variable with the name instead. Things like an organisation's name are not sensitive and do not need to be a secured variable. If you do require the use of a secure variable however, I encourage you to change the value of the variable to be more unique so that it isn't a value that will surface in your build logs.


  2. Log in to comment