O documento discute programação segura, apresentando exemplos de como diferentes perfis enxergam um código, falhas famosas causadas por bugs e como técnicas como verificação de tamanho de strings, mensagens padronizadas, CRC e confirmação de recebimento melhoram a segurança da comunicação serial entre um microcontrolador e um aplicativo.
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Programação Segura - Introdução
Como cada um vê o trecho de código abaixo?
Invasor:
“Opa, aí sim!”
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.
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. 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.
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
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.
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. 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. Programação Segura – Mãos à obra!
Vejamos um caso real de técnicas de programação segura
aumentando a confiabilidade de um sistema
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. 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. Programação Segura – Mãos à obra!
Problema durante o desenvolvimento: falha nos dados
enviados via serial
Na placa:
33. Programação Segura – Mãos à obra!
Problema durante o desenvolvimento: falha nos dados
enviados via serial
No app:
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. 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. 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. 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. Programação Segura – Mãos à obra!
Resultado:
Formas de onda observada no osciloscópio:
40. Programação Segura – Mãos à obra!
Resultado:
Gráficos gerados por dados enviados pela serial:
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. 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. Programação Segura – Considerações finais
Considerar se a economia vale à pena...
44. Programação Segura – Considerações finais
Considerar se a economia vale à pena...