Jonatan Kłosko

Existe um problema onde a neutralização inadequada de entrada durante a geração de páginas web permite Cross-site Scripting (XSS) de mutação. Isso ocorre durante um ciclo de análise (parse) e serialização de HTML fornecido por um invasor. As funções `LazyHTML.to html/2` e `LazyHTML.Tree.to html/2` determinam se devem escapar o texto de um elemento baseando-se apenas no nome da tag. Consequentemente, um elemento `style` ou `script` dentro de conteúdo estrangeiro SVG ou MathML é analisado com referências de caracteres decodificadas, mas serializado como um elemento de texto bruto HTML, fazendo com que o texto seja emitido sem escape. Isso permite que marcações codificadas fechem o elemento ao serem reanalisadas e se tornem marcações ativas. Aplicações que analisam HTML não confiável, filtram o documento ou a árvore e, em seguida, o serializam para exibição são afetadas, pois a carga útil permanece como um nó de texto simples que ignora filtros de elementos ou atributos.

Um problema de Injeção de Comando de SO existe onde os comandos de configuração de implantação são gerados sem a devida filtragem de escape de shell dos valores de variáveis de ambiente. As funções `docker instructions/2` e `fly instructions/4` em `lib/livebook web/live/hub/teams/deployment group agent component.ex` interpolam esses valores, que são processados através de `online docker info/3`. Como os valores são colocados dentro de palavras de shell entre aspas duplas, um invasor com privilégios para definir variáveis de ambiente do grupo de implantação pode usar a substituição de comando (como `$(...)` ou crases) ou aspas duplas para injetar comandos arbitrários. Esses comandos são então executados na máquina local de qualquer usuário que copiar e executar as instruções de configuração geradas a partir da interface web. As instruções do Kubernetes não são afetadas, pois utilizam escape de manifesto YAML.

Um erro de validação de origem permite que JavaScript de saída de notebook não confiável acione atalhos de teclado de toda a sessão. O recurso JS-view renderiza JavaScript em um iframe sandboxed de origem cruzada. No entanto, o shell do iframe em `iframe/priv/static/iframe/v5.html` encaminha eventos `keydown` para a página pai sem verificar `Event.isTrusted`. Consequentemente, eventos sintetizados via `window.dispatchEvent` são tratados como pressões de tecla genuínas. O relé em `assets/js/hooks/js view.js` redistribui esses eventos, que são então processados pelo manipulador de atalhos global em `assets/js/hooks/session.js` durante a fase de captura. Isso permite que scripts sandboxed executem atalhos em `LivebookWeb.SessionLive`, como forçar a avaliação de todas as células no notebook ou reiniciar o runtime, o que descarta o estado na memória. Um terceiro atalho pode excluir a célula focada. O impacto mais crítico é a avaliação completa forçada, que executa o código Elixir do notebook sem o consentimento do usuário. Isso pode ocorrer quando um usuário abre um notebook de terceiros ou de documentação publicada, e o efeito é espelhado para todos os colaboradores conectados.

Um problema de Relative Path Traversal permite que um invasor grave um arquivo com conteúdo controlado em um caminho arbitrário no sistema. Isso ocorre porque o caminho de importação em `Livebook.LiveMarkdown.Import.file entry metadata to attrs/1` recebe o nome da fonte do notebook literalmente, sem validação. Para entradas de arquivo do tipo URL, a função `Livebook.Session.file entry cache file/2` resolve o nome abaixo do diretório temporário da sessão sem verificar se o resultado permanece dentro desse diretório. Além disso, `Livebook.FileSystem.Utils.resolve unix like path/2` colapsa segmentos de diretórios pai, mas limita apenas na raiz do sistema de arquivos. Consequentemente, quando o conteúdo é solicitado e não existe cache, o sistema grava o corpo da resposta no caminho resolvido, criando diretórios pai conforme necessário. Isso permite que um invasor controle tanto o destino quanto o conteúdo do arquivo gravado em qualquer lugar onde o processo tenha permissões de gravação. Uma falta de verificação de contenção semelhante existe em `Livebook.Session.to attachment file entry/2`. Uma vítima aciona isso ao abrir um notebook fornecido por um invasor e fazer com que a entrada seja buscada dentro de sua sessão autenticada.

Um problema de Cross-Site Request Forgery (CSRF) ocorre quando o Livebook é configurado para usar o Livebook Teams para identidade. A função `handle request/4` em `lib/livebook/zta/livebook teams.ex` processa callbacks do tipo OAuth que contêm um marcador `teams identity` e um parâmetro `code`. Como a função `create auth request/1` em `lib/livebook/teams/requests.ex` não gera um estado ou nonce, o sistema não consegue verificar se o callback corresponde à sessão que iniciou o login. Um atacante na mesma organização do Livebook Teams pode iniciar um fluxo de login, capturar o código de autorização e induzir uma vítima a abrir uma URL contendo esse código. Isso faz com que a sessão da vítima seja vinculada à identidade do atacante. Consequentemente, qualquer trabalho, segredo ou dado produzido pela vítima é atribuído e acessível ao atacante, enquanto a vítima acredita estar usando sua própria conta.

Uma falha de segurança do tipo failing open no livebook permite que um cliente de rede não autenticado obtenha acesso total a um servidor que impõe a identidade por meio do Livebook Teams. Isso ocorre quando um Agente Livebook ou Servidor de Aplicativo armazena em cache um identificador de grupo de implantação que se torna irresolvível, como quando o grupo é excluído enquanto o agente está desconectado. A função `handle call/3` em `lib/livebook/hubs/team client.ex` não distingue entre um grupo irresolvível e um onde a imposição de identidade está desativada, levando o sistema a relatar que a imposição foi desligada. Consequentemente, a função `authenticate/3` em `lib/livebook/zta/livebook teams.ex` retorna metadados de identidade vazios, que o `build current user/3` no `LivebookWeb.UserPlug` mescla em um novo usuário com acesso total padrão. Este acesso é então concedido por `authorized?/1` no `LivebookWeb.AuthPlug`. Um invasor pode explorar isso para ler notebooks e segredos, executar código no runtime do servidor e interromper as operações.