AWS is enabling teams to address application weaknesses with the introduction of the AWS Fault Injection Simulator at is virtual AWS re:Invent 2020 conference this week. The simulator is a chaos engineering tool expected to be generally available in 2021.

According to the company, the new offering will come packed with pre-built templates for creating the desired disruptions whether that’s for server latency or database errors. It also contains controls and guardrails such as automatically rolling back or stopping the experiment if certain conditions are met. Then teams can quickly roll back to the pre-experiment state.

Teams will also have access to a range of fine-grained controls during the experiments to gradually or simultaneously impair how different resources perform in a production environment as it is scaled up, according to AWS in a post.

“With a few clicks in the console, teams can run complex scenarios with common distributed system failures happening in parallel or building sequentially over time, enabling them to create the real world conditions necessary to find hidden weaknesses,” AWS explained on its website.

AWS explained the new offering will be especially useful for simulating game days by creating the high-traffic conditions, a new launch or for integration right into continuous delivery pipelines so that teams can repeatedly test the impact of faults in the SDLC.

Fault Injection Simulator can be used to generate tests in many AWS services such as AWS services, such as Amazon EC2, Amazon EKS, Amazon ECS, and Amazon RDS.

A design flaw in Actions, GitHub’s workflow management platform, can give hackers write access to repositories and reveal encrypted secrets, Google Project Zero researcher Felix Wilhelm has reported.

An attacker can exploit set-env, one of the commands supported by GitHub Actions, to dump NodeJS commands to the shell output, which are then processed and run by Actions’ runner process.

“As the runner process parses every line printed to STDOUT looking for workflow commands, every GitHub action that prints untrusted content as part of its execution is vulnerable,” Wilhelm writes. Projects that have complex GitHub workflows comprised of multiple steps are especially at risk.

For instance, in the case of Microsoft’s Visual Studio Code GitHub repo, Wilhelm was able to exploit the bug by injecting code in an issue title passed to the project’s new issue workflow.

Another example is Stale, one of GitHub Actions’ own modules for closing stale issues and pull requests. In projects such as RocketChat, which use stale as part of a multi-step workflow, attackers can use the set-env command to stage code injection attacks.

In his research, Wilhelm found similar issues in actions that operate on pull requests. “An external contributor can just create a pull request between two existing branches in the target repo to trigger a privileged workflow run,” Wilhelm writes.

Following Wilhelm’s report, GitHub issued an advisory, confirming the vulnerability and declaring it will disable set-env and another command, add-path, in the future.

“To allow us to address this issue and maintain the ability for you to dynamically set environment variables we have introduced a new set of files to manage environment and path updates in workflows,” GitHub wrote in a blog post following the advisory.

“If you need to log untrusted information such as issue titles, bodies, or commit messages to STDOUT we recommend that you disable command processing prior to doing that.”

Wilhelm could not be reached for comment.

Mitigation
In written comments to The Daily Swig, a spokesperson for GitHub said: “Each submission to our bug bounty program is a chance to make GitHub, our products, and our customers more secure.

“We are continuing to migrate customers off of the set-env and add-path workflow commands feature and deprecate it as quickly as possible with minimal disruption to our users in the Actions ecosystem.

“We plan to fully deprecate set-env and add-path workflow commands in the next month, and have included guidance on how to move off of this feature as well as options for patching prior to the deprecation in our disclosure.”