4 ms·

This also serves as a reminder that code hosted on github might be malicious and we shouldn't blindly trust those just because the author seems to have similar

by zb3 3y ago

This also serves as a reminder that code hosted on github might be malicious and we shouldn't blindly trust those just because the author seems to have similar interests.. I've done that multiple times :(

dkjaudyeqooe 3y ago
That's true, but in this case the code might be fine and the executables they provide on GitHub bogus. It's tricky to keep in mind that GitHub is not a trusted build source.
- eastbound 3y ago
  And the GitHub Actions… oh man… Insert some tool in your build that comes from another random repository, that uploads an artifact to S3 or similar… GitHub’s architecture entirely is the iMessage of source code.
  - uoaei 3y ago
    Could you please expand on your iMessage comparison? I don't understand what you're referencing.
    - MarkSweep 3y ago
      I don’t know if I 100% follow or agree with the comparison of iMessage and GitHub actions. But iMessage has had a number of interesting security vulnerabilities over the years in image parsing and deserialization. One example: https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... Or a story from today: https://news.ycombinator.com/item?id=37425007 https://news.ycombinator.com/item?id=37425007 So perhaps the similarity between iMessage and GutHub actions is there are a lot of things that could go wrong. In iMessage it’s a pile of memory unsafe code that was not originally designed to withstand attack. In GutHub actions there is a lot of trust in their parties that could potentially be exploited.
      - SigmundA 3y ago
        And yet Android had multiple high and critical CVE's reported in the last few days with little coverage: https://source.android.com/docs/security/bulletin/2023-09-01 https://source.android.com/docs/security/bulletin/2023-09-01
        Obscurity4340 3y ago
        Where do CVEs tend to show up app-wise in Android? Is it also messaging or some other system service? With iOS its almost always either iMessage, WebKit, and iCloud Calendar
        teddyh 3y ago
        «А у вас негров линчуют»
        jacquesm 3y ago
        This isn't an Android vs Apple article.
        SigmundA 3y ago
        Its not an iOS / iMessage article either but it was brought up here and is the point if this current thread.
        bdangubic 3y ago
        Coverage is proportional to the number of users :)
    - 3np 3y ago
      The normal thing is to have integration test PRs and other CI actions (which may require access tokens to APIs, inherently or due to naive design) be defined by the incoming branch, creating a vector for an attacker to get access to privileged resources. For certain parts of integration and testing jobs that are operating on untrusted code, it'd therefore be desired to not allow incoming PRs to change certain parts of the CI configuration (not only including .github/workflows, which can be protected using branch protection rules, but the testing framework). It's possible to achieve this by splitting up your workflows and using workflow_run but it's non-obvious and finicky enough that I very rarely see it done. GitHub could make this easier and propose better patterns than they do in their attempt to address the problem[0], which I think could use a 2023 follow-up. [0]: https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ https://securitylab.github.com/research/github-actions-preve... --- In this context, an iMessage message <> a GitHub PR, I guess.
    - randmeerkat 3y ago
      > Could you please expand on your iMessage comparison? I don't understand what you're referencing. https://arstechnica.com/gadgets/2023/09/apple-patches-clickless-0-day-image-processing-vulnerability-in-ios-macos/ https://arstechnica.com/gadgets/2023/09/apple-patches-clickl... iMessage itself is a dumpster fire that time and again has been proven to be an attack vector.
    - eastbound 3y ago
      A lot of useful features are missing from actions/checkout@v3, so people have to either program actions manually, or use ones made by other GitHub users. Actions are build steps, such as opening a firewall before building, preparing a directory, or caching Maven artifacts. It would be very easy to add a backdoor to one of those build steps. The comparison with iMessage is that it’s unsafe by design, at the architecture level, because you’re relying on live code made by anonymous people. One day, attack vectors will be found every second day.
      - PhilipRoman 3y ago
        It strikes me as the classic NPM disease. Do we really need a reusable action for disabling a firewall, uploading files, etc.? I mean if it comes from GitHub that's fine, but for anything else I would rather verify the solution and copy the code. It works like a low-tech lock file, except changes are always visible inline in Git history, so less chance of lazy programmers missing changes. I almost laughed when GitHub suggested me an Action for Makefile based projects. The entire build process in my case consists of "make package"...
        jacquesm 3y ago
        > if it comes from GitHub that's fine No it isn't. It's become normalized but it isn't fine. Whoever thought it was a good idea to download massive amounts of unaudited code at build time to then run it behind your defensive lines should have thought about that a bit longer. CI/CD is great. GitHub/GitLab are great. But combining the two has substantial risks. More so for languages that have broken package management and namespace issues.
        PhilipRoman 3y ago
        You are of course right. I was thinking more in terms of "how do we save clueless developers (and their users) from themselves". They will probably find more ways to shoot themselves in the foot, but any percentage of prevented vulnerabilities is a positive result. Kind of like people trust Google/Apple with their phones.
tpmx 3y ago
Yes. Remember that not only security researchers but also developers in general are extra juicy targets because of e.g. their AWS credentials that sometimes aren't kept as secure as they need to be. Heck, even if you're doing proper SSO with 2FA the tokens can be stolen and data proxied/exfiltrated. At best they can be used for coin mining (running up a huge bill), at worst for stealing private customer data (and then selling/ransomwaring it).
- jacquesm 3y ago
  > e.g. their AWS credentials that sometimes aren't kept as secure as they need to be There is some irony in there.
dclowd9901 3y ago
We have pretty high bars for what we allow in terms of outside dependencies, but that doesn’t mean they do. It’s basically a crap shoot if you choose to do open source at all.
ChrisRR 3y ago
And that includes libraries that you blindly pull down from package managers

by zb3 3y ago

dkjaudyeqooe 3y ago

That's true, but in this case the code might be fine and the executables they provide on GitHub bogus. It's tricky to keep in mind that GitHub is not a trusted build source.

eastbound 3y ago
And the GitHub Actions… oh man… Insert some tool in your build that comes from another random repository, that uploads an artifact to S3 or similar… GitHub’s architecture entirely is the iMessage of source code.
- uoaei 3y ago
  Could you please expand on your iMessage comparison? I don't understand what you're referencing.
  - MarkSweep 3y ago
    I don’t know if I 100% follow or agree with the comparison of iMessage and GitHub actions. But iMessage has had a number of interesting security vulnerabilities over the years in image parsing and deserialization. One example: https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... Or a story from today: https://news.ycombinator.com/item?id=37425007 https://news.ycombinator.com/item?id=37425007 So perhaps the similarity between iMessage and GutHub actions is there are a lot of things that could go wrong. In iMessage it’s a pile of memory unsafe code that was not originally designed to withstand attack. In GutHub actions there is a lot of trust in their parties that could potentially be exploited.
    - SigmundA 3y ago
      And yet Android had multiple high and critical CVE's reported in the last few days with little coverage: https://source.android.com/docs/security/bulletin/2023-09-01 https://source.android.com/docs/security/bulletin/2023-09-01
      - Obscurity4340 3y ago
        Where do CVEs tend to show up app-wise in Android? Is it also messaging or some other system service? With iOS its almost always either iMessage, WebKit, and iCloud Calendar
      - teddyh 3y ago
        «А у вас негров линчуют»
      - jacquesm 3y ago
        This isn't an Android vs Apple article.
        SigmundA 3y ago
        Its not an iOS / iMessage article either but it was brought up here and is the point if this current thread.
      - bdangubic 3y ago
        Coverage is proportional to the number of users :)
  - 3np 3y ago
    The normal thing is to have integration test PRs and other CI actions (which may require access tokens to APIs, inherently or due to naive design) be defined by the incoming branch, creating a vector for an attacker to get access to privileged resources. For certain parts of integration and testing jobs that are operating on untrusted code, it'd therefore be desired to not allow incoming PRs to change certain parts of the CI configuration (not only including .github/workflows, which can be protected using branch protection rules, but the testing framework). It's possible to achieve this by splitting up your workflows and using workflow_run but it's non-obvious and finicky enough that I very rarely see it done. GitHub could make this easier and propose better patterns than they do in their attempt to address the problem[0], which I think could use a 2023 follow-up. [0]: https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ https://securitylab.github.com/research/github-actions-preve... --- In this context, an iMessage message <> a GitHub PR, I guess.
  - randmeerkat 3y ago
    > Could you please expand on your iMessage comparison? I don't understand what you're referencing. https://arstechnica.com/gadgets/2023/09/apple-patches-clickless-0-day-image-processing-vulnerability-in-ios-macos/ https://arstechnica.com/gadgets/2023/09/apple-patches-clickl... iMessage itself is a dumpster fire that time and again has been proven to be an attack vector.
  - eastbound 3y ago
    A lot of useful features are missing from actions/checkout@v3, so people have to either program actions manually, or use ones made by other GitHub users. Actions are build steps, such as opening a firewall before building, preparing a directory, or caching Maven artifacts. It would be very easy to add a backdoor to one of those build steps. The comparison with iMessage is that it’s unsafe by design, at the architecture level, because you’re relying on live code made by anonymous people. One day, attack vectors will be found every second day.
    - PhilipRoman 3y ago
      It strikes me as the classic NPM disease. Do we really need a reusable action for disabling a firewall, uploading files, etc.? I mean if it comes from GitHub that's fine, but for anything else I would rather verify the solution and copy the code. It works like a low-tech lock file, except changes are always visible inline in Git history, so less chance of lazy programmers missing changes. I almost laughed when GitHub suggested me an Action for Makefile based projects. The entire build process in my case consists of "make package"...
      - jacquesm 3y ago
        > if it comes from GitHub that's fine No it isn't. It's become normalized but it isn't fine. Whoever thought it was a good idea to download massive amounts of unaudited code at build time to then run it behind your defensive lines should have thought about that a bit longer. CI/CD is great. GitHub/GitLab are great. But combining the two has substantial risks. More so for languages that have broken package management and namespace issues.
        PhilipRoman 3y ago
        You are of course right. I was thinking more in terms of "how do we save clueless developers (and their users) from themselves". They will probably find more ways to shoot themselves in the foot, but any percentage of prevented vulnerabilities is a positive result. Kind of like people trust Google/Apple with their phones.

tpmx 3y ago

Yes. Remember that not only security researchers but also developers in general are extra juicy targets because of e.g. their AWS credentials that sometimes aren't kept as secure as they need to be. Heck, even if you're doing proper SSO with 2FA the tokens can be stolen and data proxied/exfiltrated. At best they can be used for coin mining (running up a huge bill), at worst for stealing private customer data (and then selling/ransomwaring it).

jacquesm 3y ago
> e.g. their AWS credentials that sometimes aren't kept as secure as they need to be There is some irony in there.

dclowd9901 3y ago

We have pretty high bars for what we allow in terms of outside dependencies, but that doesn’t mean they do. It’s basically a crap shoot if you choose to do open source at all.

ChrisRR 3y ago

And that includes libraries that you blindly pull down from package managers