Groupware e webmail: pacote oficial do Horde continha backdoor desde novembro
O servidor FTP oficial dos aplicativos Horde e Groupware foi infiltrado para inserir um backdoor nos pacotes Horde 3.3.12, Groupware 1.2.10 e sua versão webmail. O Horde 4.0, o servidor CVS e o Git não foram afetados.
A inserção do backdoor ocorreu no início de novembro, e foi descoberta há poucos dias. No momento as versões disponíveis para download já estão livres do backdoor.
Quem instalou os aplicativos afetados a partir de um pacote obtido no servidor do projeto (diretamente ou por meio de distribuidores) entre novembro e o último dia 7 de janeiro esteve exposto de forma preocupante, pois o backdoor permitia a seus criadores a execução de comandos arbitrários em PHP nos servidores afetados.
Ambos os projetos tiveram atualizações nos últimos dias para não apenas remover o backdoor, mas também corrigir outras vulnerabilidades críticas. (via h-online.com – “Horde Groupware contains backdoor – The H Open Source: News and Features”)
@brlinuxblog
Feed RSS
Quando li sobre isso ontem no H fiquei pensando se nessas horas não compensa o conservadorismo do Debian.
(Embora não sei se não foi afetado também)
O “conservadorismo” do Debian se justifica na estabilidade e segurança do servidor.
Spif,
Obrigado por interpretar o texto para os demais leitores.
@Weber Jr,
O QA do Debian costuma sempre analisar os códigos de suas aplicações empacotadas.. muito provavelmente o bug deve existir em outros lugares… mas não lá. Agora.. problemas acontecem em qualquer distribuição.. e se pensar em ser “conservador”, o RedHAT com 10anos de TS é super conservador e o Ubuntu LTS com 5 anos… também… e agora? :D
“O QA do Debian costuma sempre analisar os códigos de suas aplicações empacotadas.. muito provavelmente o bug deve existir em outros lugares… mas não lá.”
Sim, é o que eu imaginei, e acho muito bom.
“Agora.. problemas acontecem em qualquer distribuição..”
Claro que sim, mas o Debian, principalmente depois que surgiu o Ubuntu, recebeu muita crítica por ser “lento” na adoção de versões novas dos softwares empacotados. Por isso comentei.
‘se pensar em ser “conservador”, o RedHAT com 10anos de TS é super conservador e o Ubuntu LTS com 5 anos… também… e agora? :D’
Acho que aí não se aplica, é mais uma questão de suporte do que precaução.
é impressionantes em todos os lugares e profissões existem pessoas mal caráter, por isso sempre enfrentaremos esse problemas em pacotes.
Más deixando a humanidade de lado e voltando ao sistema, o linux mais seguro é aquele onde voce tem controle do que está sendo instalado. compilar os fontes em servidores de produção é essencial e aumenta ainda mais a segurança dessas aplicações. seja no ubuntu, no debian ou no slack.
Tiago Nóbrega: http://www.defendendoolinux.in
@tiagonobrega, discordo plenamente de você.
se você baixou o código fonte do projeto diretamente do site oficial – que por sinal foi comprometido – e compilou vc mesmo, continuaria com o mesmo problema dos outros, e o estrago seria bem maior, por causa da falsa sensação de segurança.
Compilar codigo infectado e achar que está seguro só porque baixou do site oficial é tão inseguro do que baixar do astalavista e auditar linha por linha.
@Tiago Nóbrega sem analisar linha por linha e acompanhar os projetos upstream, compilar é mais perigoso do que confiar em empacotadores.
@Tiago,
Além do que.. deixar um compilador funcional no seu servidor só ajuda pessoas que conseguiram acesso ao seu sistema na compilação fácil de backdoors. :D
Fonte vs Pacote, mais uma das picuinhas inúteis do Software Livre.
(BTW, prefiro pacote)
Alguém pode acrescentar alguma informação a respeito de se foi feita alguma iniciativa para identificar quem enviou o backdoor para o repositório? Isso seria importante para evitar novas ocorrências do mesmo tipo de problema.
Governança aberta é algo bastante produtivo, mas é vulnerável a esse tipo de ataque.