Dtyjlui

Yes. Any attack which has as a goal to deny the normal usage of a service by legitimate users is by definition a DoS (Denial of Service).

DDoS (Distributed DoS) is characterised by floods creating a DoS (in all available definitions). A single node causing a flood successfully is kind of rare.

But DoS can be caused by a broad range of triggers.

CVSS even has an example of a software crash classified as DoS for you:

Due to a flaw in the handler function for RPC commands, it is possible
to manipulate data pointers within the Virtual Machine Executable
(VMX) process. This vulnerability may allow a user in a Guest Virtual
Machine to crash the VMX process resulting in a Denial of Service
(DoS) on the host or potentially execute code on the host.
[empasis mine]

And from Wiki:

Denial-of-service attacks are characterized by an explicit attempt by
attackers to prevent legitimate use of a service. There are two
general forms of DoS attacks: those that crash services and those that
flood services. The most serious attacks are distributed.

So, yes, a simple crash is a DoS.

Quite often security is looked at as providing three properties:

• Availability


• Integrity


• Confidentiality

In your case, you've found something that allows a user to affect the availability of the service. Depending upon what the service provides, that might be annoying or it might be catastrophic.

Quite often failed services will be automatically restarted. These can mitigate occasional crashes, but restarting a service is usually far more expensive than the usual cost to handle a connection. In this case, executing your 'crash the server' request five or six times a second might not be much bandwidth but is still probably pretty rough on the average server.

I wanted to add one more important detail not explicitly stated in the other answers. You said this:

It works by sending the server some crafted payload, which makes the
server code throw an error, and due to lack of error handling - It
crashes (until someone runs it again).

(emphasis mine). That caveat is important because the way such services respond to a crash can vary wildly between technology sets.

Not a DoS

For instance in PHP or most cgi implementations, a single crashed request has absolutely no impact on other requests. The server fails to send a proper response for the crashed request, but other requests coming in from legitimate users continue to be handled properly by the server. In this case the crash only affects yourself - not others - and so it would be hard to qualify that as a DoS attack. Sure, there is a bug, and you are denying yourself service, but if the server continues to operate normally for everyone else then there isn't really any denial of service going on.

A DoS

If, however, your payload causes the actual service to go down and no more requests can be received by the server until some action is taken to restore services (whether by an admin or automatic restoration after a short period of time) then you definitely have a denial of service because the crash you caused stopped the service from responding to legitimate users (as discussed in other answers).

Under some circumstances the "Not a DoS" attack that doesn't take down the server could possibly be promoted to an actual DoS attack if you can "trick" a legitimate user to visit a URL with your malicious payload. Most of the time though such attacks don't have much practical impact since the service will continue to operate normally when they later use the service normally. However there could be rare circumstances when the payload is persisted to the session and therefore permanently locks out the user (I've seen people accidentally trigger such circumstances in real life before).

From your description, it's hard to tell which of these categories your particular payload falls into, but there is an important distinction to be made.

Your attack is basically the definition of DOS, it literally denies service and you are using the term correctly.

Consuming bandwidth is a naive approach that does not require the sever to have a specific vulnerability, but is certainly not the only one.

Here is a real CVE about Apache describing a similar DOS attack (crashes with segfault) using that terminology:

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

Even more complicated attacks are sometimes trivially DOS attacks and are given that label as well. A stack smashing remote code exec bug without a shellkit still smashes the stack with incorrect values causing a segfault.

Yes this could be called a DOS vulnerability. I have heard this called an "Application DOS Attack".

Another example: a site that runs a virus scanner over uploaded files, where someone uploads a zip file of 100,000 zip files containing 100,000 2gb files of zero bits. A super small zip file that uses all of the available memory to open and scan.

If you are denying a legit user from utilizing a resource [CPU, Ram, Disk, Network bandwidth (password resets?] then you could call it a DOS attack.

If however the attack just corrupts the application's state (say lets an unauthorized user set the app into read-only mode) then I might be inclined to just call that an application (or security) vulnerability.