Via HackerOne. There are two attacks here:
- Configuring mirroring to a file:// URI to place files on disk or overwrite another repository. This is not particularly severe.
- Configuring cloning from a file:// URI to read repositories you should not have access to. This is more severe.
Historically, repository creation and editing explicitly supported file:// URIs to deal with use cases where you had something else managing repositories on the same machine. Since there were no permissions, repository management was admin-only, and you couldn't mirror, this was fine.
As we've evolved, this use case is a tiny minority use case and the security implications of file:// URIs overwhelm the utility it provides. Prevent the use of file:// URIs. Existing configured repositories won't stop working, you just can't add any new ones.
Also prevent localPath from being set via Conduit (see T4039).