You are viewing a plain text version of this content. The canonical link for it is here.
Posted to builds@apache.org by Jarek Potiuk <po...@apache.org> on 2021/06/20 15:48:47 UTC
Re: Failure with Github Actions from outside of the organization (out
of a sudden!)
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 <Ja...@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 <Ja...@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 <Ja...@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.vladimir@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
Re: Failure with Github Actions from outside of the organization (out
of a sudden!)
Posted by Matt Sicker <bo...@gmail.com>.
Thanks so much for holding them to account! This is great news. :)
On Sun, Jun 20, 2021 at 10:49 Jarek Potiuk <po...@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 <Ja...@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.Potiuk@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.Potiuk@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.vladimir@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
>