gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
Mais um alerta e nova versão OpenSSH (3.7.1p2)
Contribuído por pls em 24-09-03 0:21
do departamento arghhh-que-isto-anda-mauzito
Teenagers com demasiado tempo livre... Antes de entrarem em "panic mode": o bug (explorável remotamente) foi detectado no código introduzido na versão 3.7.1, nas rotinas do PAM (i.e. afecta apenas a versão "portable" do OpenSSH - ou seja a que corre em todos os sistemas operativos com excepção do OpenBSD). Nos casos em que seja possível não utilizar o PAM (compilar com "./configure --with-pam=no" ou meter "UsePam no" no sshd_config e arrancar de novo o daemon) isso basta... como alternativa (a recompilar o código antigo ou mudar a configuração) a versão "3.7.1p2" já está disponível para download.

Quem fez patches (em vez de upgrade para a versão 3.7 ou 3.7.1), e está a utilizar o antigo código de acesso aos PAM (anterior à versão 3.7), não está vulnerável.

Advisory
Lista de mirrors do OpenSSH

O verdadeiro significado de "culo" | Onde e' que esta' o Wi-Fi?  >

 

gildot Login
Login:

Password:

Referências
  • Advisory
  • Lista de mirrors do OpenSSH
  • Mais acerca Teenagers com demasiado tempo livre...
  • Também por pls
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Implementações do SSH (Pontos:3, Informativo)
    por sena em 24-09-03 4:28 GMT (#1)
    (Utilizador Info) http://smux.net/

    Estou, considerando os últimos acontecimentos relacionados com o OpenSSH, a considerar implementações alternativas do SSH.

    As alternativas que conheço:

    • LSH, o ssh da GNU - Software Livre, mas estou um bocado inseguro quanto a este programa, já que foi descoberto um Remote Root Exploit há três dias.
    • FreSSH - Licença BSD, ainda não implementa a versão 2.0 do protocolo, o que é uma grande falha.
    • SSH Tectia Server, o SSH da ssh.com - Não é software livre, mas tem uma licença Non-commercial interessante (é open-source e permite ao utilizador criar bugfixes e implementar novas features), tem uma data de features e parece bastante sólido e seguro.

    Que opiniões têm sobre estes programas? O que escolher, tendo em conta factores técnicos, políticos e comerciais? O que usar em casa, na universidade e na empresa?

    Cumps, João Ribeiro
    --
    sena@smux.net
    http://smux.net/

    Re:Implementações do SSH (Pontos:2, Interessante)
    por moonrider em 24-09-03 8:57 GMT (#2)
    (Utilizador Info) http://127.0.0.1
    Penso que não há qualquer versão do protocolo SSH que se aplique ao teu caso, volta ao telnet.
    Esta política do "muda porque tem bugs" acontece devido ao excesso de opções no mercado... O OpenSSH continua a ser uma das melhores implementações do SSH, infelizmente tem bugs, mas isso não tem propriamente uma cura total.
    Cada vez que tens um problema com o teu carro compras um novo ?
    Re:Implementações do SSH (Pontos:1)
    por sena em 24-09-03 12:02 GMT (#9)
    (Utilizador Info) http://smux.net/
    Penso que não há qualquer versão do protocolo SSH que se aplique ao teu caso, volta ao telnet.

    É este o teu conselho? :/

    Cada vez que tens um problema com o teu carro compras um novo?

    Esta é uma comparação completamente pertinente. :/

    Ontem à noite, para experimentar, instalei o ssh da ssh.com. Ao fim de uns minutos já tinha uma instalação com as funcionalidades que tinha com o OpenSSH. Deu-me um bocado menos de trabalho do que comprar um carro novo...

    Cumps, João Ribeiro
    --
    sena@smux.net
    http://smux.net/

    Re:Implementações do SSH (Pontos:2)
    por racme em 24-09-03 12:55 GMT (#14)
    (Utilizador Info) vendetta.guildsoftware.com
    e entao ?

    qual e' a diferenca entre "eu instalei e vi e gostei ou nao "

    a dizer

    "porque deu isto ACHO que vou instalar porque e' melhor e nao sei mas UM DIA VOU experiementar etc etc"





    Those who do not understand Unix are condemned to reinvent it, poorly.
    -- Henry Spencer
    Re:Implementações do SSH (Pontos:1)
    por moonrider em 24-09-03 14:04 GMT (#15)
    (Utilizador Info) http://127.0.0.1
    Ao fim de uns minutos já tinha uma instalação com as funcionalidades que tinha com o OpenSSH.

    Quando surgiu o OpenSSH, muita gente começou a migrar e os principais motivos não foram a licença, mas o excesso de bugs da versão comercial... Onde quero chegar é que o problema com determinado software não é a existência de bugs, mas se os mesmos são resolvidos, de preferência com rapidez !
    Se aparentemente a versão comercial tem menos bugs, isso é porque já não é tão usada como na "época pré-OpenSSH". Não se esqueçam que o OpenSSH tem uma equipa de programadores que se preocupam com a segurança em primeiro lugar... ou não seja o OpenBSD considerado o S.O. mais seguro...
    Re:Implementações do SSH (Pontos:2)
    por humpback em 24-09-03 9:37 GMT (#3)
    (Utilizador Info) http://www.felisberto.net
    Eu durante muito tempo usei o ssh da ssh.com em sistemas redhat e slackware. Desde que mudei primeiro para a debian e depois para gentoo que andava a usar o openssh, mas esta onda de buracos está a deixar-me algo preocupado.
    Por essas e por outras voltei ao ssh do ssh.com, o problema é que em gentoo ainda não havia ebuild. Por isso deitei mãos a obra e aqui está ela.
    Quem usar gentoo e quiser testar que por favor coloque lá os resultados.
    Neste momento apenas estou a usar em uma máquina mas correu tudo bem.


    Gustavo Felisberto
    72ef1d7183eb2ea89420b94c0cf3e1f1
    apt-get install anarchism

    Re:Implementações do SSH (Pontos:2)
    por Gamito em 24-09-03 9:52 GMT (#4)
    (Utilizador Info) http://www.dte.ua.pt/~gamito
    Eu estou como tu.
    Duante muito tempo usei o ssh.com, depois voltei para openssh, mas já começo a ter dúvidas...

    Mário Gamito
    my web shelter
    Re:Implementações do SSH (Pontos:3, Esclarecedor)
    por Dehumanizer em 24-09-03 10:20 GMT (#5)
    (Utilizador Info) http://www.dehumanizer.com
    Homens de pouca fé. :)

    O OpenSSH não tem tido mais bugs do que a maior parte do software, muito pelo contrário.

    Simplesmente deu-se o azar de haver 3 correcções no espaço de uma semana, o que sem dúvida faz uma pessoa reparar...

    ... mas nenhuma delas é exploitable no default install. Esta do PAM, pelo que li, só afecta quem desligue o PrivSep, o que não vejo qualquer razão para fazer.

    As 2 primeiras correcções não foram algo tipo "temos um buraco no OpenSSH! Há servidores por todo o mundo a ser hackados! Depressa, lancem um fix!". Foram, sim, os próprios autores a corrigir bugs proactivamente. Querem melhor?

    Era bom que em todo o software os bugs fossem descobertos exclusivamente pelos autores do mesmo...


    "It is every citizen's final duty to go into the tanks and become one with all the people."
    - Chairman Sheng-ji Yang, "Ethics for Tomorrow"
    Re:Implementações do SSH (Pontos:4, Interessante)
    por pls em 24-09-03 10:20 GMT (#6)
    (Utilizador Info) http://pls.mrnet.pt
    Estou sem o tempo necessário para te dar uma "boa resposta", pelo que vou ficar pela "posta de pescada não justificada". :-)

    Na minha opinião o OpenSSH é a melhor opção. Já há uns anos que se posicionou como o servidor de ssh mais auditado do mercado.

    Mais importante para se perceber a história de bugs do openssh é observar a natureza desses bugs... não só não são "triviais", como não são propriamente "your average, easy to exploit, buffer overflow". Claro que uma vez "criado" o exploit isso é relativamente igual ao litro, na mão do script kiddie, mas "até isso suceder" a história é muito diferente.

    Há que perceber ainda o impacto que a separação de previlégios tem (separação essa que, da ultima vez que olhei para as alternativas, não estava implementada). Esse impacto é tão simples como ser totalmente irrelevante (bug eventual com impacto limitado) o buffer overflow em quase todos os segmentos de código (muito poucos correm como root até delegar previlégios)...

    Não. O OpenSSH, vital como é, tem pregado umas partidas a todos os sysadmins...mas software é isto mesmo. E cada bug que se descobre é um "a menos", ficamos todos um bocadinho mais seguros do que estavamos. Sempre foi assim, sempre será, pelo menos enquanto novas funcionalidades forem sendo implementadas (e o código a auditar for um alvo em movimento).

    Não é perfeito, mas é a melhor opção que conheço para o efeito desejado...

    PLS


    Re:Implementações do SSH (Pontos:2)
    por Gamito em 24-09-03 11:57 GMT (#8)
    (Utilizador Info) http://www.dte.ua.pt/~gamito
    Pois, acho que estás certo.
    E eu já fiz 3 ./configure && make && make install :-)

    Mário Gamito
    my web shelter
    Re:Implementações do SSH (Pontos:1)
    por sena em 24-09-03 12:14 GMT (#11)
    (Utilizador Info) http://smux.net/
    (separação essa que, da ultima vez que olhei para as alternativas, não estava implementada)

    Penso que o ssh da ssh.com implementa isto...

    Sep 24 10:12:34 [sshd2] User xxxxx, coming from localhost, authenticated.
    Sep 24 10:12:34 [sshd2] Now running on xxxxx's privileges.

    Cumps, João Ribeiro
    --
    sena@smux.net
    http://smux.net/

    Re:Implementações do SSH (Pontos:2)
    por pls em 24-09-03 12:35 GMT (#13)
    (Utilizador Info) http://pls.mrnet.pt
    http://www.citi.umich.edu/u/provos/ssh/privsep.html

    A diferença é entre delegar previlégios no passo final, quando passa o PTY, no caso do ssh.com (pelo menos há uns tempos atrás era assim, não sei como está hoje) e ser feita toda a negociação por um processo sem previlégios (com o parent a fazer o controle).

    Todos os daemons deviam que necessitam de previlégios correr assim (i.e. com um processo sem previlégios E chrooted por trás a executar todo o código possível de correr em separado)...

    PLS
    Re:Implementações do SSH (Pontos:1)
    por apm em 24-09-03 14:21 GMT (#16)
    (Utilizador Info) http://%31%32%37%2E%30%2E%30%2E%31
    O facto de ser o mais auditado não implica que seja o mais seguro, auditar código é uma tarefa bastante complexa, que exige conhecimentos muito acima da média, assim como investimentos a nivel de tempo.
    Além disso a projecção do própio daemon é crucial, o wuftpd é muito mais auditado que o vsftpd, e no entanto isso não o torna mais seguro (mesmo nada).
    Hoje em dia, e em daemons de primeira linha, praticamente nenhum bug é trivial, e além disso acho que ter segurança num sistema, não é so estar protejido contra "script kidies", mas sim também contra os denominados hackers.
    Acho que contra factos não existem argumentos, e portanto o servidor de ssh comercial (www.ssh.com), é definitivamente o mais seguro até ao momento, o openssh para mim so tem a vantagem de ser grátis.
    Re:Implementações do SSH (Pontos:0)
    por tonidosimpostos em 24-09-03 16:46 GMT (#18)
    (Utilizador Info)
    Ja saiu mais um buraco para o wu-ftpd ;)
    Re:Implementações do SSH (Pontos:1)
    por nbk em 24-09-03 17:04 GMT (#19)
    (Utilizador Info) http://www.mrnbk.com/
    Boas.

    Complementando e agarrando numas palavras tuas de à uns thread's atrás, é missão/função do sysadmin estar atento aos novos bugs no software que corre nas máquinas que gere. Se o patch/nova_versão demora algumas horas a chegar, é obrigação do sysadmin pelo menos minimizar os possiveis danos, e ir monitorizando mais atentamente os logs.

    Tudo o resto será *apenas* conversa...

    @754, Nbk

    Re:Implementações do SSH (Pontos:1)
    por lbruno em 24-09-03 10:31 GMT (#7)
    (Utilizador Info) http://republico.estv.ipv.pt/~lbruno/
    O que usar em casa, na universidade e na empresa?
    O mesmo. Precisas do mesmo grau de seguranca em todos eles.
    estou... a considerar implementações alternativas do SSH.
    A unica razao para usar o protocolo SSHv1 e' que a negociacao Diffie-Helman(sp?) do SSHv2 deixa a maquina sentada. Ha' aqui um trade-off entre a tua seguranca e o hardware que tens.

    Posto isto, nao nos esquecamos que estamos a ver estes bugs porque o desenvolvimento e' aberto; uma pesquisa rapida no site do ssh.com nao mostra qualquer advisory.

    Re:Implementações do SSH (Pontos:1)
    por sena em 24-09-03 12:20 GMT (#12)
    (Utilizador Info) http://smux.net/

    O mesmo. Precisas do mesmo grau de seguranca em todos eles.

    Estava também a considerar a licença e a viabilidade comercial.

    Por exemplo, a liceça non-commercial do ssh da ssh.com é bastante permissiva, mas não se aplica em casos de empresas. Já numa universidade ou em casa, este problema não se põe. E depois há também o factor preço... :)

    A unica razao para usar o protocolo SSHv1 [...]

    Eu nunca considerei usar o SSH 1. Isso para mim é impensável. Eu estava a pensar nas implementações disponíveis, não nas versões do protocolo disponíveis.

    Cumps, João Ribeiro


    --
    sena@smux.net
    http://smux.net/
    PAM... (Pontos:2)
    por higuita em 24-09-03 12:04 GMT (#10)
    (Utilizador Info)
    (i.e. afecta apenas a versão "portable" do OpenSSH - ou seja a que corre em todos os sistemas operativos com excepção do OpenBSD)

    a versao portable e' a que corre nos restantes sistemas, mas nao quer dizer que todos estejam vulneraveis...

    pelo menos a slackware nao compila o openssh com suporte para PAM, e logo nao e' vulneravel ao problema (e' impressao minha ou o PAM ainda e' uma fonte consideravel de buracos em varios softwares?)

    aqui teem o email da slackware sobre a actualizacao:


    [slackware-security] New OpenSSH packages (SSA:2003-266-01)

      Upgraded OpenSSH 3.7.1p2 packages are available for Slackware 8.1,
      9.0 and -current. This fixes security problems with PAM
      authentication. It also includes several code cleanups from Solar
      Designer.

      Slackware is not vulnerable to the PAM problem, and it is not
      believed that any of the other code cleanups fix exploitable
      security problems, not nevertheless sites may wish to upgrade.

      These are some of the more interesting entries from OpenSSH's
      ChangeLog so you can be the judge:

                [buffer.c]
                protect against double free; #660; zardoz at users.sf.net
            - markus@cvs.openbsd.org 2003/09/18 08:49:45
                [deattack.c misc.c session.c ssh-agent.c]
                more buffer allocation fixes; from Solar Designer; CAN-2003-0682;
                ok millert@
        - (djm) Bug #676: Fix PAM stack corruption
        - (djm) Fix bad free() in PAM code

    Higuita
    Re:PAM... (Pontos:2)
    por Dehumanizer em 24-09-03 15:25 GMT (#17)
    (Utilizador Info) http://www.dehumanizer.com
    "not nevertheless"???


    "It is every citizen's final duty to go into the tanks and become one with all the people."
    - Chairman Sheng-ji Yang, "Ethics for Tomorrow"
    Re:PAM... (Pontos:2)
    por higuita em 25-09-03 11:12 GMT (#20)
    (Utilizador Info)
    8)

    nao sao so' os portugueses que falam mal a sua lingua, os americanos pelos vistos tambem se enganam ;)

    Higuita

     

     

    [ Topo | FAQ | Editores | Contacto ]