Console logs secure env value when parsing fails

[Synesso]

Put an "unexpected value" character in a secure env variable and that variable will be logged at the console.

e.g. the encrypted value PASSWORD=winnie(the pooh) might become

secure: abcd1234..01

At build time this will log:

$ export PASSWORD=[secure]
/home/travis/build.sh: line 107: syntax error near unexpected token `('
/home/travis/build.sh: line 107: `export PASSWORD=winnie(the pooh)'

[sarahhodne]

See also #825, #1145 and #1722.

I'm a bit torn on how to fix this. The obvious way seems to be to add a bit of escaping in the travis CLI, but if you look at #1722 that has issues as well.

If there is a way to do a syntax check on a bash script before running it, that may be the best thing to do, and just fail with an error if there is a syntax check.

The way to fix this, by the way, is to use travis encrypt 'PASSWORD="winnie(the pooh)"' instead.

[Synesso]

Yes, given that the problem only occurs when the user has incorrectly
configured a secure env, an appropriate fix might just be to allow the
deletion of a build's log. The user fixes their config, deletes the old log
and afterwards no sensitive info remains on travis-ci for public view.

On 28 December 2013 16:04, Henrik Hodne notifications@github.com wrote:

See also #825 #825, #1145https://github.com/travis-ci/travis-ci/issues/1145and
#1722 #1722.

I'm a bit torn on how to fix this. The obvious way seems to be to add a
bit of escaping in the travis CLI, but if you look at #1722https://github.com/travis-ci/travis-ci/issues/1722that has issues as well.

If there is a way to do a syntax check on a bash script before running it,
that may be the best thing to do, and just fail with an error if there is a
syntax check.

The way to fix this, by the way, is to use travis encrypt
PASSWORD="winnie(the pooh)" instead.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1775#issuecomment-31290579
.

[sarahhodne]

Agreed, that would probably be a good workaround too. Right now, the correct way of getting a log cleared is to email support, but we have a “delete build” feature on the roadmap: #877.

[joshk]

I am a big fan of adding a 'delete log' feature as several requests to remove builds have been because of security issues with the logs. I would actually favour this feature over #877

[sarahhodne]

I agree. Opened #1791 for that.

[BanzaiMan]

Is there anything to do on this ticket?

[sarahhodne]

I think we are still considering adding "filtering" of some sort, removing the values of encrypted environment variables from the logs if they are accidentally printed. There's also the question of automatically escaping the variables in travis.rb when adding them. Both of those might be separate tickets, though.

[joshk]

Personally I'm not in favour of us filtering the logs as the concept of log parts makes filtering hard and complicated.

The 'remove log' feature should help in cases where secure vars are exported in clear text when they shouldn't.

[rkh]

In theory, filtering logs would allow an attack, if the attacker could
inject strings into the logs.

On Tue, Jul 22, 2014 at 12:32 AM, Josh Kalderimis notifications@github.com
wrote:

Personally I'm not in favour of us filtering the logs as the concept of
log parts makes filtering hard and complicated.

The 'remove log' feature should help in cases where secure vars are
exported in clear text when they shouldn't.

—
Reply to this email directly or view it on GitHub
#1775 (comment)
.

[sarahhodne]

@rkh I thought that at first, too, but then @drogus pointed out that if they have access to inject strings to the log, they also have access to the environment variables and can just print them instead.

[rkh]

Not necessarily, the log could be output from a curl command, for instance.

[bguerin]

@henrikhodne

If there is a way to do a syntax check on a bash script before running it

bash -n

[camelspeed]

@henrikhodne @BanzaiMan Any progress on this issue? I just had my hosting environment access token exposed due to a malformed character in the string. I purged my log but it is still concerning that secrets are exposed (and this issue is 18mos old and still unresolved) even though the information entered the system in a protected state. Thank you guys.

[octocat-mona]

I configured a (apparently malformed) secure variable via the settings in Travis, why can't that be checked before it is saved?

[langri-sha]

Hello everyone! Would it not be possible to export these values before the build begins and re-export them for verbosity and clerical purposes?

I am happy with any way you manage to fix this, as this seems to be a critical security error, because it's easy to use robots to divulge logs that have partially leaked a secret in public.

[BanzaiMan]

I've opened the PR to at least partially address this issue. I welcome comments there. Thank you!

[BanzaiMan]

I'm closing this now. We now send export's STDOUT to /dev/null, so that parts are not leaked to the logs, and show link for further information on Bash special characters if the command fails.

If you see a similar issue going forward, please open a new issue.

Thank you!

[BanzaiMan]

The PR was reverted.

[Swyter]

The fix is easy, just escape them as literal strings like everyone else. That's it.

Spent the entire afternoon scratching my head before figuring out why my URLs weren't working.
That I had to base64-encode them to use them in scripts is just ridiculous.

[BanzaiMan]

travis-ci/travis-build#942 is live. Accidental leakage is far less likely now.

I'm closing this.