Queijo Suíço em 2000: sabor Windows ?
Há alguns anos a comunidade open-source acostumou a se referir ao IIS (Internet Information Services, o servidor de páginas web que vêm incluído nas versões Server do Windows) como um "queijo suíço" devido a dezenas de bugs descobertos no IIS 4 do Windows NT Server 4 e do IIS 5 do Windows Server 2000.
Eles também exaltavam a todos a segurança do Apache (servidor web de código aberto) e ironizavam a segurança do IIS mesmo desconsiderando o fato da Microsoft sempre ter disponibilizado patches para as vulnerabilidades do IIS antes de exploits (programas que exploram falhas) aparecerem na web - o que na prática fazia com que os servidores Windows que estivessem atualizados estivessem imunes a problemas dessa natureza...
Ao desenvolver o Windows Server 2003, a Microsoft decidiu reescrever o IIS praticamente "do zero", dando uma atenção especial à segurança. Com isso, além das diversas novidades e melhoria visível de performance em relação às suas versões anteriores, o IIS 6.0 tornou-se um servidor web extremamente confiável e seguro - e os resultaram não tardaram a aparecer ...
Queijo Suíço em 2004: sabor Apache !
Atualmente a situação se inverteu de tal maneira que a versão mais recente do Apache tornou-se um "queijo suíço" quando comparado com o IIS 6.0: enquanto o Apache 2.0 (versão mais recente) tem quase 30 vulnerabilidades reportadas, o IIS 6.0 não tem nenhuma vulnerabilidade (ou, segundo o site Secunia, apenas 3 bugs que são comentadas mais abaixo). Isso torna-o um recordista em segurança pois ele foi lançado há mais de um ano e meio (24/Abril/03), mostrando a correta decisão da Microsoft em desenvolvê-lo de maneira segura.
Enquanto muitos tentam provar a maior qualidade de um aplicativo de código aberto, o Apache mostra exatamente o contrário, aonde um de seus builds mais recentes (2.0.51) não durou sequer uma semana antes de encontrarem uma vulnerabilidade crítica de segurança nele - sendo que a versão que corrige este bug (a versão 2.0.52) também já apresentou duas vulnerabilidades críticas relativas ao SSL e a DoS. Enquanto isso, o IIS 6 continua sem necessidade de correções 19 meses após o seu lançamento ...
Vulnerabilidades do Apache 2.0
A lista abaixo foi obtida no site ApacheWeek e inclui as vulnerabilidades relatadas até o momento (19/11/04) na versão 2.0:
1. Memory consumption DoS CAN-2004-0942
2. SSLCipherSuite bypass CAN-2004-0885
3. Basic authentication bypass CAN-2004-0811
4. IPv6 URI parsing can cause crash CAN-2004-0786
5. Environment variable expansion flaw CAN-2004-0747
6. Malicious SSL proxy can cause crash CAN-2004-0751
7. WebDAV remote crash CAN-2004-0809
8. Header parsing memory leak CAN-2004-0493
9. FakeBasicAuth overflow CAN-2004-0488
10. listening socket starvation CAN-2004-0174
11. mod_ssl memory leak CVE-2004-0113
12. Error log escape filtering CVE-2003-0020
13. CGI output information leak CAN-2003-0789
14. Local configuration regular expression overflow CAN-2003-0542
15. Remote DoS via IPv6 CAN-2003-0254
16. Remote DoS with multiple Listen directives CAN-2003-0253
17. mod_ssl renegotiation issue CAN-2003-0192
18. APR remote crash CAN-2003-0245
19. Basic Authentication DoS CAN-2003-0189
20. OS2 device name DoS CAN-2003-0134
21. Filtered escape sequences CAN-2003-0083
22. Line feed memory leak DoS CAN-2003-0132
23. MSDOS device names cause DoS CVE-2003-0016
24. Apache can serve unexpected files CVE-2003-0017
25. Error page XSS using wildcard DNS CVE-2002-0840
26. CGI scripts source revealed using WebDAV CVE-2002-1156
27. Apache 2.0 path vulnerability CAN-2002-0661
28. Path revealing exposures CAN-2002-0654
29. Apache Chunked encoding vulnerability CVE-2002-0392
Vulnerabilidades do Apache 1.3
Para muitos que defendem que a antiga versão 1.3 não tem bugs ou tem poucos bugs em relação à versão 2.0, a lista abaixo mostra que não é bem assim:
1. moderate: mod_include overflow CAN-2004-0940
2. mod_proxy buffer overflow CAN-2004-0492
3. Error log escape filtering CVE-2003-0020
4. mod_digest nonce checking CAN-2003-0987
5. listening socket starvation CAN-2004-0174
6. Allow/Deny parsing on big-endian 64-bit platforms CVE-2003-0993
7. Local configuration regular expression overflow CAN-2003-0542
8 RotateLogs DoS CAN-2003-0460
9. Buffer overflows in ab utility CAN-2002-0843
10. Shared memory permissions lead to local privilege escalation CAN-2002-0839
11. Error page XSS using wildcard DNS CVE-2002-0840
12. Apache Chunked encoding vulnerability CVE-2002-0392
13. Filtered escape sequences CAN-2003-0083
14. Win32 Apache Remote command execution CVE-2002-0061
15. Requests can cause directory listing to be displayed CAN-2001-0729
16. split-logfile can cause arbitrary log files to be written to CVE-2001-0730
17. Multiviews can cause a directory listing to be displayed CVE-2001-0731
18. Denial of service attack on Win32 and OS2 CVE-2001-1342
19. Requests can cause directory listing to be displayed CAN-2001-0925
20. Rewrite rules that include references allow access to any file CVE-2000-0913
21. Mass virtual hosting can display CGI source CAN-2000-1204
22. Requests can cause directory listing to be displayed on NT CVE-2000-0505
23. Cross-site scripting can reveal private session information CAN-2000-1205
24. Mass virtual hosting security issue CAN-2000-1206
25. Denial of service attack on Win32
26. Multiple header Denial of Service vulnerability CVE-1999-1199
27. Denial of service attacks
Vulnerabilidades do IIS 6: três ou zero ? ZERO !
Embora a maioria dos sites de segurança não mostrem até o momento nenhuma vulnerabilidade específica do IIS 6, estranhamente o site Secunia informa que há três bugs do mesmo. São eles:
1. moderate: mod_include overflow CAN-2004-0940
2. mod_proxy buffer overflow CAN-2004-0492
3. Error log escape filtering CVE-2003-0020
Eu fiquei bastante curioso em conhecer os detalhes dessas "vulnerabilidades" pois eu trabalho com o IIS 6, conheço-o razoavelmente bem e mantenho-me informado sobre eventuais problemas dele.
Com isso, eu analisei detalhadamente cada uma delas e o resultado foi surpreendente: duas vulnerabilidades não são relativas ao IIS 6 em si: são dois componentes externos que podem ser instalados ou não no IIS 6 - e uma "vulnerabilidade" é apenas uma configuração errada do IIS 6 que pode ser modificada (e portanto "corrigida") em segundos com alguns cliques !
Analisando detalhadamente as "vulnerabilidades":
Microsoft IIS Inappropriate Cookie Handling Error
Quando a aplicação web apresenta um erro, por default o IIS 5 e IIS 6 mostram o nome do arquivo que gerou o erro - e o autor considera isso como uma vulnerabilidade !. Além não fazer muito sentido considerar isso uma "vulnerabilidade", o IIS pode ser configurado para não mostrar nada caso o administrador assim o quiser, bastando acessar a tab Custom Errors nas propriedades do IIS 6. Essa "vulnerabilidade" é apenas uma questão de configuração do IIS detalhada pela Microsoft em http://support.microsoft.com/?id=834452 ...
Microsoft Windows Server 2003 / IIS 6 Cross Site Scripting
A vulnerabilidade está detalhada aqui: é um bug do Remote Administration Tool (RAT), uma ferramenta externa de administração remota do IIS 6 que não tem relação alguma com o funcionamento do IIS 6. O RAT é instalada pelo Windows Server 2003 somente se o administrador quiser monitorar o IIS6 via web, não sendo um problema relativo ao IIS 6 em si. Curiosamente o RAT - que para funcionar exige o uso de SSL e acesso à porta 9098 - nem é instalado por default nas versões Windows Server 2003 Standard Edition, Enterprise Edition e Datacenter Edition, o que torna essas versões imunes a essa "vulnerabilidade" ...
Microsoft Windows WebDAV XML Message Handler Denial of Service
Essa vulnerabilidade não é do IIS 6, mas (como informa o próprio título) do componente WebDAV relativo ao uso de XML. Quem utiliza o IIS sem WebDAV não está sujeito a essa "vulnerabilidade" ....
Após chegar à conclusão que nenhuma vulnerabilidade afeta o próprio IIS 6, eu contatei o site Secunia e pedi explicações sobre o fato das vulnerabilidades acima serem relatadas como sendo do IIS 6, algo que não condiz com a realidade.
A resposta deles veio através de um e-mail de Carsten H. Eiram, um de seus especialistas de segurança, e foi bastante esclarecedora: "We have chosen to add IIS as "affected", since the issue only is of interest to (some) people using IIS", ou seja, eles incluíram as vulnerabilidades como sendo do IIS pois as informações das mesmas interessam apenas às pessoas que usam o IIS - o que é verdade.
A conclusão final de tudo isso é bastante simples: até o momento não há nenhuma vulnerabilidade do IIS 6.0 relativa especificamente a ele !
Cada advisorie do Secunia pode conter mais de uma vulnerabilidade
Ideologia x mundo real
Como mostrado acima, o Apache, uma das referências no mundo open-source, mostra claramente que o fato de um aplicativo ter o seu código aberto não significa que ele tenha maior segurança e muito menos que a qualidade do código aberto seja superior ao do código fechado (proprietário).
O uso desses argumentos apenas para defender uma ideologia pode custar caro. Em 2002, quando foi descoberta uma vulnerabilidade no OpenSSL utilizado pelo Apache, 75% dos servidores continuavam vulneráveis mais de dois meses após a publicação da correção, sendo uma indicação que seus administradores acreditavam (erroneamente) que o fato de utilizarem o Apache deixava-os seguros e com isso não precisavam se preocupar.
Outros exemplos incluem o site do Kremlin, que antes de ser lançado se auto-intitulava "à prova de hackers", mas estava vulnerável por usar uma versão do Apache com vulnerabilidades, a invasão de 13 sites da NASA em 2003, a invasão do site que controla os domínios .name na web que foi invadido através de um exploit do Apache e até mesmo o próprio site da Apache.org, que foi invadido em 2001 !
Acreditar que o uso do Apache dará mais segurança ao servidor é pura ilusão.
Os números mágicos da Netcraft
Um dos assuntos mais citados quando o assunto é Apache x IIS é a estatística da Netcraft mostrando que sites sob Apache representam cerca de dois terços dos sites publicados na web.
Isso ocorre pois a maioria dos sites da web funcionam com sites virtuais, isto é, centenas de sites diferentes ficam hospedados em um único computador, funcionando sob uma única instalação do Apache. Isso é bastante comum na web e há anos as empresas de hospedagem de sites usam o Apache para este cenário, sendo que a Microsoft só começou a investir seriamente nesse nicho em 2003, com o lançamento do Windows Server 2003 Web Edition.
É preciso entender o resultado da Netcraft: como as estatísticas mostram o número de sites - e não o número de servidores web (computadores) - o resultado mostrado não indica o número de instalações de Apache e IIS, mas apenas a quantidade de sites hospedados. Com isso há a falsa impressão de haver muito mais servidores com Apache do que com IIS (Windows).
Um exemplo simples que mostra essa distorção: para a Netcraft, um servidor com uma única cópia do Apache instalado e que esteja hospedando 1000 sites conta mais do que 5 servidores com IIS que estejam hospedando 100 sites cada um. Neste caso, o gráfico da Netcraft contaria 1000 "instalações de Apache" e apenas 500 do IIS, quando na realidade há apenas uma instalação do Apache e cinco do IIS ...
Outro exemplo que se aplica a um único servidor: se um servidor com Apache estiver hospedando 1000 sites e um servidor IIS estiver hospedando 500 sites, a Netcraft contabilizará o dobro de instalações de Apache (1000) em relação ao número de instalações do IIS (500), quando na prática o número é o mesmo: uma única instalação para ambos.
A conclusão é que o gráfico da Netcraft não conclui absolutamente nada sobre o número de instalações do Apache e do IIS, mostrando apenas o número de sites hospedados em ambos. Em relação ao número de servidores web, em 2001 a própria Netcraft publicou que havia muito mais servidores Windows (49,2%) do que Linux (28,5%) e em 2003 a IDC publicou que servidores Windows continuam a dominar largamente o mercado.
Nas empresas, por outro lado, as estatísticas são mais claras: dentre as 1000 maiores empresas dos EUA, 53,8% delas utilizam IIS e apenas 21,2% utilizam Apache (independentemente do número de sites hospedados), mostrando a confiança das corporações no uso do IIS.
Conclusão
Eu acredito que isso ponha um fim às eternas discussões sobre segurança e uso do Apache e IIS, aonde quem defende que o IIS é um "queijo suíço" apenas mostra que parou no tempo e está totalmente desinformado sobre o assunto.
Os fatos acima comprovam que uma das mais tradicionais retóricas dos defensores do código livre não tem fundamento algum: a de que um produto com código aberto indique que ele seja mais seguro, melhor ou que tenha menos bugs e vulnerabilidades do que um produto com código fechado (da Microsoft ou não). O Apache, um dos produtos mais conhecidos e utilizados atualmente - e que serve de ícone para muitos defensores do código aberto -, mostra exatamente o contrário ;) ...
Até a próxima !
Baboo.
www.baboo.com.br
20/11/04
Update 23/11/04: há uma discussão no Fórum do BABOO sobre este artigo
