Closed Bug 1822104 Opened 2 years ago Closed 2 years ago

Leak of token when using moz-phab for external project without bug tracker

Categories

(Conduit :: moz-phab, defect, P2)

Production

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wanders, Assigned: wanders)

Details

Attachments

(2 files)

Steps to reproduce:

I was using moz-phab for a non mozilla project. Specifically LLVM.

The arcconfig for LLVM looks like this https://github.com/llvm/llvm-project/blob/main/.arcconfig

Actual results:

My authentication token for the phabricator installation at reviews.llvm.org got sent to bugzilla.mozilla.org.

As part of telementry initialization (telemetry.configure_telemetry -> telemetry.update_user_data -> user.set_user_data -> user.whoami -> bmo.whoami) moz-phab does a call to the bugtracker to try to figure out if user is a mozilla employee. This means doing a request to the bugtracker supplying the phabricator api token in a X-PHABRICATOR-TOKEN header.

If project has not configured any bugtracker in the .arcconfig file (as in the case
for LLVM, because it doesn't have any bugzilla (any longer)) it defaults to bugzilla.mozilla.org. Meaning that my llvm token leaked to mozilla.

$ moz-phab submit --trace --no-bug --no-wip HEAD^
DEBUG    2023-03-13 16:36:39,416 MozPhab (1.4.0)
DEBUG    2023-03-13 16:36:39,416 found git repo in /home/awaldenborg/dev/llvm/llvm-project
DEBUG    2023-03-13 16:36:39,417 $ git -c i18n.logOutputEncoding=UTF-8 -c i18n.commitEncoding=UTF-8 --version
DEBUG    2023-03-13 16:36:39,418 git version 2.34.1
DEBUG    2023-03-13 16:36:39,419 $ git -c i18n.logOutputEncoding=UTF-8 -c i18n.commitEncoding=UTF-8 config --list
DEBUG    2023-03-13 16:36:39,420 https://reviews.llvm.org/api/user.whoami {}
DEBUG    2023-03-13 16:36:42,085 https://bugzilla.mozilla.org/rest/whoami {'url': 'https://bugzilla.mozilla.org/rest/whoami', 'method': 'GET', 'headers': {'X-PHABRICATOR-TOKEN': 'cli-XXXX', 'User-Agent': 'MozPhab/1.4.0'}}
DEBUG    2023-03-13 16:36:42,506 Bugzilla Error: HTTP Error 400: Bad Request
DEBUG    2023-03-13 16:36:42,507 https://bugzilla.mozilla.org/rest/whoami {'url': 'https://bugzilla.mozilla.org/rest/whoami', 'method': 'GET', 'headers': {'X-PHABRICATOR-TOKEN': 'cli-XXXX', 'User-Agent': 'MozPhab/1.4.0'}}
DEBUG    2023-03-13 16:36:42,919 Bugzilla Error: HTTP Error 400: Bad Request
DEBUG    2023-03-13 16:36:43,921 https://bugzilla.mozilla.org/rest/whoami {'url': 'https://bugzilla.mozilla.org/rest/whoami', 'method': 'GET', 'headers': {'X-PHABRICATOR-TOKEN': 'cli-XXXX', 'User-Agent': 'MozPhab/1.4.0'}}
DEBUG    2023-03-13 16:36:44,324 Bugzilla Error: HTTP Error 400: Bad Request
DEBUG    2023-03-13 16:36:46,325 BMOAPIError: Bugzilla Error: Reached maximum retries for BMO API (/whoami).
...

Expected results:

The auth token should not be sent to a different organization.

Thanks for the bug report.

We could skip telemetry if the repo is not a Mozilla repo. Or likely the easiest check would be to skip/abort the Bugzilla API call if the default Bugzilla URL does not share the ending with the repo's Phabricator URL (i.e., in this case .mozilla.org). This could be done in mozphab.user.

I am going to assume no workaround exists for this, since setting an invalid Bugzilla URL (e.g., localhost) will likely cause other things to fail.

Severity: -- → S2
Priority: -- → P2

Patch idea.

I don't know what phabricator host names there are in use at mozilla, so the domains are just a guess.
Also can't really test all scenarios.

Setting an invalid bmo_url is a workaround. Those error are not fatal (and only displayed with --trace). However it retries 4 times with a 1s delay. So it increases startup time with 4s.

Attached patch idea. But maybe better if telemetry (and thus bmo) is skipped alltogether on a non-mozilla phabricator url?

(In reply to anders.waldenborg+github from comment #2)

Created attachment 9322848 [details] [diff] [review]
0001-bmo-only-default-to-mozilla-bugzilla-if-phab-url-is-.patch

Patch idea.

I don't know what phabricator host names there are in use at mozilla, so the domains are just a guess.
Also can't really test all scenarios.

The patch looks good, can you send it via Phabricator and I'll review it there? Thanks for reporting and coming up with a fix so quickly. :)

Flags: needinfo?(anders.waldenborg+github)

For non-mozilla projects that doesn't specify a bmo URL
in its .arcconfig moz-phab defaulted to using
https://bugzilla.mozilla.org for bmo url.

This was problematic as it caused the phabricator API token for the
non-mozilla project to be sent to mozilla's bugzilla.

This commit changes so that the default is calculated when setting up
Repo object rather than when doing request. This allows additional logic
so that it only is set to bugzilla.mozilla.org if the phabricator url
looks like a mozilla owned project.

Assignee: nobody → anders.waldenborg+github
Status: NEW → ASSIGNED

It is in phabricator as https://phabricator.services.mozilla.com/D172540 hopefully I managed to create i properly.

Flags: needinfo?(anders.waldenborg+github)
Attachment #9322924 - Attachment description: Bug 1822104 - bmo: only default to mozilla bugzilla if phab url is mozilla r=sheehan → bmo: only default to mozilla bugzilla if phab url is mozilla (Bug 1822104) r=sheehan

The fix for this bug is live in moz-phab 1.4.2.

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Group: conduit-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: