Toutes les menaces de sécurité sont-elles déclenchées par des bogues logiciels?

13

La plupart des menaces de sécurité dont j'ai entendu parler sont survenues en raison d'un bogue dans le logiciel (par exemple, toutes les entrées ne sont pas correctement vérifiées, les débordements de pile, etc.). Donc, si nous excluons tout piratage social, toutes les menaces de sécurité sont-elles dues à des bugs? En d'autres termes, s'il n'y avait pas de bogues, n'y aurait-il pas de menaces pour la sécurité (encore une fois, en excluant les défauts des humains tels que la divulgation de mots de passe et autres)? Ou les systèmes peuvent-ils être exploités de manière non causée par des bogues?

gablin
la source
4
Appelez-vous la possibilité que je pouvais deviner un mot de passe faible un bug logiciel? Si c'est quelque chose, c'est un problème de conception, mais c'est probablement encore plus fondamental que cela.
Joachim Sauer
4
Pourriez-vous définir une mauvaise conception comme un bug?
StuperUser
1
Pour prendre en charge @StuperUser, dans le lien " security.stackexchange.com/questions/25585/… ", il n'y a pas de bogue dans le script de Dave. Mais c'est une conception stupide.
Manoj R
1
Si nous excluons toutes les raisons des problèmes de sécurité, à l'exception des bogues, alors oui.
andho

Réponses:

25

Un bug est défini comme un logiciel ne fonctionnant pas selon les spécifications. Maintenant, si les spécifications sont défectueuses, ce n'est pas un bug logiciel. Si un client stupide exige que tous les mots de passe soient des codes à trois chiffres sans période de grâce entre les entrées défectueuses, ce n'est pas le logiciel qui doit être blâmé.

De nombreux systèmes ont un "mode de service" qui peut annuler la sécurité, et même si l'accès à celui-ci doit être sécurisé, les codes fuient souvent au public.

Les progrès des mathématiques compromettent les anciennes méthodes de cryptographie. Quelque chose qui était une sécurité viable il y a 30 ans devient faible de nos jours.

Il existe différentes méthodes de vol de données qui sont souvent négligées. Un clavier sans fil a une portée d'environ 2 m, en raison de petites antennes, et le code envoyé n'est pas crypté. Le lire de l'autre côté de la rue avec une bonne antenne est une méthode bien connue.

Parfois, les compromis en matière de sécurité sont faits en toute conscience des conséquences - les systèmes de chiffrement prennent de l'énergie et du temps CPU. Les applications de surveillance intégrées envoient souvent leurs données d'une manière clairement lisible au public car tout d'abord, la valeur de compromettre les données est négligeable, puis le coût supplémentaire de mise en œuvre de la sécurité n'est pas nécessaire.

Toute sécurité est basée sur la confiance. Il ne faut pas d'ingénierie sociale pour que l'administrateur désigné devienne un voyou et lise votre courrier.

Et à la fin, peut-on envisager d'appliquer une batte de baseball sur un genou une technique sociale?

SF.
la source
2
"si les spécifications sont défectueuses, ce n'est pas le bug" hm cette formulation semble glissante. Je dirais plutôt "c'est un bug dans les spécifications" . Quand j'ai été testeur, j'ai soumis et vérifié avec succès des correctifs pour quelques dizaines de ces bogues. Et en tant que développeur, j'ai eu la chance de corriger certains de ces "bogues de spécification" signalés par les testeurs contre les documents d'API que j'ai été chargé de maintenir ...
gnat
8
@gnat - Cependant, un "bug dans la spécification" n'est pas un bug logiciel , c'est un bug de conception . À moins que vous ne puissiez le concevoir dans le cadre du logiciel, bien sûr. Tout dépend de l'endroit où vous tracez la ligne.
ChrisF
1
@ChrisF: Merci d'avoir mis des mots sur ce que je voulais dire mais je ne savais pas comment. Réponse modifiée pour clarifier.
SF.
Il n'est pas toujours clair qu'une fonctionnalité spécifique écrite dans une spécification soit un défaut.
Doc Brown
1
@DocBrown: Oui - parfois une réduction de la sécurité est nécessaire en tant que compromis coût-performance ...
SF.
12

Dans certains cas, des bogues matériels peuvent également entraîner des problèmes de sécurité. Considérez simplement une puce RAM défectueuse qui retourne spontanément le bit "isAdmin".

Ou considérez un bogue matériel hypothétique où la protection de la mémoire ne fonctionne pas comme prévu et un processus peut écraser la mémoire d'un autre processus sans déclencher d'interruption.

Pour votre plaisir de lecture: la sécurité informatique compromise par une panne matérielle

user281377
la source
Quelles sont les chances pour que la puce RAM retourne exactement l'isAdmin?
m3th0dman
1
Très petit, évidemment, mais si cela se produit, il s'agit d'un fil de sécurité non causé par un bug logiciel.
user281377
Il est tout à fait possible qu'un système informatique corrompe les bits d'autorisation sur des fichiers aléatoires. Un fichier accessible en écriture globale et la racine SUID peuvent être modifiés de manière triviale pour élever les autorisations des utilisateurs.
SF.
@ user281377 Vous réalisez que la probabilité de sélectionner exactement le bit isAdmin parmi tous les bits est 1/34359738368 pour une machine avec 4 Go de RAM; ceci, en ignorant la probabilité d'un mauvais retournement de puce.
m3th0dman
@ m3th0dman Vous m'avez probablement mal compris. Je ne dis pas que c'est un problème majeur dont tout le monde doit se soucier. Cela ressemble plus à une preuve théorique qu'un problème matériel peut créer un fil de sécurité. Cela dit, il est imaginable qu'un attaquant qui découvre le ou les bits défectueux sur un serveur puisse trouver des moyens de remplir son entrée jusqu'à ce que quelque chose de critique soit placé sur ces emplacements de mémoire.
user281377
6

De nombreuses menaces de sécurité proviennent des fonctionnalités du logiciel, pas des bogues. De nombreuses fonctionnalités logicielles très utiles s'avèrent utiles pour le bien ou le mal, en fonction uniquement de l'intention de l'utilisateur.

ddyer
la source
Le raccourci d'un homme est un exploit détourné d'un autre.
Daniel Hollinrake
5

Considérez une attaque par déni de service distribué (DDOS). Cela peut être un risque pour la sécurité, mais il n'est pas causé par un bogue logiciel, mais plutôt par un attaquant dépassant les limites de la destination du système. Et chaque système a une limite.

La réponse à votre question est donc: non, toutes les menaces de sécurité ne sont pas déclenchées par des bogues logiciels.

Pieter B
la source
Est-ce un risque pour la sécurité ? Cela peut certainement briser votre site, mais peut-il briser la sécurité de votre site?
Carson63000
1
Cela dépend de l'étendue ou de l'étroitesse de votre définition du risque de sécurité.
Pieter B
4

Ingénierie sociale.

Bonjour, je suis XX du service informatique. Votre ordinateur transmet actuellement des virus à d'autres ordinateurs de bureau. J'ai besoin de votre nom d'utilisateur et de votre mot de passe pour pouvoir le supprimer.

Lorsque le pirate a obtenu le nom d'utilisateur / mot de passe, il peut installer en toute sécurité des chevaux de Troie, etc.

L'ingénierie sociale peut être appliquée de plusieurs manières et l'utiliser pour contourner la sécurité en est une.

jgauffin
la source
4
Une raison probable pour laquelle cela n'est pas davantage voté est que le demandeur a explicitement exclu le "piratage social".
Joachim Sauer
@JoachimSauer Bon point. Je n'ai pas vu ça.
jgauffin
3

Que diriez-vous de quelque chose comme Firesheep , l'addon Firefox qui vole les cookies transmis sur un réseau sans fil partagé?

Vous pouvez affirmer que la vulnérabilité à de telles attaques est un bug, mais vous pouvez également vous opposer à cela. Il n'y a pas grand-chose qu'un site Web puisse faire pour éviter que les utilisateurs ne soient compromis autrement que d'exécuter toutes les communications via HTTPS - pouvez-vous dire que c'est un bogue d'accepter les communications HTTP sur votre site Web?

Carson63000
la source
1
Je catégoriserais la décision de transférer des informations privées importantes sur un support non chiffré une erreur de conception. Si cela devait être considéré comme un "bug logiciel", c'est une discussion séparée, à mon avis.
Joachim Sauer
@JoachimSauer, que se passe-t-il si votre site Web refuse de transférer des informations via HTTP et qu'il s'agit en fait d'un MITM qui mappe HTTP vers HTTPS? Bien que les navigateurs prennent en charge HTTP et que les routeurs le permettent, il existe une vulnérabilité au reniflement qui ne peut être évitée que par des clients extrêmement soucieux de la sécurité. Donc, la question devient vraiment: est-ce un bug pour les navigateurs Web de prendre en charge HTTP?
Peter Taylor
@PeterTaylor: pour ce problème, il y a HTTP Strict Transport Security , qui garantit essentiellement que le navigateur sait que votre site ne doit être visité que via une connexion sécurisée. Aussi: le demandeur a explicitement exclu le "piratage social" et, selon l'utilisateur à ignorer une ligne non sécurisée, pourrait être considéré comme contenu dans cet aspect.
Joachim Sauer
@JoachimSauer Que se passe-t-il si je procède simplement à un proxy de tout le trafic vers le site de transport strict, mais autorise les connexions HTTP aux clients?
Joshua Drake
@JoachimSauer: En effet, je suis d'accord avec vous. Ce sont des décisions de conception architecturale imprudentes qui causent cette vulnérabilité. Rien de mal implémenté dans le code, ce que j'appellerais un "bug".
Carson63000
1

Oui, dans la mesure où une défaillance de la sécurité du logiciel est - quelle qu'en soit la cause immédiate - une défaillance du logiciel à satisfaire ses exigences.

J'accepte que ce n'est qu'une tautologie, mais c'est la mesure.


la source
Parfois, la sécurité n'est tout simplement pas une exigence (définie). Et s'il est ajouté à la liste des exigences après la faille de sécurité, je n'appellerais pas cela un "bug".
Joachim Sauer
Ce n'est pas parce qu'une exigence n'a pas été obtenue au début d'un projet, @JoachimSauer, qu'elle ne l'était pas. L'industrie du logiciel a consacré plus de temps que ma vie à faire face à ce fait.