While scrolling Twitter, I came across this tweet talking about the new AWS feature Roles Anywhere.
I was messing around with the aws_signing_helper and got this panic. The trace path doesn't make me feel super confident about the security of their build process. Not that I was happy about the "download this from a random S3 bucket" distribution method either. pic.twitter.com/B58g8fOk49
— David Adams (@daveadams) July 13, 2022
Roles Anywhere is a new way to use IAM roles on systems that aren't in AWS. Think data centers or even other clouds that would not have access to assume a role and get temporary credentials. Generally, we would have to give these services long-living IAM credentials or find another way to federate into AWS for authentication.
A blurb:
temporary security credentials in IAMIAM policiesIAM roles
Roles Anywhere uses PKI via a cert and a trust in IAM to generate temporary IAM access credentials. It does solve the problem of having long-living IAM credentials being used.
AWS provided a helper binary, written in Go, to help generate the temporary credentials.
As pointed out in the tweet, you download it from S3 here.
I was curious so I pulled down the Darwin helper binary and ran strings against it. Along with a lot of garbage and normal symbols, there were some interesting paths in the output.
Here's a few examples:
/Users/guptagr/Workspaces/AWSNileCredentialHelper/rolesanywhere/service.go /Users/guptagr/go/pkg/mod/github.com/aws/aws-sdk-go@v1.44.40/service/sts/service.go /usr/local/Cellar/go/1.18/libexec/src/bufio/bufio.go
I'll start by saying, I'm no reverse engineer, but what we gather from these strings is that a user, guptagr, built the helper binary on a Mac (Darwin) and referenced locally installed libraries.
Additionally, some strings leak internal but internet-facing library hosting sites:
golang.a2z.com/AWSNileCredentialHelper/rolesanywhere.newErrorTooManyTagsException
This is not an unusual thing to do in the Golang world. Users build binaries that have local references. It is odd that a production-ready binary used for some of the most sensitive functions (IAM assume role) and installed on internal systems, looks to be built on a single developer's machine...
Preferably, AWS would checkout the helper binary code on a build machine for this purpose, build the binary, sign it, then publish it, not leaking internal file paths. This calls into question if AWS has a proper release process for tools like this. I would be slightly appalled but not completely surprised if this binary is built then pushed to the S3 bucket hosting it for the world to consume.
AWS did not seem to take the simple build options such as trimming symbols or paths via build options -ldflags="-s -w" and -trimpath. Note: there are issues completely removing symbols on Darwin platforms without third party tools. Credit: hex0punk!
If this is the case that AWS releases tools like this without a central and verified pipeline, is it the end of the world? No. Pipelines can be mismanaged as well and they may actually have a process in place that is not obvious that is addressing what I'm bringing up. Maybe the paths and info in the binaries is false or old or from another source not directly related to the build.
AWS does a really great job with security most of the time but there are times where some rough edges poke through, examples here. Hopefully, I'm misreading what we're seeing and AWS has this covered but, if not they have some work to do.
