Ohxorud-Dev

Existe um problema no processo de montagem de blobs entre repositórios onde o pacote de destino é validado em relação à restrição `public-only` de um token, mas o blob de origem é verificado apenas em relação às permissões completas da conta do proprietário do token. Um invasor usando um token `public-only` com o escopo `write:package` pode montar um blob de um pacote privado em um namespace de pacote público, desde que o proprietário do token tenha acesso de leitura ao pacote privado e acesso de escrita ao público. Isso permite que blobs privados, como camadas de contêiner, sejam acessados e baixados por qualquer usuário através do pacote público.

O Gitea permite que um token com restrições `public-only,write:repository` atualize o branch de cabeça (head branch) de um pull request privado. Isso ocorre porque o sistema valida a restrição de apenas-público do token em relação à rota do repositório base público, mas não reaplica essa restrição ao repositório de cabeça privado durante o processo de atualização. Consequentemente, um invasor com tal token pode fazer com que o Gitea envie commits de um repositório base público para um branch de cabeça privado, ignorando as limitações de acesso pretendidas. Detalhes técnicos incluem: - **API Endpoint:** `POST /api/v1/repos/{public-owner}/{public-repo}/pulls/{index}/update` - **Função Vulnerável:** `UpdatePullRequest()` Se o Gitea Actions estiver habilitado no repositório de cabeça privado, esse envio não autorizado também pode disparar a execução de fluxos de trabalho (workflows) de `push` do repositório privado.

Um problema de escalação de privilégios existe no endpoint de API `POST /users/{username}/tokens` utilizado para criar Tokens de Acesso Pessoal. O endpoint é protegido pelo middleware `reqBasicOrRevProxyAuth`, que foi projetado para exigir autenticação baseada em senha para evitar que um token comprometido seja usado para gerar novos tokens. No entanto, se um token for fornecido no formato `Authorization: Basic <token>:x-oauth-basic`, o sistema define incorretamente o `AuthedMethod` como `basic` e `IsBasicAuth` como `true`, ignorando a proteção do middleware. Uma vez superada a proteção, a função `CreateAccessToken` não aplica um limite de escopo, o que significa que ela não verifica se os escopos solicitados são um subconjunto dos escopos atuais do solicitante. Consequentemente, um invasor que possua um token restrito (como um com permissões apenas de `write:user`) pode criar um novo token com o escopo `all`, obtendo acesso total à conta sem saber a senha do usuário.

No caminho do Git Smart HTTP, o sistema falha ao aplicar as permissões de token de acesso com escopo de repositório quando os tokens são fornecidos via autenticação Bearer. Embora a função `CheckRepoScopedToken()` seja projetada para validar escopos, ela retorna prematuramente se a requisição não estiver utilizando autenticação HTTP Basic. Consequentemente, um Token de Acesso Pessoal (PAT) ou token OAuth2 enviado como `Authorization: Bearer <token>` ignora completamente as verificações de escopo. Isso permite que um token com permissões limitadas (por exemplo, apenas `read:notification`) realize operações como clonar ou buscar repositórios privados sem o escopo `read:repository`, ou enviar alterações (push) para repositórios sem o escopo `write:repository`, desde que o proprietário do token possua as permissões de RBAC de repositório necessárias. O problema afeta a função `CheckRepoScopedToken()` e impacta as rotas do Git Smart HTTP.