Backdoor no Linux

amarildosertorio
(usa Fedora)

Enviado em 01/04/2024 - 20:31h

Não entendi. A vulnerabilidade foi identificada e relatada à comunidade. Além disso, as distribuições importantes e estáveis nem sequer foram afetadas.

Minions
(usa Nenhuma)

Enviado em 01/04/2024 - 23:52h

A questão não é que distribuições importantes e estáveis não foram afetadas. O problema vai além de backdoor no Linux.

amarildosertorio
(usa Fedora)

Enviado em 02/04/2024 - 10:36h

Honestamente, ainda não entendi sua afirmação. Reconheço que a comunidade identificar uma vulnerabilidade em uma biblioteca que ainda não havia sido oficialmente considerada estável um sinal excelente. Isso destaca a vitalidade e a atuação ativa da comunidade, demonstrando seu compromisso com a qualidade e a segurança do software.

Seria interessante compartilhar aqui um resumo dos mecanismos empregados pela Red Hat.

1. Análise de Vulnerabilidades: A Red Hat realiza análises regulares de vulnerabilidades em pacotes de software, incluindo aqueles provenientes da comunidade. Eles acompanham bancos de dados de vulnerabilidades, como o CVE (Common Vulnerabilities and Exposures), e aplicam patches ou atualizações de segurança conforme necessário para proteger seus usuários.

2. Patches de Segurança: Quando uma vulnerabilidade é descoberta em um pacote de software, a Red Hat desenvolve e distribui patches de segurança para corrigir essas vulnerabilidades. Isso se aplica não apenas aos pacotes desenvolvidos internamente, mas também aos pacotes da comunidade que são distribuídos como parte dos produtos Red Hat.

3. Avaliação de Código Aberto: A Red Hat tem uma equipe dedicada que revisa e avalia o código-fonte de pacotes de software de código aberto, antes de incluí-los em seus produtos. Isso ajuda a identificar possíveis problemas de segurança antes mesmo de os pacotes serem integrados.

4. Colaboração com a Comunidade: A Red Hat muitas vezes colabora com a comunidade de código aberto para identificar e corrigir problemas de segurança em pacotes de software. Eles podem enviar patches de segurança upstream e trabalhar em conjunto com os mantenedores do projeto para garantir que as correções sejam implementadas e distribuídas amplamente.

5. Monitoramento Contínuo: Além de aplicar patches de segurança conforme necessário, a Red Hat também monitora continuamente a segurança de seus pacotes de software. Isso inclui acompanhamento de novas vulnerabilidades, análise de ameaças emergentes e ações proativas para proteger os usuários contra possíveis ataques.

GRM
(usa openSUSE)

Enviado em 02/04/2024 - 10:45h

Infelizmente, pacotes abandonados e cruciais tem que ser adotado pelo mantenedor da alguma distro estabelicida como debian red hat e afins(fork ou algo do tipo), se não é crítico, não pode fazer parte do repositório oficial.

Disciplina é liberdade
Compaixão é fortaleza
Ter bondade é ter coragem

Minions
(usa Nenhuma)

Enviado em 03/04/2024 - 02:36h

https://openwall.com/lists/oss-security/2024/03/29/4

---------------------------------------------------------
Camarão que dorme, acaba na empada!

Minions
(usa Nenhuma)

Enviado em 08/04/2024 - 03:22h

Agora falta aparece no zstd kkkkkk

https://diolinux.com.br/noticias/fwupd-abandona-o-xz-utils.html

.....
sugerindo começarem a exigir que os commits sejam assinados, facilitando rastrear a origem de possíveis códigos maliciosos, mas ainda não chegaram a uma conclusão.
....

rastrear a origem acho que será difícil mesmo sendo assinados.

---------------------------------------------------------
Camarão que dorme, acaba na empada!

GRM
(usa openSUSE)

Enviado em 09/04/2024 - 12:34h

ao que parece a questão do xz esfriou

Disciplina é liberdade
Compaixão é fortaleza
Ter bondade é ter coragem

aguamole
(usa KUbuntu)

Enviado em 09/04/2024 - 12:59h

Daqui a um tempo surge novas vulnerabilidades, a dica é a mesma, aproveita que as atualizações são gratuitas e fique sempre com o sistema atualizado.

amarildosertorio
(usa Fedora)

Enviado em 09/04/2024 - 18:25h

Andres Freund exemplificou a importância da liberdade e do acesso ao código-fonte.

Vale ressaltar que a versão na qual a vulnerabilidade foi encontrada não foi incorporada às distribuições estáveis.

Do meu ponto de vista, a maior preocupação reside nos produtos de terceiros que incorporam essas bibliotecas sem suporte algum.

aguamole
(usa KUbuntu)

Enviado em 09/04/2024 - 22:14h

Le no canaltech que o Andres Freund esta ajudando a fazer a engenharia reversa de software dos códigos da tentativa do ataque supplychain, provavelmente vai dar tudo certo.
https://canaltech.com.br/seguranca/sozinho-um-desenvolvedor-pode-ter-salvado-a-internet-de-um-grande...

Mauriciodez
(usa Debian)

Enviado em 09/04/2024 - 23:18h

eu sou meio tobó nisso então tenho a seguinte questão: pelo que eu entendi, o código do pacote estava com o insert do backdoor, este por sua vez dava acesso via SSH ... pra mim isso parece bem simples de entender ... o que eu não entendo é como alguém vai fazer engenharia reversa em open source !!!!

ou eu tô viajando ???

------------------------------------------------------| Linux User #621728 |------------------------------------------------------



                                " Nem sempre é amigo aquele que te tira do buraco !!! ( Saddam Hussein )"



------------------------------------------------------| Linux User #621728 |------------------------------------------------------ 

amarildosertorio
(usa Fedora)

Enviado em 09/04/2024 - 23:35h

Aparentemente o código está obscurecido.

Considerando as informações mais recentes, essa vulnerabilidade não deveria ser classificada como uma “ameaça que burla a autenticação”, mas sim como “execução remota de código” (RCE). A backdoor intercepta a função RSA_public_decrypt, verifica a assinatura do host usando a chave fixa Ed448 e, se verificada com sucesso, executa o código malicioso enviado pelo host por meio da função system(), não deixando rastros nos logs do sshd.

Referência: https://www.kaspersky.com.br/blog/cve-2024-3094-vulnerability-backdoor/22371/