dbx12 / envmanager Goto Github PK

Only affects password storage pass

Steps to reproduce:

• have a profile using pass as storage backend
• gpg key used to encrypt secrets is expired (or at least the subkey with usage E is)
• attempt to load the profile
• see the following output

Command 'gpg:' not found, did you mean: command 'gpgv' from deb gpgv (2.2.19-3ubuntu2.2)
 command 'gpg2' from deb gnupg2 (2.2.19-3ubuntu2.2)
 command 'gpg1' from deb gnupg1 (1.4.23-1)
 command 'gpg' from deb gpg (2.2.19-3ubuntu2.2)Try: sudo apt install <deb name>

What happened?

Apparently the library github.com/gopasspw/gopass uses the gpg binary internally. And this binary outputs a note (gpg: Note: secret key <fingerprint> expired at Wed 31 Aug 2022 09:43:32 AM CEST) if an expired key is used for decryption. That output on stderr is not caught by the library and emitted on the stderr of envManager along with the export statements. The wrapper takes this output on stderr and evals it to execute the export statements.

Conlusions

• Communication over stderr is not as optimal as initially thought since libraries can pollute stderr output
• Running eval on the output of the envManager binary can pose a security risk. Potential scenario is a targeted supply chain attack on this project by a library which outputs malicious code on stderr with the intent of having envManager eval-ing it.

Actual behavior
If two profiles define the same environment variable and both profiles are loaded, the last profile wins and overwrites the earlier loaded environment variables.

Expected behavior
An error message / warning is shown when one profile overwrites a variable set by another profile during the same load command.

Additional notes

• The check should only be performed during one load operation (e.g. envManager load profA profB)
• It is particularly easy to "achieve" this with directory mappings since they are another redirection
• This condition can probably also be reached via dependencies

How to to reproduce
Config:

storage:
  pass:
    type: pass
profiles:
  profA:
    storage: pass
    path: credA
    constEnv:
      CONST_ENV: i-am-from-profile-A
  profB:
    storage: pass
    path: credB
    constEnv:
      CONST_ENV: i-am-from-profile-B
directoryMapping:
  /tmp:
    - profA
    - profB

• Run envManager load profA profB and you see CONST_ENV=i-am-from-profile-B. Swap the profile names and you see the value of profile A
• Run envManager load while in /tmp and see again the value from profile B