Programação Segura

237 visualizações

Publicada em

Palestra introdutória sobre programação segura apresentada na Co0L BSidesSP edição #naovaitercopa.

Breve mostra de acidentes causados por falhas de programação

Publicada em: Engenharia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
237
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
1
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Programação Segura

  1. 1. Programação Segura Rafael de Moura Moreira
  2. 2. Programação Segura - Introdução  Como cada um vê o trecho de código abaixo?
  3. 3. Programação Segura - Introdução  Como cada um vê o trecho de código abaixo?
  4. 4. Programação Segura - Introdução  Como cada um vê o trecho de código abaixo?  Aluno padrão de computação: “Tá certinho, uai!”
  5. 5. Programação Segura - Introdução  Como cada um vê o trecho de código abaixo?  Aluno espertinho: “Se o professor não digitar m**** pra sacanear, não dá pau...Ah, ele não vai digitar.”
  6. 6. Programação Segura - Introdução  Como cada um vê o trecho de código abaixo?  CDF chato: “FESSOR! Ô FESSOOOOOR! E se eu fizesse um loop pra ler letra por letra e desse malloc() pra criar um vetor do tamanho certinho da string? ...”
  7. 7. Programação Segura - Introdução  Como cada um vê o trecho de código abaixo?  CDF chato: “FESSOR! Ô FESSOOOOOR! E se eu fizesse um loop pra ler letra por letra e desse malloc() pra criar um vetor do tamanho certinho da string? Isso vale ponto extra na prova?”
  8. 8. Programação Segura - Introdução  Como cada um vê o trecho de código abaixo?  CDF chato: “FESSOR! Ô FESSOOOOOR! E se eu fizesse um loop pra ler letra por letra e desse malloc() pra criar um vetor do tamanho certinho da string? Isso vale ponto extra na prova?”
  9. 9. Programação Segura - Introdução  Como cada um vê o trecho de código abaixo?  Professor de algoritmos: “Eles aprenderam I/O direitinho, vamos tocar a matéria.”
  10. 10. Programação Segura - Introdução  Como cada um vê o trecho de código abaixo?  Desenvolvedor de embarcados: “Com essa porcariazinha de 8 bits e 4k de memória, verificação de segurança é um luxo que não temos.”
  11. 11. Programação Segura - Introdução  Como cada um vê o trecho de código abaixo?  Chefe do desenvolvedor: “O orçamento tá curto e o prazo tá apertado, se funciona, vai assim mesmo!”
  12. 12. Programação Segura - Introdução  Como cada um vê o trecho de código abaixo?  Usuário: “João Henrique de Mello da Silva Santos”
  13. 13. Programação Segura - Introdução  Como cada um vê o trecho de código abaixo?  Usuário: “João Henrique de Mello da Silva Santos... Que que eu fiz???”
  14. 14. Programação Segura - Introdução  Como cada um vê o trecho de código abaixo?  Usuário: “João Henrique de Mello da Silva Santos... Que que eu fiz???”
  15. 15. Programação Segura - Introdução  Como cada um vê o trecho de código abaixo?  Invasor: “Opa, aí sim!”
  16. 16. Programação Segura - Introdução  Ao digitar uma string muito longa, o invasor pode sobrescrever outras regiões da memória.  Isso permite alterar variáveis, inserir códigos maliciosos, desviar a execução para outro código...  Para evitar isso, deve-se sempre conferir o tamanho de uma entrada e ver se ela respeita o tamanho do vetor.
  17. 17. Programação Segura – Falhas famosas  Aceleração Involuntária doToyota Camry (2005)
  18. 18. Programação Segura – Falhas famosas  Aceleração Involuntária doToyota Camry (2005)  Carro acelerou involuntariamente, causando a morte de uma passageira.  Análise do firmware encontrou bugs diversos, alguns causados por stack overflow e não uso de mirroring em dados importantes. http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences
  19. 19. Programação Segura – Falhas famosas  Aceleração Involuntária doToyota Camry (2005)  Carro acelerou involuntariamente, causando a morte de uma passageira.  Análise do firmware encontrou bugs diversos, alguns causados por stack overflow e não uso de mirroring em dados importantes. http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences  Empresa foi condenada a pagar US$1,2 bilhão.
  20. 20. Programação Segura – Falhas famosas  Ariane 5 Flight 501(1996)
  21. 21. Programação Segura – Falhas famosas  Ariane 5 Flight 501(1996)  Foguete explodiu em seu vôo de teste.  Código-fonte reciclado do modelo Ariane 4 – modelo com menor aceleração horizontal - causou overflow durante uma conversão de uma variável float de 64 bits para int de 16 bits – o erro não era tratado por software. http://en.wikipedia.org/wiki/Ariane_5_Flight_501#Launch_failure
  22. 22. Programação Segura – Falhas famosas  Ariane 5 Flight 501(1996)
  23. 23. Programação Segura – Falhas famosas  Ariane 5 Flight 501(1996)  Componente vertical (E_BV) possui proteção;
  24. 24. Programação Segura – Falhas famosas  Ariane 5 Flight 501(1996)  Componente vertical (E_BV) possui proteção.  Componente horizontal (E_BH) não possui.
  25. 25. Programação Segura – Falhas famosas  Ariane 5 Flight 501(1996)  Foguete explodiu em seu vôo de teste.  Código-fonte reciclado do modelo Ariane 4 – modelo com menor aceleração horizontal - causou overflow durante uma conversão de uma variável float de 64 bits para int de 16 bits – o erro não era tratado por software. http://en.wikipedia.org/wiki/Ariane_5_Flight_501#Launch_failure  4 satélites foram perdidos, prejuízo total de US$370 milhões.
  26. 26. Programação Segura – Falhas famosas  Los Angeles LAX sem memória (2014)
  27. 27. Programação Segura – Falhas famosas  Los Angeles LAX sem memória (2014)  Plano de vôo de um avião espião não informou sua altitude.  Sistema de controle de vôo tentou calcular rotas possíveis para todas as altitudes “de zero a infinito” e ficou sem memória disponível. http://www.theregister.co.uk/2014/05/12/los_angeles_air_traffic_control_crash_caused_memory_shortage_u_2_spyplane_cia
  28. 28. Programação Segura – Falhas famosas  Los Angeles LAX sem memória (2014)  Plano de vôo de um avião espião não informou sua altitude.  Sistema de controle de vôo tentou calcular rotas possíveis para todas as altitudes “de zero a infinito” e ficou sem memória disponível. http://www.theregister.co.uk/2014/05/12/los_angeles_air_traffic_control_crash_caused_memory_shortage_u_2_spyplane_cia  Todas as decolagens e pousos suspensos por 46 minutos.
  29. 29. Programação Segura – Mãos à obra!  Vejamos um caso real de técnicas de programação segura aumentando a confiabilidade de um sistema
  30. 30. Programação Segura – Mãos à obra!  Hardware utilizado: Dragon12P-USB  MCU Freescale HCS12 (até 25MHz) com 256kb de memória  Interface USB baseada em FT232RL
  31. 31. Programação Segura – Mãos à obra!  Software desenvolvido:  RTOS preemptivo baseado em um microkernel cooperativo desenvolvido anteriormente na UNIFEI  Controladora de drivers de dispositivo  Drivers para diversos periféricos da placa  Monitor de porta serial  Sistema de controle PID  App em Java paraWindows para alterar parâmetros do PID via USB e visualizar seus sinais graficamente
  32. 32. Programação Segura – Mãos à obra!  Problema durante o desenvolvimento: falha nos dados enviados via serial  Na placa:
  33. 33. Programação Segura – Mãos à obra!  Problema durante o desenvolvimento: falha nos dados enviados via serial  No app:
  34. 34. Programação Segura – Mãos à obra!  Soluções adotadas:
  35. 35. Programação Segura – Mãos à obra!  Soluções adotadas:  01 – Converter a mensagem para ASCII  Dados do PID são todos números  Logo, se algum byte > 57 ou < 48, não é um dígito válido
  36. 36. Programação Segura – Mãos à obra!  Soluções adotadas:  02 – Padronizar todas as mensagens  Todas as mensagens se iniciam com ‘$’ e terminam com ’r’ (carriage return)  Começa a decodificar ao encontrar ‘$’, verifica o código do comando enviado, conta-se os bytes de parâmetros e verifica-se se o próximo byte é ‘r’
  37. 37. Programação Segura – Mãos à obra!  Soluções adotadas:  03 – Utilização de código CRC16  Uma operação é realizada utilizando os bits da mensagem e o seu resultado é anexado ao fim da mensagem (detalhes: http://en.wikipedia.org/wiki/Computation_of_cyclic_redundancy_checks)  Quando uma mensagem é recebida, seu CRC é calculado e comparado com o CRC anexado a ela
  38. 38. Programação Segura – Mãos à obra!  Soluções adotadas:  04 – Confirmação de recebimento  Quando uma mensagem é recebida e reconhecida, um sinal é enviado informando isso  Caso haja algum erro (no tamanho da mensagem ou no CRC, por exemplo), é enviado um aviso solicitando o reenvio da mesma
  39. 39. Programação Segura – Mãos à obra!  Resultado:  Formas de onda observada no osciloscópio:
  40. 40. Programação Segura – Mãos à obra!  Resultado:  Gráficos gerados por dados enviados pela serial:
  41. 41. Programação Segura – Considerações finais  Programação segura aumenta a complexidade do código – mais verificações a serem feitas. SEGURO NÃO-SEGURO
  42. 42. Programação Segura – Considerações finais  Programação segura aumenta o gasto de recursos computacionais. 0 200 400 600 800 1000 Proteção Mix Proteção Hamming Proteção CRC Prioridade Controladora de Drivers Earliest Deadline First Round Robin Consumo de Memória (bytes) Adicional Base
  43. 43. Programação Segura – Considerações finais  Considerar se a economia vale à pena...
  44. 44. Programação Segura – Considerações finais  Considerar se a economia vale à pena...
  45. 45. Programação Segura FIM

×