Oui. Toute attaque qui a pour but de nier l'utilisation normale d'un service par des utilisateurs légitimes est par définition un DoS (Denial of Service).

DDoS (Distributed DoS) est caractérisé par des inondations créant un DoS (dans toutes les définitions disponibles). Un seul nœud causant avec succès une inondation est assez rare.

Mais DoS peut être causé par un large éventail de déclencheurs.

CVSS a même un exemple de crash logiciel classé comme DoS pour vous:

En raison d'une faille dans la fonction de gestion des commandes RPC , il est possible de manipuler des pointeurs de données dans le processus VMX (Virtual Machine Executable). Cette vulnérabilité peut permettre à un utilisateur d'une machine virtuelle invitée de planter le processus VMX entraînant un déni de service (DoS) sur l'hôte ou d'exécuter potentiellement du code sur l'hôte. [empasis mine]

Et du Wiki:

Les attaques par déni de service sont caractérisées par une tentative explicite des attaquants pour empêcher l'utilisation légitime d'un service. Il existe deux formes générales d'attaques DoS: celles qui bloquent les services et celles qui inondent les services. Les attaques les plus sérieuses sont distribuées.

Donc, oui, un simple crash est un DoS.

La sécurité est souvent considérée comme offrant trois propriétés:

• Disponibilité
• Intégrité
• Confidentialité

Dans votre cas, vous avez trouvé quelque chose qui permet à un utilisateur d'affecter la disponibilité du service. En fonction de ce que le service fournit, cela peut être ennuyeux ou catastrophique.

Très souvent, les services défaillants seront automatiquement redémarrés. Ceux-ci peuvent atténuer les plantages occasionnels, mais le redémarrage d'un service est généralement beaucoup plus coûteux que le coût habituel de gestion d'une connexion. Dans ce cas, exécuter votre requête «planter le serveur» cinq ou six fois par seconde peut ne pas représenter beaucoup de bande passante, mais cela reste probablement assez difficile sur le serveur moyen.

Je voulais ajouter un autre détail important qui n'est pas explicitement indiqué dans les autres réponses. Vous avez dit ceci:

Cela fonctionne en envoyant au serveur une charge utile spécialement conçue, ce qui fait que le code du serveur génère une erreur, et en raison d'un manque de gestion des erreurs - Il plante ( jusqu'à ce que quelqu'un s'exécute à nouveau ).

(c'est moi qui souligne). Cette mise en garde est importante car la manière dont ces services répondent à un crash peut varier énormément entre les ensembles de technologies.

Pas un DoS

Par exemple en PHP ou la plupart cgi implémentations, une seule requête plantée n'a absolument aucun impact sur les autres requêtes. Le serveur ne parvient pas à envoyer une réponse appropriée pour la demande en panne, mais les autres demandes provenant d'utilisateurs légitimes continuent d'être traitées correctement par le serveur. Dans ce cas, le crash ne concerne que vous-même - pas les autres - et il serait donc difficile de qualifier cela d'attaque DoS. Bien sûr, il y a un bogue et vous vous refusez le service, mais si le serveur continue de fonctionner normalement pour tout le monde, il n'y a pas vraiment de déni de service en cours.

A DoS

Si, cependant, votre charge utile provoque l'arrêt du service réel et qu'aucune demande ne peut être reçue par le serveur jusqu'à ce qu'une action soit entreprise pour restaurer les services (que ce soit par un administrateur ou par une restauration automatique après un court laps de temps), vous avez définitivement un déni de service car le crash que vous avez causé a empêché le service de répondre aux utilisateurs légitimes (comme indiqué dans d'autres réponses).

Dans certaines circonstances, l'attaque "Not a DoS" qui ne supprime pas le serveur pourrait éventuellement être promue en attaque DoS réelle si vous pouvez "tromper" un utilisateur légitime pour qu'il visite une URL contenant votre charge malveillante. La plupart du temps, ces attaques n'ont pas beaucoup d'impact pratique, car le service continuera à fonctionner normalement lorsqu'ils l'utiliseront plus tard normalement. Cependant, il peut y avoir de rares circonstances où la charge utile est conservée dans la session et verrouille donc définitivement l'utilisateur (j'ai déjà vu des gens déclencher accidentellement de telles circonstances dans la vie réelle).

D'après votre description, c'est difficile pour savoir à laquelle de ces catégories appartient votre charge utile particulière, mais il y a une distinction importante à faire.

Votre attaque est essentiellement la définition de DOS, elle refuse littéralement le service et vous utilisez le terme correctement.

La consommation de bande passante est une approche naïve qui ne nécessite pas que le serveur ait une vulnérabilité spécifique, mais n'est certainement pas le seul.

Voici un vrai CVE sur Apache décrivant une attaque DOS similaire (se bloque avec segfault) en utilisant cette terminologie:

http: // cve .mitre.org / cgi-bin / cvename.cgi? name = CVE-2018-8011

Des attaques encore plus compliquées sont parfois des attaques DOS triviales et reçoivent également cette étiquette. Un bug d'exécution de code distant écrasant la pile sans un shellkit écrase toujours la pile avec des valeurs incorrectes provoquant un segfault.

Oui, cela pourrait être appelé une vulnérabilité DOS. J'ai entendu cela appelé une "attaque DOS d'application".

Un autre exemple: un site qui exécute un antivirus sur les fichiers téléchargés, où quelqu'un télécharge un fichier zip de 100 000 fichiers zip contenant 100 000 fichiers de 2 Go de zéro bits . Un très petit fichier zip qui utilise toute la mémoire disponible pour ouvrir et analyser.

Si vous refusez à un utilisateur légitime d'utiliser une ressource [CPU, RAM, disque, bande passante réseau (réinitialisation du mot de passe?] Alors vous pourriez l'appeler une attaque DOS.

Si toutefois l'attaque corrompt simplement l'état de l'application (par exemple, permet à un utilisateur non autorisé de mettre l'application en mode lecture seule), alors je pourrais être enclin à simplement appeler cela une application (ou sécurité).

Est-il judicieux de considérer un crash logiciel serveur, comme une attaque DOS?

Tout acteur agira dans au moins deux dimensions par rapport à toute activité: capacité et permission.

La capacité a 2 possibilités: capable et incapable .

L'autorisation a également 2 possibilités: autorisé ou denied.

Par conséquent, un bon acteur effectuera une action uniquement si capable et allowed.

De mon point de vue, crash logiciel = impossible et DOS = refusé . Puisque les deux sont des "valeurs" sur des dimensions différentes, elles ne peuvent pas être considérées comme similaires, même si les effets pour l'utilisateur final peuvent être similaires. Cependant, les effets vus par l'administrateur du réseau peuvent être totalement différents - les solutions pour eux sont généralement différentes.

De plus, une attaque DOS peut entraîner un crash logiciel, mais ils ne sont toujours pas similaires - ils sont uniquement lié - cause et effet.

Exemple: tout logiciel peut planter pour un nombre incalculable de raisons même en l'absence d'attaque.

Remarque: un crash logiciel signifie généralement que le processus est arrêté par le système d'exploitation en raison d'une opération défectueuse. DOS est possible généralement parce que le logiciel se comporte mal, mais ne plante pas.