Alertas do Couchbase

o pacote golang.org/x/text/encoding/unicode que pode fazer com que o decodificador UTF-16 entre em um loop infinito, fazendo com que o programa trave ou fique sem memória.

Se o serviço de backup falhar ao registrar uma mensagem de auditoria, ele vaza os dados do log de auditoria no arquivo backup_service.log, que não é mascarado.

Ao falhar no estabelecimento de conexão TLS para um Link Remoto do Analytics configurado com encryption=full, o tempo de execução tentava descobrir a porta TLS (não padrão) tentando uma conexão não TLS com o cluster remoto, usando SCRAM-SHA para autenticação. Embora as credenciais não sejam compartilhadas com o SCRAM-SHA, pode não ser esperado que o sistema rebaixe o nível de criptografia prescrito que especificava uma conexão TLS. Esse mecanismo de fallback foi removido e, em caso de falha inicial ao estabelecer uma conexão TLS, o CONNECT LINK simplesmente falhará até que a porta TLS correta seja fornecida como parte da configuração do link.

Ao criar índices secundários com o Serviço de Analytics do Couchbase Server, existem algumas validações nos campos indexados que são relatadas ao usuário e registradas em log. A mensagem de erro com o código ASX0013 é usada em vários caminhos para relatar e registrar que há um nome de campo duplicado. Os nomes dos campos nessas mensagens de validação registradas não são mascarados. Além disso, os erros com o código ASX1079 possuem nomes de campos que não são mascarados.

Administradores que adicionam um nó não confiável a um cluster podem, inadvertidamente, correr o risco de transmitir o cookie do cluster, que deve permanecer em sigilo. Isso pode ser resolvido com a implantação de criptografia TLS com certificados assinados por Autoridade Certificadora. Ao usar o TLS, é obrigatório que um certificado confiável esteja presente no nó de entrada a partir da versão 7.1.0 do Couchbase Server. Reconhecimento: Ofir Hamam, pesquisador de segurança do Advanced Security Center da EY Israel

O Couchbase Operator 2.2.0 introduziu uma otimização que simplificou a coleta de logs. Quando os logs são coletados, a ferramenta de suporte – “cbopinfo” – é utilizada para coletar os recursos do Kubernetes necessários para obter visibilidade do estado pretendido do recurso e do status atual do recurso. Antes das versões afetadas, os dados de segredos eram ocultados (redacted), no entanto, essa funcionalidade não foi mantida no novo método de coleta. Como resultado, os logs continham erroneamente quaisquer senhas, tokens e chaves privadas dentro do escopo da coleta de logs. Por padrão, esse escopo será limitado ao namespace do Kubernetes no qual o cluster do Couchbase Server inspecionado reside. A exceção a isso é se a flag –system foi especificada, caso em que todos os segredos na plataforma foram expostos. Os logs são usados para identificar e solucionar problemas de clientes e, portanto, apenas os clientes que forneceram logs com as versões de ferramentas especificadas são afetados. O Couchbase garantirá que todos os logs afetados que foram fornecidos tenham seus dados confidenciais ocultados.