Todas as ameaças à segurança são acionadas por bugs de software?

13

A maioria das ameaças de segurança que ouvi surgiram devido a um erro no software (por exemplo, todas as entradas não são verificadas corretamente quanto à integridade, estouros de pilha, etc.). Portanto, se excluirmos todos os hackers sociais, todas as ameaças à segurança são causadas por bugs? Em outras palavras, se não houvesse bugs, não haveria ameaças à segurança (novamente, excluindo as falhas humanas, como revelar senhas e outras)? Ou os sistemas podem ser explorados de maneiras não causadas por bugs?

security bug hacking

— gablin
fonte

4

Você chama a possibilidade de que eu possa adivinhar uma senha fraca como um bug de software? Se alguma coisa, é um problema de design, mas provavelmente é ainda mais fundamental que isso.

— Joachim Sauer

4

Você definiria um design ruim como um bug?

— precisa saber é o seguinte

1

Para dar suporte ao @StuperUser, no link " security.stackexchange.com/questions/25585/… ", não há nenhum erro no script de Dave. Mas é um design estúpido.

— Dilsh R

1

Se excluirmos todos os motivos de problemas de segurança, exceto erros, então sim.

— andho 21/12/12

Relevante: homepage.ntlworld.com./jonathan.deboynepollard/FGA/…

— Trevor Powell

25

Um bug é definido como software que não opera de acordo com as especificações. Agora, se as especificações estão com defeito, não é um erro de software. Se um cliente burro exige que todas as senhas devam ter códigos de três dígitos, sem período de carência entre entradas defeituosas, não é o software que deve ser responsabilizado.

Muitos sistemas têm um "modo de serviço" que pode substituir a segurança e, embora o acesso a ele seja seguro, os códigos geralmente vazam para o público.

Os avanços na matemática comprometem velhos métodos de criptografia. Algo que era viável segurança há 30 anos se torna fraco hoje em dia.

Existem vários métodos de roubo de dados que geralmente são ignorados. Um teclado sem fio tem um alcance de cerca de 2m, devido a pequenas antenas, e o código enviado não é criptografado. Lê-lo do outro lado da rua com uma boa antena é um método bem conhecido.

Às vezes, as trocas de segurança são feitas com total consciência das consequências - os sistemas de criptografia consomem energia e tempo de CPU. Os aplicativos de monitoramento incorporados geralmente enviam seus dados de maneira claramente legível ao público, porque primeiro o valor do comprometimento dos dados é insignificante e, em seguida, o custo extra da implementação da segurança é desnecessário.

Toda a segurança é baseada na confiança. Não é necessária nenhuma engenharia social para o administrador nomeado ficar desonesto e ler seu e-mail.

E, no final, alguém pode considerar aplicar um taco de beisebol no joelho uma técnica social?

— SF.
fonte

2

"se as especificações estão com defeito, não é o problema" hm, esta formulação soa escorregadia. Eu diria "é um bug nas especificações" . Quando testei, enviei e verifiquei com êxito as correções de algumas dezenas desses erros. E como um desenvolvedor eu tive a oportunidade de corrigir alguns dos tais "erros de especificação" relatados pelos testadores contra docs API fui designado para manter ...

— mosquito

8

@gnat - No entanto, um "erro na especificação" não é um erro de software , é um erro de design . A menos que você possa fazer o design como parte do software, é claro. Tudo depende de onde você desenha a linha.

— ChrisF

1

@ ChrisF: Obrigado por colocar em palavras o que eu queria dizer, mas não sabia como. Resposta editada para esclarecer.

— SF.

Nem sempre é claro que um recurso específico anotado em uma especificação é uma falha.

— Doc Brown

1

@DocBrown: Sim - às vezes é necessária redução da segurança como contrapartida custo-desempenho ...

— SF.

12

Pode haver situações em que os erros de hardware também causam problemas de segurança. Basta considerar um chip de RAM com defeito que espontaneamente vira o bit "isAdmin".

Ou considere um bug hipotético de hardware em que a proteção de memória não funcione conforme o esperado e um processo possa substituir a memória de outro processo sem acionar uma interrupção.

Para seu prazer na leitura: Segurança do computador comprometida por falha de hardware

— user281377
fonte

Quais são as chances do chip RAM lançar exatamente o isAdmin?

— M3th0dman

1

Muito pequeno, obviamente, mas se acontecer, é um encadeamento de segurança não causado por um bug do software.

— usar o seguinte comando

A chance de um sistema de computador corromper os bits de permissão em arquivos aleatórios é inteiramente possível. Um arquivo que é gravável globalmente e raiz SUID pode ser editado trivialmente para elevar as permissões do usuário.

— SF.

@ user281377 Você percebe que a probabilidade de selecionar exatamente exatamente o bit isAdmin de todos os bits é 1/34359738368 para uma máquina com 4 GB de RAM; isso, ignorando a probabilidade de um lançamento errado do chip.

— M3th0dman

@ m3th0dman Você provavelmente me entendeu mal. Não estou dizendo que esse é um grande problema com o qual todos devem se preocupar. É mais uma prova teórica de que um problema de hardware pode criar um encadeamento de segurança. Dito isso, é imaginável que um invasor que descubra o (s) bit (s) defeituoso (s) em um servidor possa encontrar maneiras de suprimir sua entrada até que algo crítico seja colocado nesses locais de memória.

— usar o seguinte comando

6

Muitas ameaças à segurança surgem de recursos de software, não de bugs. Muitos recursos de software muito úteis acabam tendo usos para o bem ou para o mal, dependendo apenas da intenção do usuário.

— ddyer
fonte

O atalho de um homem é a exploração da porta de trás de outro.

— precisa saber é o seguinte

5

Considere um ataque de negação de serviço distribuído (DDOS). Isso pode ser um risco à segurança, mas não é causado por um erro de software, mas por um invasor que ultrapassa os limites para os quais o sistema foi projetado. E todo sistema tem um limite.

Portanto, a resposta para sua pergunta é: não, nem todas as ameaças à segurança são acionadas por bugs de software.

— Pieter B
fonte

É um risco à segurança ? Certamente pode quebrar o seu site, mas pode quebrar a segurança do seu site?

— precisa saber é o seguinte

1

Isso depende de quão ampla ou restrita é sua definição de risco à segurança.

— Pieter B

4

Engenharia social.

Olá, sou XX do departamento de TI. No momento, seu computador está transmitindo vírus para outros computadores do escritório. Eu preciso do seu nome de usuário e senha para poder removê-lo.

Quando o hacker obtiver o nome de usuário / senha, ele poderá instalar com segurança trojans etc.

A engenharia social pode ser aplicada de várias maneiras e usá-la para burlar a segurança é uma delas.

— jgauffin
fonte

4

Uma provável razão para isso não ser mais votado é que o autor da pergunta excluiu explicitamente "hackers sociais".

— Joachim Sauer

@JoachimSauer Bom ponto. Não vi isso.

— precisa saber é o seguinte

3

Que tal algo como o Firesheep , o complemento do Firefox que rouba cookies transmitidos em uma rede sem fio compartilhada?

Você pode argumentar que a vulnerabilidade a esses ataques é um bug, mas também pode ser contra. Não há muito que um site possa fazer para evitar que os usuários sejam comprometidos, além de executar todas as comunicações por HTTPS - você pode dizer que é um erro aceitar comunicações HTTP em seu site?

— Carson63000
fonte

1

Eu categorizaria a decisão de transferir informações importantes e privadas sobre um meio não criptografado, um erro de design. Se isso deve ser considerado um "bug de software" é uma discussão separada, na minha opinião.

— Joachim Sauer

@JoachimSauer, e se o seu site se recusar a transferir qualquer informação por HTTP e, na verdade, for um MITM que estiver mapeando HTTP para HTTPS? Embora os navegadores suportem HTTP e os roteadores permitam sua passagem, há uma vulnerabilidade ao sniffing que só pode ser evitada por clientes extremamente preocupados com a segurança. Então, na verdade, a pergunta se torna: é um bug para navegadores da Web suportar HTTP?

— Peter Taylor

@ PeterTaylor: para esse problema, existe HTTP Strict Transport Security , que basicamente garante que o navegador saiba que seu site só deve ser visitado por uma conexão segura. Além disso: o solicitante excluiu explicitamente "hackers sociais" e, dependendo do usuário ignorar uma linha não segura, pode ser considerado contido nesse aspecto.

— Joachim Sauer

@JoachimSauer E se eu simplesmente proxyizar todo o tráfego no Site de Transporte Rigoroso, mas permitir conexões HTTP de volta aos clientes?

— 21412 Joshua Drake

@JoachimSauer: Na verdade, eu concordo com você. São decisões imprudentes de design de arquitetura que causam essa vulnerabilidade. Nada implementado incorretamente no código, que é o que eu chamaria de "bug".

— Carson63000

1

Sim, na medida em que uma falha na segurança do software é - qualquer que seja a causa próxima - uma falha do software em atender a seus requisitos.

Aceito que isso seja apenas uma tautologia, mas essa é a medida.

Às vezes, a segurança simplesmente não é um requisito (definido). E se ele for adicionado à lista de requisitos após a violação de segurança, eu não chamaria isso de "bug".

— Joachim Sauer

Só porque um requisito não foi solicitado no início de um projeto, o @JoachimSauer, não significa que não era obrigatório. A indústria de software passou mais tempo do que minha vida lidando com esse fato.