You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "Paul Rogers (JIRA)" <ji...@apache.org> on 2019/01/26 21:18:00 UTC
[jira] [Updated] (IMPALA-8127) AWS security token leaked to build
log
[ https://issues.apache.org/jira/browse/IMPALA-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Rogers updated IMPALA-8127:
--------------------------------
Description:
The build for "asf-master-core-asan" failed due to IMPALA-8128. The log tried to then upload core files to AWS. In doing so, the (presumably temporary) AWS tokens were leaked into the build log:
{noformat}
20:42:08 2019-01-25 20:42:08,728 - boto - DEBUG - StringToSign:
20:42:08 HEAD
20:42:08 Sat, 26 Jan 2019 04:42:08 GMT
20:42:08 x-amz-security-token:FQ...4gU=
20:42:08 /impala-coredump-archive/
20:42:08 2019-01-25 20:42:08,729 - boto - DEBUG - Signature:
20:42:08 AWS ASIA...g=
20:42:08 2019-01-25 20:42:08,729 - boto - DEBUG - Final headers: {'Date': 'Sat, 26 Jan 2019 04:42:08 GMT', 'Content-Length': '0', 'Authorization': u'AWS ASIAV...8ev4gU=', 'User-Agent': 'Boto/2.48.0 Python/2.7.5 Linux/3.10.0-693.5.2.el7.x86_64'}
20:42:08 2019-01-25 20:42:08,800 - boto - DEBUG - Response headers: [('x-amz-bucket-region', 'us-west-2'), ('x-amz-id-2', 'MXD...U='), ('server', 'AmazonS3'), ('transfer-encoding', 'chunked'), ('x-amz-request-id', 'FB38CC160531DCFF'), ('date', 'Sat, 26 Jan 2019 04:42:09 GMT'), ('content-type', 'application/xml')]
{noformat}
Even if these tokens are somehow benign (are expired by the time someone reads them), the "optics" are bad: security tokens should be secure; they should not be dumped to logs.
As a workaround, if the team feels they do need the tokens, elide the tokens as done in the text above. Provide enough characters to verify that the token is the one expected, but leave off most of the text. Not ideal, but better than exposing the entire token.
was:
In the "asf-master-core-asan" build, the (presumably temporary) AWS tokens appear in the build log:
{noformat}
20:42:08 2019-01-25 20:42:08,728 - boto - DEBUG - StringToSign:
20:42:08 HEAD
20:42:08 Sat, 26 Jan 2019 04:42:08 GMT
20:42:08 x-amz-security-token:FQ...4gU=
20:42:08 /impala-coredump-archive/
20:42:08 2019-01-25 20:42:08,729 - boto - DEBUG - Signature:
20:42:08 AWS ASIA...g=
20:42:08 2019-01-25 20:42:08,729 - boto - DEBUG - Final headers: {'Date': 'Sat, 26 Jan 2019 04:42:08 GMT', 'Content-Length': '0', 'Authorization': u'AWS ASIAV...8ev4gU=', 'User-Agent': 'Boto/2.48.0 Python/2.7.5 Linux/3.10.0-693.5.2.el7.x86_64'}
20:42:08 2019-01-25 20:42:08,800 - boto - DEBUG - Response headers: [('x-amz-bucket-region', 'us-west-2'), ('x-amz-id-2', 'MXD...U='), ('server', 'AmazonS3'), ('transfer-encoding', 'chunked'), ('x-amz-request-id', 'FB38CC160531DCFF'), ('date', 'Sat, 26 Jan 2019 04:42:09 GMT'), ('content-type', 'application/xml')]
{noformat}
Even if these tokens are somehow benign (are expired by the time someone reads them), the "optics" are bad: security tokens should be secure; they should not be dumped to logs.
As a workaround, if the team feels they do need the tokens, elide the tokens as done in the text above. Provide enough characters to verify that the token is the one expected, but leave off most of the text. Not ideal, but better than exposing the entire token.
> AWS security token leaked to build log
> --------------------------------------
>
> Key: IMPALA-8127
> URL: https://issues.apache.org/jira/browse/IMPALA-8127
> Project: IMPALA
> Issue Type: Bug
> Components: Infrastructure
> Affects Versions: Impala 3.1.0
> Reporter: Paul Rogers
> Assignee: Janaki Lahorani
> Priority: Blocker
> Fix For: Impala 3.1.0
>
>
> The build for "asf-master-core-asan" failed due to IMPALA-8128. The log tried to then upload core files to AWS. In doing so, the (presumably temporary) AWS tokens were leaked into the build log:
> {noformat}
> 20:42:08 2019-01-25 20:42:08,728 - boto - DEBUG - StringToSign:
> 20:42:08 HEAD
> 20:42:08 Sat, 26 Jan 2019 04:42:08 GMT
> 20:42:08 x-amz-security-token:FQ...4gU=
> 20:42:08 /impala-coredump-archive/
> 20:42:08 2019-01-25 20:42:08,729 - boto - DEBUG - Signature:
> 20:42:08 AWS ASIA...g=
> 20:42:08 2019-01-25 20:42:08,729 - boto - DEBUG - Final headers: {'Date': 'Sat, 26 Jan 2019 04:42:08 GMT', 'Content-Length': '0', 'Authorization': u'AWS ASIAV...8ev4gU=', 'User-Agent': 'Boto/2.48.0 Python/2.7.5 Linux/3.10.0-693.5.2.el7.x86_64'}
> 20:42:08 2019-01-25 20:42:08,800 - boto - DEBUG - Response headers: [('x-amz-bucket-region', 'us-west-2'), ('x-amz-id-2', 'MXD...U='), ('server', 'AmazonS3'), ('transfer-encoding', 'chunked'), ('x-amz-request-id', 'FB38CC160531DCFF'), ('date', 'Sat, 26 Jan 2019 04:42:09 GMT'), ('content-type', 'application/xml')]
> {noformat}
> Even if these tokens are somehow benign (are expired by the time someone reads them), the "optics" are bad: security tokens should be secure; they should not be dumped to logs.
> As a workaround, if the team feels they do need the tokens, elide the tokens as done in the text above. Provide enough characters to verify that the token is the one expected, but leave off most of the text. Not ideal, but better than exposing the entire token.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org