Falha corrigida no Bugzilla

No final de Setembro, investigadores da Check Point Software Technologies detectaram uma falha no Bugzilla, um sistema usado por programadores para registar e acompanhar bugs.

Este bug permitiria que utilizadores não autorizados tivessem conhecimento de falhas não corrigidas em grandes projectos de software.

Na segunda-feira (06-Outubro) a Mozilla Foundation disponibilizou um patch (para correcção preliminar do problema) com os principais utilizadores do Bugzilla. Desconhece-se se algum hacker terá explorado esta falha.

---------------------------------------
Fonte (em inglês): Critical Bugzilla vulnerability could give hackers access to undisclosed software flaws

Nova falha de segurança massiva deixa boa parte da Internet sujeita a ataques

Está a ser apelidado de Bash Bug e de Shellshock. Especialistas em segurança informática dizem que é uma falha de segurança mais grave do que o Heartbleed. Tanto os sistemas operativos Linux como o Mac OS estão vulneráveis.

A Internet acordou hoje, 25 de setembro, outra vez em sobressalto: depois da grande falha de segurança Heartbleed, surgem provas e relatos de que existe outro bug de grande escala que afeta os sistemas operativos baseados em Linux, bem como o Mac OS da Apple.

No caso das distribuições Linux a preocupação é ainda maior visto que são usadas como sistema operativo de muitos servidores de Internet – quer isto dizer que qualquer dispositivo ligado à grande rede está sujeito a ser explorado por piratas informáticos.

Em causa está uma parte dos sistemas operativos que é conhecida como interpretadora de comandos – que faz uma tradução dos comandos entre o software e os utilizadores. Esta shell é ativada sempre que é necessário despoletar uma ação como um script de um navegador de Internet. No caso do Linux muitos dos comandos são escritos pelos próprios utilizadores para executar determinadas ações, o que aumenta ainda mais a probabilidade de ataque.

Explica a imprensa internacional, como o ZDNet, que a falha descoberta no Bash – nome da shell que é usada nas distribuições Linux e que também marca presença no Unix, que é a base do Mac OS -, faz com que um cracker possa executar vários comandos nos equipamentos dos utilizadores.

Um porta-voz da empresa de segurança Rapid7 explicou à Reuters o alarmismo da situação: atinge o nível 10, o máximo, ao nível da gravidade, e ao nível da facilidade de exploração por um pirata informático é muito fácil.

Várias equipas de segurança responsáveis por distribuições Linux – como a CentOS, Debian, RedHat – já lançaram atualizações para corrigir o problema, mas existe a possibilidade de que nos próximos meses muitas máquinas venham a ficar desprotegidas.

À semelhança do que aconteceu com o Heartbleed e depois de todos os avisos, mais de 300 mil servidores continuavam desprotegidos ao fim de dois meses da descoberta da vulnerabilidade. Três meses depois, em julho, apenas 3% dos servidores de grandes empresas mundiais estavam totalmente protegidas contra a falha de segurança.

------------------------------------
FONTE: Nova falha de segurança massiva deixa boa parte da Internet sujeita a ataques (tek.sapo.pt)

Satélites europeus em órbita errada devido a erro de software

Dois satélites encomendados pela União Europeia foram acidentalmente colocados numa órbita errada após o lançamento, devido a um erro de software, tornando-se potencialmente inúteis.

O foguetão Soyuz que transportava os dois satélites

Estes dois satélites (Doresa e Milena) fazem parte do projecto Galileo que foi desenvolvido pela União Europeia com o objectivo de criar uma alternativa aos sistemas de posicionamento por satélite GPS (dos EUA) e GLONASS (da Rússia), no caso de esses países impedirem o acesso a esses sistemas devido a divergências políticas.

O sistema Galileo terá um custo superior a 5,5 mil milhões de Euros e permitirá uma precisão dez vezes superior ao sinal de GPS civil disponível na Europa. Quando estiver concluído (em 2019) será formado por 30 satélites que orbitarão a Terra a uma distância de cerca de 23.333 km. (recorde-se que Estação Espacial Internacional encontra-se a 420 km da Terra)

Os primeiros satélites foram lançados em 2011 e, no passado dia 22 de Agosto, os satélites número cinco e seis foram lançados para o espaço a partir da Guiana Francesa. Mas rapidamente ficou claro que não conseguiram alcançar a órbita correta. Os satélites deveriam seguir uma órbita circular, mas o foguetão Soyuz que os lançou colocou-os numa órbita elíptica em torno do nosso planeta.

Entretanto, o jornal russo Izvestia afirmou que um erro de software no andar superior do foguetão - que foi desenvolvido por uma empresa propriedade do governo russo - foi a causa provável. Uma fonte anónima da agência espacial russa Roscosmos disse ao jornal que um erro numa componente de software forneceu instruções de voo incorrectas para o andar superior do foguetão, lançando os satélites para um destino errado.

Segundo a Agência Espacial Europeia (ESA), apesar de estarem numa órbita errada, os satélites estão a funcionar normalmente e encontram-se sob controlo do Centro de Operações da ESA em Darmstadt, Alemanha.

A ESA está a investigar a possibilidade de recuperação parcial ou integral destes satélites para o fim previsto. Recorde-se que estes aparelhos possuem uma capacidade de propulsão limitada, sendo possível que não tenham energia ou combustível suficiente para serem colocados na órbitra correcta.

-----------------------------------------------------

FONTE: EU satellites fired intowrong orbit by 'software bug' (The Telegraph)

Becoming a Software Testing Expert

Um bug de software que viajou até Marte

Um bug potencialmente perigoso foi encontrado numa componente de software com 20 anos de idade e considerada tão eficaz que tem sido usado em smartphones, automóveis, aviões e no veículo que viajou até ao planeta Marte, a Mars Rover Curiosity.

Em 1994, Markus Oberhumer criou um algoritmo de compressão de dados (Lempel-Ziv-Oberhumer, LZO) que se mostrou tão rápido a descomprimir informações que passou a ser usado em todo o mundo. Para isto contribuiu o facto de Oberhumer ter publicado o software com licença Open Source.

Na semana passada, Oberhumer lançou a versão 2.07 da LZO, e avisou que as versões anteriores eram passíveis de buffer overrun. Isto significa que é possível criar um conjunto de dados comprimidos que executaria um pedaço de código malicioso quando o software tentasse descompactá-lo.

A falha só se manifesta em circunstâncias muito específicas, levando Oberhumer a sugerir que as "implicações práticas são limitadas". Mas a natureza do código e a popularidade do software levam a crer que a correcção do problema em todo o mundo será um enorme esforço.

-------------------------------------------------------
Notícia completa em inglês: Software bug found on Mars Curiosity rover

10 Regras Básicas sobre Automatização de Testes

Testar software é uma tarefa difícil e automatizar testes de software é o sonho de todos os testers, analistas e programadores. No entanto, a automatização é um processo que tem de ser bem compreendido, que exige muita prática, e no qual devemos seguir alguns conceitos básicos. Vamos descrever alguns desses conceitos básicos e mostrar que a automatização pode ser fácil se for feita correctamente.

Regra 1: Ler e aprender conceitos básicos

Os programadores mais qualificados necessitam de rever os seus conhecimentos ao longo do tempo; aprender é uma necessidade. A automatização não é mais que que uma mera avaliação dos passos a executar por um programa, escrevendo instruções detalhadas.

Regra 2: Estar preparado para enfrentar a automatização no projecto

A prática é a única forma de obter conhecimento válido. Seleccione uma qualquer ferramenta de testes open source disponível, instale-a e aprenda a usá-la no seu tempo livre. Qualquer uma serve. O importante é praticar, compreender e ganhar experiência para estar pronto para enfrentar um projecto real quando for necessário.

Regra 3: Os conceitos básicos são os mesmos, basta explorá-los

Além das diferentes particularidades, todas as linguagens de programação funcionam basicamente com os mesmos conceitos como variáveis, parâmetros, funções, diferentes tipos de dados, ciclos, declarações condicionais, arrays, etc. Depois de os compreender e recordar, qualquer pessoa deve ser capaz de aplicar esse conhecimento em qualquer linguagem de programação. Reserve algum tempo, cerca de duas semanas, para compreender as bases da programação.

Regra 4: Não desistir quando o primeiro programa falhar

Os russos têm um provérbio maravilhoso: a primeira panqueca é uma confusão. Isso significa que é muito provável que a primeira tentativa de qualquer coisa irá falhar, mas todas as seguintes terão melhor resultado, e com isso podemos ganhar experiência no processo. Não importa o quanto sabemos da teoria; provavelmente, a primeira execução prática será decepcionante. Por isso, temos que continuar.

Regra 5: Olhar para o código como um processo, não como magia

Sempre que um principiante olha para o código, este parece incrivelmente complexo. No entanto, depois de produzir algum código eficaz, conseguiremos reconhecer os padrões e procedimentos, tornando a leitura do código muito mais fácil. Depois podemos ver as instruções do programa, claras como água, e perceber a sua lógica.

Regra 6: Explorar a ferramenta

A melhor maneira de conhecer uma ferramenta é explorar as suas funcionalidades uma a uma. De forma sistemática, devemos seleccionar cada uma das opções e subopções de menu e inspeccionar as respectivas funcionalidades. Se existir uma barra com botões, estes devem conter as funcionalidades mais comuns. A maioria dos itens costuma ter nomes auto-explicativos.

Regra 7: Procurar Ajuda

Sempre que nos sentimos num impasse devemos procurar algum texto explicativo na secção de ajuda. Geralmente esta contém boas explicações e instruções sobre cada funcionalidade da ferramenta. Leia-a atentamente para conseguir dominar a ferramenta.

Regra 8: Praticar muito

Devemos encarar os testes de software com um processo de validação. Isto permite concluir se o código é funcional ou não. Os testes automatizados devem permitir concluir a mesma coisa, e apresentando resultados claros (sim/não; o teste passou ou falhou) em vez de resultados em bruto que necessitam de interpretação.

Regra 9: Melhorar o nosso Trabalho

Todas as coisas bem-feitas podem ser feitas ainda melhor. Investir na revisão e melhoramento dos nossos projectos é um caminho para melhorar as nossas competências e levar-nos a novos desafios.

Regra 10: Automatização nem sempre é necessária

Apesar de ser muito útil, a automatização não é nada mais do que um instrumento de testes. Nem sempre os projectos necessitam de automatizar os seus testes. Devemos escolher a melhor forma de testar (manual ou automático) de acordo com as necessidades de cada projecto.

Conclusão:

Essas regras não são obrigatórias, mas são simples e óbvias. Seguindo-as podemos melhorar as nossas competências e evoluir como testers.

-----------------------------------------------------
Traduzido e adaptado de: 10 Basic Rules For Beginners In Automation Testing

GTAC 2011: Opening Keynote Address - Test is Dead