Dan Jones

**Nome do software vulnerável e versões afetadas** Versões do matrix-android-sdk2 anteriores à 1.5.1 **Descrição** Um invasor em colaboração com um servidor doméstico malicioso pode criar mensagens que parecem ter sido enviadas por outra pessoa, sem qualquer indício. Essa vulnerabilidade pode ser usada para realizar ataques direcionados, enviando mensagens falsas para o dispositivo e, potencialmente, injetando segredos de backup de chaves. O problema se deve a uma vulnerabilidade de confusão de protocolo que aceita mensagens para o dispositivo criptografadas com Megolm em vez de Olm. **Recomendações** Para versões anteriores à 1.5.1, atualize para a versão 1.5.1, que aceita apenas mensagens para o dispositivo criptografadas com Olm e interrompe a assinatura de backups após a descriptografia bem-sucedida. Como solução temporária, considere evitar o uso de métodos de verificação por emoji/QR para novos logins até que a atualização seja aplicada e, em vez disso, use a verificação por senha. Restrinja o acesso a dispositivos não confiáveis e descarte os segredos recebidos deles. Certifique-se de que os backups de chaves só sejam utilizáveis se tiverem uma assinatura válida de um dispositivo confiável.

**Nome do software vulnerável e versões afetadas** Versões do Matrix JavaScript SDK anteriores à 19.7.0 **Descrição** Um invasor em conluio com um servidor doméstico malicioso pode criar mensagens que parecem ter sido enviadas por outra pessoa. Essas mensagens serão marcadas com um escudo cinza em algumas plataformas, mas essa marcação pode não aparecer em outras. Este ataque é possível devido ao fato de o matrix-js-sdk implementar uma estratégia de encaminhamento de chaves excessivamente permissiva no lado receptor. O SDK agora define um sinalizador `trusted` na mensagem descriptografada após a descriptografia, com base no fato de a chave usada para descriptografar a mensagem ter sido recebida de uma fonte confiável. Os clientes precisam garantir que as mensagens descriptografadas com uma chave com `trusted = false` sejam sinalizadas adequadamente, por exemplo, exibindo um aviso para tais mensagens. Esse ataque requer coordenação entre um servidor doméstico malicioso e um invasor, e aqueles que confiam em seus servidores domésticos não precisam de uma solução alternativa. **Recomendações** Atualize para a versão 19.7.0 ou posterior, que inclui uma política padrão mais rigorosa para aceitar encaminhamentos de chaves. Como solução alternativa temporária, considere marcar adequadamente as mensagens descriptografadas com uma chave com `trusted = false`, por exemplo, exibindo um aviso para essas mensagens. Restrinja o acesso ao mecanismo de encaminhamento de chaves para minimizar o risco de exploração. Certifique-se de que os clientes tratem as mensagens com `trusted = false` corretamente, por exemplo, exibindo um aviso para essas mensagens.

**Nome do software vulnerável e versões afetadas** Versões do Matrix JavaScript SDK anteriores à 19.7.0 **Descrição** O problema é causado por um bug no matrix-js-sdk, no qual um invasor em conluio com um servidor doméstico malicioso poderia interferir no fluxo de verificação entre dois usuários, injetando sua própria identidade de usuário com assinatura cruzada no lugar da identidade de um dos usuários. Isso levaria o outro dispositivo a confiar/verificar a identidade do usuário sob o controle do servidor doméstico, em vez da identidade pretendida. A vulnerabilidade é parcialmente possibilitada pela decisão de design de tratar identidades de usuário com assinatura cruzada como dispositivos Matrix no lado do servidor. Nenhuma outra implementação examinada apresentou vulnerabilidade. A partir da versão 19.7.0, o matrix-js-sdk foi modificado para verificar novamente se a chave assinada é a mesma que foi verificada, em vez de apenas referenciar a chave pelo ID. Uma verificação adicional foi implementada para relatar um erro quando um dos IDs de dispositivo corresponder a uma chave de assinatura cruzada. **Recomendações** Para versões anteriores à 19.7.0, atualize para a versão 19.7.0 ou posterior para resolver o problema. Como solução temporária, considere revisar sua lista de dispositivos ou a lista de dispositivos de outros usuários para identificar dispositivos com IDs no formato de uma chave de assinatura cruzada base64 (por exemplo, `5XaczGNlfz0bl8R1IX5qn+tBoue2tWJqLMh+SDUuvCk`) em vez do ID clássico do dispositivo (por exemplo, `SEHACYDHMG`). Se você confia no seu servidor doméstico, não é necessária nenhuma solução alternativa específica.

**Nome do software vulnerável e versões afetadas** Versões do Matrix JavaScript SDK anteriores à 19.7.0 **Descrição** A vulnerabilidade permite que um invasor, em cooperação com um servidor doméstico malicioso, crie mensagens que pareçam ter sido enviadas por outra pessoa, sem qualquer indicação de que se trata de uma falsificação. Um invasor experiente poderia explorar essa vulnerabilidade para realizar um ataque direcionado, enviando mensagens falsas para o dispositivo que pareçam ter sido originadas por outro usuário. Isso pode permitir a injeção do segredo de backup da chave durante a autoverificação, fazendo com que um dispositivo alvo utilize um backup de chave malicioso falsificado pelo servidor doméstico. Esses ataques são possíveis devido a uma vulnerabilidade de confusão de protocolo que aceita mensagens para o dispositivo criptografadas com Megolm em vez de Olm. O ataque requer coordenação entre um servidor doméstico malicioso e um invasor. **Recomendações** Para versões anteriores à 19.7.0, atualize para a versão 19.7.0 ou posterior, que aceita apenas mensagens para o dispositivo criptografadas com Olm e inclui verificações adicionais de segurança. Como precaução, evite usar métodos de verificação por emoji/QR para novos logins até que a correção seja aplicada e, em vez disso, verifique com sua senha de segurança. Se você confia no seu servidor doméstico, não é necessária nenhuma solução alternativa específica.

**Nome do software vulnerável e versões afetadas** Versões do matrix-ios-sdk anteriores à 0.23.19 **Descrição** A vulnerabilidade permite que um invasor, em cooperação com um servidor doméstico malicioso, crie mensagens que pareçam ter sido enviadas por outra pessoa, sem qualquer indício de falsificação. Um invasor sofisticado poderia empregar essa vulnerabilidade para realizar um ataque direcionado, enviando mensagens falsas para o dispositivo que parecem ter origem em outro usuário. Isso pode permitir a injeção do segredo de backup da chave durante a autoverificação ou fazer com que um dispositivo alvo utilize um backup de chave malicioso falsificado pelo servidor doméstico. Os ataques são possíveis devido a uma vulnerabilidade de confusão de protocolo que aceita mensagens para o dispositivo criptografadas com Megolm em vez de Olm. **Recomendações** Para versões anteriores à 0.23.19, atualize para a versão 0.23.19 ou posterior para aceitar apenas mensagens para o dispositivo criptografadas com Olm. Como solução temporária, considere não verificar novos logins usando métodos de verificação por emoji/QR até que a correção seja aplicada. Para minimizar o risco de exploração, certifique-se de que confia no seu servidor doméstico, pois o ataque requer coordenação entre um servidor doméstico malicioso e um invasor.

**Nome do software vulnerável e versões afetadas** Versões do Matrix iOS SDK anteriores à 0.23.19 **Descrição** A vulnerabilidade permite que um invasor, em cooperação com um servidor doméstico malicioso, crie mensagens que parecem ter sido enviadas por outra pessoa. Essas mensagens podem ser marcadas com um escudo cinza em algumas plataformas, mas esse indicador pode não aparecer em outras. Isso se deve a uma estratégia de encaminhamento de chaves excessivamente permissiva implementada no SDK do Matrix para iOS. O SDK foi atualizado para aceitar apenas chaves encaminhadas em resposta a solicitações emitidas anteriormente e somente de dispositivos próprios e verificados. Um sinalizador `trusted` é definido em mensagens descriptografadas com base no fato de a chave usada para a descriptografia ter sido proveniente de uma fonte confiável. Os clientes devem garantir que as mensagens descriptografadas com uma chave marcada como `trusted = false` sejam devidamente sinalizadas, por exemplo, exibindo um aviso. Esse ataque requer coordenação entre um servidor doméstico malicioso e um invasor. **Recomendações** Para versões anteriores à 0.23.19, atualize para a versão 0.23.19 ou posterior para resolver o problema. Como solução temporária, considere implementar uma política rígida de encaminhamento de chaves e garantir que as mensagens descriptografadas com chaves não confiáveis sejam marcadas com avisos, como a exibição de um escudo cinza ou um indicador semelhante. Os clientes devem garantir que as mensagens com `trusted = false` sejam tratadas adequadamente, por exemplo, exibindo um aviso para tais mensagens.