Hello Everyone, GitHub Security Update: You can now specify finer-grained permissions for Github Tokens - something that I complained about to GitHub. This could help in preventing sophisticated supply-chain attacks like the recent codecov attack (https://www.computerweekly.com/news/252499587/Codecov-supply-chain-attack-has-echoes-of-SolarWinds).
One of my bounty issues has been resolved (Brennan - sorry, no reward this time to share). Here is the message I got: "@potiuk I want to thank you taking the time to submit this report. As you're probably already aware, we recently released improved our permissions model for GITHUB_TOKENS, allowing maintainers and developers to have more fine grained control: https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/. Hopefully this helps to solve many of the issues you have outlined. If not, please feel free to reach out again - we're always happy to hear feedback from our users. As this was already a known issue and our engineers had plans in place to improve this work, it is unfortunately not eligible for bounty through our bounty program." I updated the "GitHub Actions status" page https://cwiki.apache.org/confluence/display/BUILDS/GitHub+Actions+status with this recommendation: ALWAYS limit your GitHub write token to as little scope as possible. As of April 2021 there is a possibility of specifying scopes for the permissions of the token you automatically get during your build. https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/ . This could help preventing sophisticated supply-chain attack for example like the recent codecov attack. > On Wed, Dec 30, 2020 at 5:25 PM Jarek Potiuk <jarek.pot...@polidea.com> wrote: > > > > FYI. I've filed two issues to GH via https://bounty.github.com/ - let's see > > what their security teams do with those. > > > > BTW. Brennan, if there is any reward, happy to share it with you :) > > > > J. > > > > > > On Wed, Dec 30, 2020 at 4:03 PM Jarek Potiuk <jarek.pot...@polidea.com> > > wrote: > > > > > Got some feedback from GH support . It's both good and bad. > > > > > > 1) Indeed GITHUB_TOKEN is not available for actions that do not explicitly > > > get it passed to them > > > > > > 2) But it's much worse - the actions themselves can have (and even add) > > > new inputs and get the GITHUB_TOKEN set as default value via: > > > > > > default: ${{ github.token }} > > > > > > In their action.xml. > > > > > > This basically means that if you have any action referred to by TAG, at > > > any point in time anyone can add a new input to it with `default: ${{ > > > github.token }}` - and they have complete access to your repository (even > > > if they were completely safe before). > > > > > > Vladimir - I think that closes the topic about banning GITHUB_TOKEN usage. > > > > > > J. > > > > > > > > > > > > On Wed, Dec 30, 2020 at 2:37 PM Jarek Potiuk <jarek.pot...@polidea.com> > > > wrote: > > > > > >> FYI We looked at the source code of the checkout action and indeed it > > >> seems it uses some kind of token, possibly GITHUB_TOKEN by simply using > > >> this: > > >> > > >> https://github.com/actions/checkout/blob/main/src/input-helper.ts#L108 > > >> > > >> // Auth token > > >> result.authToken = core.getInput('token', {required: true}) > > >> > > >> Seems like this is some kind of a hack. Even if this parameter is marked > > >> as 'required' it's not really required - if you do not specify `token` as > > >> parameter, apparently GITHUB_TOKEN is used. Still waiting for > > >> confirmation > > >> from GitHub on that. > > >> > > >> This means (Vladimir to your point) that it might even be that if actions > > >> have no GITHUB_TOKEN specified in yaml, they can still use it without > > >> user > > >> knowing it. > > >> This is unless this hack only works for the checkout action. There is > > >> nothing in the getInput method to handle that hack, but it seems it > > >> could > > >> be injected externally to the github runner as INPUT_TOKEN env variable. > > >> > > >> https://github.com/actions/toolkit/blob/main/packages/core/src/core.ts#L84 > > >> > > >> This is quite unexpected and really, really bad if that's confirmed. > > >> > > >> J. > > >> > > >> > > >> > > >> On Wed, Dec 30, 2020 at 11:56 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > >> > > >>> Jarek>What credentials are you talking about? > > >>> > > >>> Please report it to security@ then. If it works this way, this is > > >>> serious > > >>> security threat IMHO. > > >>> > > >>> On Wed, Dec 30, 2020 at 11:42 AM Vladimir Sitnikov < > > >>> sitnikov.vladi...@gmail.com> wrote: > > >>> > > >>> > Jarek>What credentials are you talking about? > > >>> > > > >>> > For instance, asfNexusUsername/asfNexusPassword (see > > >>> > https://cwiki.apache.org/confluence/display/INFRA/Gradle+Installations > > >>> ) > > >>> > I assume there exists something like git-websites Jenkins node label > > >>> that > > >>> > has privileges to update project site ( > > >>> > https://cwiki.apache.org/confluence/display/INFRA/Jenkins+node+labels > > >>> ) > > >>> > > > >>> > Jarek>Not as long as the build cannot write to the github repository > > >>> and > > >>> > modify > > >>> > Jarek>code. > > >>> > > > >>> > ASF Jenknis nodes are stateful, and they do have credentials of some > > >>> kind. > > >>> > On top of that, a malicious build script plugin could use developer's > > >>> > credentials > > >>> > to make changes to the repositories. > > >>> > > > >>> > Vladimir > > >>> > > > >>> > > >>> > > >>> -- > > >>> +48 660 796 129 > > >>> > > >> > > >> > > >> -- > > >> > > >> Jarek Potiuk > > >> Polidea <https://www.polidea.com/> | Principal Software Engineer > > >> > > >> M: +48 660 796 129 <+48660796129> > > >> [image: Polidea] <https://www.polidea.com/> > > >> > > >> > > > > > > -- > > > > > > Jarek Potiuk > > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > > > M: +48 660 796 129 <+48660796129> > > > [image: Polidea] <https://www.polidea.com/> > > > > > > > > > > -- > > > > Jarek Potiuk > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > M: +48 660 796 129 <+48660796129> > > [image: Polidea] <https://www.polidea.com/> > > > > -- > Jarek Potiuk, Principal Software Engineer > > Polidea: http://polidea.com, MCE^4: http://mceconf.com > Mobile: +48 660 796 129
