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?”
I agree with everything in your assessment. One thing I would say though, is that we don’t know the reporters motivations. It could be someone being lazy/opportunistic, maybe using AI to generate nonsense reports. However, it might be someone who is just getting into bug hunting. I hope that when the bug was dismissed that that moderator gave the person some encouragement and support, and pointed them in the right direction. Their thinking is in the right direction, they just need more experience to get the real, juicy bugs.
I think we are giving the submitter too much benefit of the doubt here, trying to twist the sequences of hypothetical events where this becomes a valid vulnerability report.
However, it could be a valid “usability” report. Many apps give you little info to guess if they are hung (force quit time!) or actually doing real work and you should wait it out.
My related pet peeve is how Windows still doesn’t do anything to indicate that an app is starting after you double click it’s icon, often leading to trying to start slow-loading apps twice.
The problem is that is very difficult for the application itself to know if it is hung. The message pump being stalled is easy to detect, if it offloads this work onto a background thread, then the application can seemingly keep working as normal. An application could put a "Saving" banner or some other way to indicate that an operation is taking place, but it is impossible to tell difference between a live lock and an operation just taking a very long time. This is the whole concept behind the Halting Problem. Even if you put a percentage, how do...
I agree there's no automated solution to this problem that works 100% of the time. But I bet you could come close.
For instance, disk access (writing or reading) is very often the cause of these apparent hangs. It would be trivial for the OS to add a "disk" icon to app the title bar whenever the app has been reading or writing above a specified threshold, say 1MB/s for the last 5 seconds. You'd have to empirically determine what a reasonable threshold is, 1MB/s is probably too low.
as for the launching issue, the macos already has a pretty...
These posts are so much fun to read, thank you 🙂
This one was pretty standard. What would be interesting to know is which vulnerability lead to Http.sys being “patched” breaking localhost
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...
Code injected into the process is not the “vulnerability” that was reported though. You’re comparing apples to
orangeslemons.@Michael Taylor. The primary actor is the one who left the USB drive, or who tricked the victim into downloading malicious stuff. The attack vector may now include a missing brain firewall but the effect is the same.
Next to that even if we consider the one who executes as the actor:
In these cases the victim is suffering from his/her actions. The balance between usability and security warrants a situation where a user can do something stupid, and jeapordize his/her own session. What should not be possible is that you download a dll, and another user on the system...
@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.
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.