Adrian Dombeck

A correspondência de identidade do usuário na função `UpdateUser()` (localizada em internal/users/manager.go) resolve logins usando um ID de provedor com escopo de broker. Se o ID do provedor não for reconhecido, o sistema retorna à correspondência pelo nome de usuário, sem rejeitar IDs de provedores não vazios que sejam conflitantes. Se um provedor de identidade reatribuir um endereço de e-mail (usado como nome de usuário) a uma nova conta, essa nova conta herda o UID local e o diretório home do usuário anterior ao fazer login. Isso permite que o novo usuário acesse e modifique arquivos do usuário anterior, incluindo chaves SSH e tokens de API de nuvem, vinculando silenciosamente o registro da conta local à nova identidade.

Um invasor local capaz de registrar nomes de usuário poderia falsificar a identificação de outro usuário e obter seus privilégios devido à aleatorização insuficiente das identificações de usuário. O problema decorre do método `GenerateID`, que atribui identificações de usuário como uma função pura do nome de usuário, e o conjunto de UIDs é pequeno demais para que a atribuição pseudoaleatória funcione. Isso permite que um adversário registre vários usuários com IDs conflitantes ou registre um único usuário cujo ID entre em conflito com o de um usuário alvo. O invasor pode contornar a verificação de exclusividade criando uma situação em que o administrador do sistema limpe `/var/cache`, visando uma conta do sistema cujo UID esteja no intervalo do `authd`, ou visando uma conta que não tenha feito login em um sistema específico há mais de 6 meses.