October 27th, 2025
like1 reaction

Dubious security vulnerability: Denial of service by loading a very large file

A denial of service vulnerability report was filed against a program, let’s call it Notepad. The actual text of the report was very hard to understand because the grammar was all messed up. I’ll give the finder the benefit of the doubt on the assumption that they are not a native English speaker. Here’s a cleaned-up version:

If you open multiple documents, one very large document and several small documents, and then try to exit all of them at once, the program will take a very long time saving the large document, resulting in a denial of service against the small documents.

I’m not sure what the point is here. The program does eventually finish saving the large document, so everything works out in the end. Are they suggesting that the program should save the smallest documents first? But then wouldn’t that be a denial of service against the large document if you had lots of small documents?

But wait, let’s ask the standard questions.

Who is the attacker?

I guess the attacker is the person who opened the very large document.

Who is the victim?

The victim is the person who is unable to save their small documents because the large document is hogging the program.

What has the attacker gained?

The attacker has annoyed the victim temporarily.

But wait, the attacker and the victim are the same person!

It’s not a security vulnerability that you have the power to annoy yourself. Other ways include “Putting itching powder in your pants” and “Throwing your glasses in the trash.”

Furthermore, there is no impact on other users, or even to other apps by this user. The only person you’re denying service to is yourself.

If you’re concerned about the order in which files are saved on close, you could explicitly close them in the desired order, like, I dunno, most important files first? Removable drives first?

And really, it’s not clear what the finder was expecting here. You loaded a large file, and now you’re saving it. Why is it surprising that this takes a long time?

This was resolved as “Not a vulnerability” with the subcategory “By design.” But sometimes I wish there was subcategory “So what did you expect?”

Topics
Other

Author

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.

5 comments

Sort by :
  • Sigge Mannen 57 minutes ago

    This one was pretty standard. What would be interesting to know is which vulnerability lead to Http.sys being “patched” breaking localhost

  • Michael Taylor 3 hours ago

    While I agree that this is not really a security vulnerability since the user isn't doing anything more than they can already do, I don't know that I agree that the attacker = victim. It isn't particularly hard to have someone download a malicious program that injects a DLL, or perhaps an image hijacking program, into a user's process that causes code to run when "notepad" starts. This code could automatically open a very large file and then save it which would trigger a denial attack against the user.

    There are easier ways to deny a user to be sure...

    Read more
    • Brian Boorman 1 hour ago

      Code injected into the process is not the “vulnerability” that was reported though. You’re comparing apples to oranges lemons.

      • Raymond ChenMicrosoft employee Author

        @Michael Taylor: The vulnerability is “Who let the USB stick into the building?” In the Notepad case, it’s “Who allowed the malware onto the system?” If you assume that the system has already been compromised, then it’s not surprising that the system can be compromised.

      • Michael Taylor

        I disagree. The point wasn’t about code injection. It was that whether an actor = victim or not isn’t relevant to whether this is a vulnerability or not. Who “put” the bad code onto the system doesn’t change whether it is a vulnerability or not. If I sneak into a building and put a USB virus on the network or I just leave the USB lying on the ground and some employee picks it up and puts it on the network doesn’t change the fact that it was a vulnerability.