Sensitive variable unmasked in logs

Octopus Server
, ,
1

Using Octopus Server 2020.6.4688
Deployment target: SSH

In one of our projects, we have a sensitive variable with a value that contains a # in it. From what we could tell, when the variable was substituted into a script, the presence of the # caused the variable value to show unmasked in the log.

Is this known behavior in the version we’re running?

2

More details:

I was unable to reproduce with a sample project.

The offending project is passing that sensitive variable (password) into Ant and it’s being logged out from there. Is it possible that another character in that password is causing issues? I’m trying to get the actual value from my Operations team. All I’ve been able to see is the value that appears in the log file which could be different (but very similar) to the actual value.

4

Hi @christopher.newton,

Thanks for getting in touch with us over your question, and sorry to hear you may be encountering issues with sensitive variables.

We aren’t currently aware of any known issues with sensitive variables in version 2020.6.4688 of Octopus, so I’m not yet sure what would be causing this. In which log are you seeing the sensitive variable unmasked?

Does the sensitive variable still unmask if you use only plain text characters and avoid sensitive characters (like # and {} ) in the original project?

I understand you don’t have an actual value from the log yet, but I’m curious to know if you’re able to reproduce the behavior in your test project using the same string. Another character that might cause issues would be }.

I’m looking forward to hearing back from you on the above.

Best,

5

We found the source of the problem, but looking for recommendations on how to avoid issues in the future.

We’re executing ant in bash on the Linux deployment target. One of the arguments we’re passing to ant is the password (value of that sensitive variable). The password that caused the issue had a $2 in the middle of it, which bash must have interpreted as the variable referring to the second argument of the ant command, which we could see in the logs. In other words, the password that was displayed in the logs had the $2 replaced by the value of second argument. That explains why the value was showing as unmasked since it was not equal to value that was marked as sensitive.

Is this the behavior we should expect when variable values contain $number?

6

Hi @christopher.newton,

Thanks for getting back to us and providing those details.

It may just be best to avoid strings that will be interpreted by the scripting language being used, as stated in our common mistakes section of the Sensitive variables doc (found here).

I realize that can be difficult to do in some cases, so one option might be to use variable filters to prevent this. I don’t know much about Ant or your use case I’m afraid, but the process would be to apply an escaping filter to your sensitive variable and then unencode it prior to passing it to Ant. For example, you could use | HtmlEscape, which should convert the $ to %24, and then unencode it once it passes through bash.

Does that seem like it might be helpful as a workaround for your use case? I’m looking forward to hearing back from you.

Best,
Patrick

7

Hi Patrick,

I’m not sure if that will work with Ant, but I’ll give it a try next week.

Thanks,

Chris

9

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.