Re: Ajuda - woody, php bugs, etc
rodrigo@iq.unesp.br wrote:
Oi pessoal,
Preciso de uma ajuda, todos os nossos servidores rodando Debian e tudo
instalado via apt-get, so que agora temos um problema em relacao ao php4
instalado aqui.Eh que uma empresa esta dizendo que esta versao esta cheia de bugs, com
poucas funcionalidades, abaixo o texto que a pessoa nos enviou.
Se vc usa apenas repositórios stable (o woody) e realiza as atualizações
periodicamente (pelo menos uma vez por semana), pode ficar tranquilo.
Falando em termos dos programas, eles estarão devidamente consertados e sem
bugs de segurança que já foram descobertos e corrigidos.
Veja detalhes em:
http://packages.debian.org/stable/web/php4
http://packages.debian.org/changelogs/pool/main/p/php4/php4_4.1.2-7/changelog
"A versão do PHP instalada no servidor de vocês, a 4.1.2, é uma versão com
um histórico de bugs (erros de código) e vulnerabilidade muito extensa.
Veja o que eu disse acima: se voce fez o dever de casa (apt-get update &&
apt-get -u upgrade da base stable), já está tudo corrigido. Tudo através do
famoso 'backport'. Veja algumas referencias boas:
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?backport
http://www.redhat.com/advice/speaks_backport.html
Confira no changelog
Publicados pela própria empresa que desenvolve o PHP, a Zend
Technologies (http://www.zend.com)
O PHP 4.1.2 foi lançado em maio de 2002, utilizando o Zend Engine 1.1.1
(o qual atualmente está no 2.0). E essa versão do Zend Engine, além de
ser lenta, contém muitos erros estruturais documentados.
Isso pode até ser verdade (e realmente deve ser), mas nenhum deles é
relacionado a acesso com permissões indevidas e problemas de segurança
(exceto se a intenção do programador original foi essa mesmo). Mas até ai
ele é apenas um software com bugs, como outro qualquer.
Esta versão do PHP permite que alguma pessoa mal intencionada provoque
até mesmo um desligamento inesperado do servidor. As vulnerabilidades
presentes em versões antigas do PHP são muito críticas.
Aqui o autor não considera o tal do 'backport', que é seguido rigorosamente
pelo security.debian.org para o debian stable. Considerando que voce fez sua
parte do trabalho, eu diria que ou é uma ignorância tremenda do autor desse
texto ou então ele está pondo vc a prova :-) pois muitas distros(a maioria
eu acho) usam esse mesmo método.
Uma das vulnerabilidades presentes no PHP, que foi corrigida nas versões
acima de 4.3.x é a seguinte:
Um usuário mal intencionado pode realizar o upload de um código
infeccioso, como um exploit para linux.
Este código vai ser enviado normalmente para o servidor...
E quando o php fosse acessar o arquivo, o mesmo pode acessar todo o
sistema do servidor, enviando informações importantes para fora do
servidor, ou até mesmo criando uma conta de acesso root para o usuário.
Bom, isso não está bem explicado: enviar como? HTTP POST? ou via ssh/scp? Tá
meio furado esse texto
Não que eu duvide dessa vulnerabilidade - mas nao quero confundir com
problema de configuração do servidor.
Será que elá está listada no CERT e/ou CVE?
http://www.cert.org/advisories/
http://cve.mitre.org/
Nas versões mais atuais do sistema isso foi corrigido simplesmente
isolando o processo dos arquivos abertos pelo php do sistema. Assim se o
usuário enviar um código infeccioso ele não terá acesso ao resto do
sistema, apenas ao PHP, em uma espécie de Jail Root.
Talvez fazendo o php rodar com o UID do apache?
Como eu já disse, isso deve ser verdade mesmo - mas até que ponto isso foi
um erro na configuração do sistema e não um problema do php?
Eu poderia citar muitas outras vulnerabilidades presentes na versão que
está instalada no servidor da unesp, mas isto não vem ao caso neste
momento.
Por acaso ele chegou a testar algumas dessas vulnerabilidades? :-)
(isso é meio arriscado de perguntar, ainda mais se o cara for nervoso hehehehe)
Outra informação que não procede, é o fato de utilizar o apt-get para se
instalar uma versão "estável" do PHP.
O apt-get instala uma versão pré-compilada como um arquivo ".exe" no
windows.
apt-get: nao procede <-> 'estável' ?? O camarada viajou...
Além disso, ele interpretou ao pé da letra o nome 'estável', o que não é
verdade.
A qual é compilada para funcionar em todos os sistemas linux,
independente da plataforma, sistema, e isso causa certa lentidão no
aplicativo (não apenas para o PHP).
Viajou completo: o arquivo binario de um PowerPC é diferente de um pra Sparc
que é diferente de um i386 que é diferente de .....
O que o cara provavelmente quis dizer é que um programa compilado pra 386
vai rodar mais lentamente num P4 do que um compilado especificamente pra P4.
Isso é verdade, e de certo modo, fato (incontestável).
Utilizando uma distribuição em código fonte, e compilando no próprio
sistema em que ele vai funcionar, proporciona uma otimização do código
para a máquina em si. O que o torna até 300% mais rápido e eficaz.
Essa é a parte contestável: 300%?! Papo de vendedor.
Compilar o kernel, glibc e alguns outros programas bem 'core' do sistema
realmente fazem diferenca sim (pois eles representam uma parcela bastante
grande do tempo de execucao na CPU). Já o ganho obtido com outros programas
não é necessariamente tão grande assim...
Além disso, voce tem que contar o tempo de compilação do aplicativo... o que
nem sempre torna a coisa viável (pra citar alguns exemplos do meu Athlon
1GHz: compilar mozilla=2h30, XFree=2h, windowmaker=30min, KDE=? talvez umas
10 ou 15h). Isso vai ter que ser feito no momento da instalação e para cada
correção que surgir.
A
única dificuldade em utilizar este tipo de distribuição, é a
complexidade que envolve. Pois exige um conhecimento mais profundo de
sistemas Posix, e conhecimento das bibliotecas dependentes dos próprios
aplicativos que são instalados.
De novo, papo de vendedor. Nada que um 'apt-get build-dep && apt-get source
-b' nao resolvam. (só não sei dizer como o debian se comporta pra compilar
esses pacotes 'core' do sistema, como libc6, etc)
É lógico que se ocorrer algum problema, esse 'conhecimento mais profundo'
pode ajudar :-)
Mas isso não significa que o sistema
ficaria desatualizado, muito pelo contrário, o sistema ficaria
otimizado, com uma velocidade muito maior, e com um controle mais
profundo sobre todas as bibliotecas instaladas no sistema.
"
O cara comecou com um argumento e depois fugiu dele. Não falou que a cada
atualização voce vai ter q recompilar tudo. Tirando esse 'pequeno detalhe',
isso é verdade, mas a que custo? Isso é o que deve ser pesado.
Aposto que esse cara ama e quer que voce instale um Gentoo ou um BSD da
vida. Eles fazem exatamente isso: oferecem binários pré-compilados, mas o
forte deles é disponibilizar o source code para que voce mesmo possa
compilá-los, utilizando as otimizacoes que achar importantes (-O3
march=athlon etc).
Um comentário a parte: Vi uma vez que num congresso, de dois dias, ia
ocorrer uma pelestra sobre o Gentoo. Uma das observacoes era algo como: "Nós
faremos os primeiros passos da instalação 'live', mas não será possivel
instalar o sistema completo pois o congresso é de _apenas_ dois dias" :-)
Imagina se vc só tem uma máquina e vc fala pra seus usuários que o servico
está fora do ar pq ainda tá compilando e vai demorar nao-sei-qtos-dias
ainda... :-)
Eu estou errado em instalar via apt?
Este pacote tem estes bugs mesmos?
A minha recomendação é vc estudar bastante o debian antes (pra ter base pra
responder aos questionamentos que possam surgir), e ai perguntar pro autor
se ele detectou alguma vulnerabilidade que ainda nao foi corrigida, e se ele
precisa de uma versão mais nova do PHP e não quis dizer.
Se vc estiver a fim de seguir o conselho de compilar tudo, ótimo - Veja tbm
qual a distro que o cara 'adora' :-) Mas faca isso numa máquina em separado,
e com bastante HD (só pra compilar o XFree eram necessários quase 2Gb
livres). Vc vai precisar de bastante tempo até conseguir acertar tudo.
Experiencia própria.
Eu pessoalmente sempre compilo o kernel da máquina (vale a pena), mas hj em
dia existem diversas kernel-images-2.x-<arch> - ai fico na dúvida se vale a
pena os 30min extras que tenho que esperar só de compilação... (isso se eu
acertar de primeira, pois sempre fica faltando alguma coisa)
Espero que tenha ajudado e nao complicado :-)
Obrigado
Rodrigo
--
Marcos Lazarini
Reply to:
- References:
- Ajuda
- From: <rodrigo@iq.unesp.br>