Secure Erase of a Bash Environmental Variable

user_158096 0
Viewed 534

Suppose I have in a Bash shell script an environmental variable that holds a sensitive value (e.g. a password). How may I securely overwrite the memory that holds this variable's value before exiting my script?

If possible, the technique used to do so would not be dependent on the particular implementation of Bash I'm using. I'd like to find a standards-respecting/canonical way to do this that works on all correct Bash implementations.

Please note that the following are not in the scope of the question: 1. How the sensitive value is placed into the environmental variable 2. How the sensitive value stored in the environmental variable is passed to the program that consumes it

7/10/2017 5:03 AM Update to Address Comment by rici

rici, thank you for your comment, copied here:

"Exiting the script is really the only way to reliably delete an environment variable from the script's resident memory. Why do you feel the string is less safe after the script terminates than while it is running?"

My intent here is to follow good practice and actively scrub all cryptographically-sensitive values from memory as soon as I am through using them.

I do not know if Bash actively scrubs the memory used by a script when that script exits. I suspect that it does not. If it indeed does not, the sensitive cryptographic value will remain resident in memory and is subject to capture by an adversary.

In C/C++, one can easily scrub a value's memory location. I am trying to find out of this is possible in Bash. It may be that Bash is simply not the right tool for security-sensitive applications.

cryptography scripting linux security bash
1 Answers

First off, we need to distinguish between environment variables and shell variables. Environment variables exist for the lifetime of the process and cannot be overwritten. Not only that, but on many systems they are trivially visible to other processes. For example Linux provides the /proc filesystem which allows for lots of introspection of running processes, including observing their environment variables.

Here's an example of a Bash script that attempts to overwrite an environment variable. Notice that although the value within the script changes, the process' environment is not changed:

$ SECRET=mysecret bash -c \
  'strings /proc/$$/environ | grep SECRET
   SECRET=overwritten
   echo "SECRET=$SECRET"
   strings /proc/$$/environ | grep SECRET'
SECRET=mysecret
SECRET=overwritten
SECRET=mysecret

So it is never safe to store secrets in environment variables unless you control all access to the machine.

Holding a secret in a (non-environment) shell variable is much more secure, as an attacker would need to be able to access the memory of the process, which is generally something only the kernel can do. And while you're correct that minimizing the time you hold onto such secrets is a good practice, it's not generally worth jumping through lots of hoops for. It's far more important to secure your system and execution environment, because a motivated attacker who has sufficient access can observe a secret even if it only lives in memory for a brief time. Holding a secret in memory for longer than strictly necessary is only a marginal increase in risk, whereas running a privileged program on an insecure system already means all bets are off.

user_1136320
Related