Thanks so much for holding them to account! This is great news. :) On Sun, Jun 20, 2021 at 10:49 Jarek Potiuk <pot...@apache.org> wrote:
> 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 >
