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/>
