When you submit a security vulnerability report, we go the extra mile and try to fix your typos

A security vulnerability report arrived that went like this:

  1. Create the folder C:\Folder and grant full control to authenticated users.
  2. Create the subfolder C:\Folder\bar.
  3. Create the files C:\Folder\bar\foo and C:\Folder\foo.
  4. Deny all permissions to everyone for those two files.
  5. Set the owner of the two files to a domain administrator or some other user.

Even though all access has been revoked to the two files, the following program deletes C:\Folder\foo:

#include <windows.h>

int main(int, char**)
 return 0;

From reading this page, it seems that file deletion is related to the control on the file itself and not on the parent folder. And anyway, both have the same rights.

There's nothing wrong here. Even though all access to the file has been revoked, all authenticated users still have DELETE_CHILD permission on the parent, and as we noted some time ago, that is sufficient access to delete any file in the directory. This is also noted in the documentation for Delete­File:

  • To delete or rename a file, you must have either delete permission on the file, or delete child permission in the parent directory.

The page cited by the finder lists the various permissions available to files and folders. It even says

If a user has full control over a folder, the user can delete files in the folder regardless of the permission on the files.

That statement covers the exact scenario described here: The permissions on the parent folder grant full control, which includes DELETE_CHILD. Mind you, that statement could be strengthened by weakening the hypothesis and strengthening the conclusion:

If a user has permission to delete children of a folder, the user can delete files and subfolders in the folder regardless of the permission on the files or subfolders.

Table 13-3 reiterates that Full Control on a folder grants permission to delete files and subfolders.

So everything is behaving as normal, and the security team replied, "Upon investigation we have determined that this is not a valid vulnerability as you are an authenticated user, or providing authenticated access to a potential attackers to reproduce this report." In other words, "You gave authenticated users full control, so it's not a vulnerability that any authenticated user has full control."

What made this interesting to me is that the finder posted to Stack Overflow wondering why this wasn't a bug. And then the finder eventually discovered a typographical error in their sample program: The first Delete­File call passes the string L"C:\\Folder\\Bar\foo" instead of L"C:\\Folder\\Bar\\foo". "I'm not sure why that was not Microsoft's answer."

Okay, let's look back at the situation. The finder appeared to be concerned about two things but articulated only one of them in the report.

  1. The user is able to delete the file C:\Folder\foo.
  2. The user is not able to delete the file C:\Folder\bar\foo even though its permissions are identical to C:\Folder\foo.

The finder raised only the first question, and that's the question the security team answered.

That said, the security team tries to be thorough and in this case assumed that the finder created the C:\Folder\bar\foo file for a reason, namely in order to delete it. And if they fix the obvious typo in the program, the file does get deleted. So it seems that the deletion is following the security model in all cases. The finder never said, "But the C:\Folder\bar\foo file is not deleted," so the security team assumed that the finder was expecting the file to be deleted, and it was.

The security team didn't mention the typo because they assumed that it was just a transcription error. In general, the security team gives the finder all benefit of the doubt and assume that they are dealing with an experienced programmer who understands the security model. Any misunderstandings are assumed to be due to communication problems or poor explanations. These sorts of things happen a lot with legitimate security issues because it is common to receive vulnerability reports from people for whom English is not their native language. You don't want to reject an issue just because you can't understand it. And you definitely don't want to reject an issue just because there was a typo in the report.

In a sense, the security team failed this particular finder because they assumed too much from the finder.¹


But you don't want to take the default position that the finder simply doesn't understand how the system works, because that biases you toward rejecting issues just because you can't understand them when they are initially presented to you.

¹ It's like asking a question at a physics symposium: The speaker is going to assume that you're a physicist (or at least well-versed enough in physics to understand the proceedings at a physics symposium), and they will fix the obvious errors in your question, assuming that you misspoke or were nervous. But if you're not a physicist, then those automatic corrections might end up confusing you even more, because they are now answering a question different from the one you asked.

Comments (6)
  1. Karellen says:

    If a user has permission to delete children of a folder, the user can delete files and subfolders in the folder regardless of the permission on the files or subfolders.

    Now that’s interesting.

    Coming from a Unix background, deleting files you can’t modify (or even read!) from a directory you can modify makes sense, because you’re modifying the directory, not the file. Thinking about the problem in the case of multiple hard links to the file clarifies the situation, because deleting one link to a file (or ‘unlinking’ it) doesn’t *necessarily* delete the file, unless it happens to be the last link to the file.

    However, the situation is different for subdirectories. If you don’t have permission to modify a subdirectory, you can’t make the subdirectory empty. If you can’t make the subdirectory empty, you can’t unlink the subdirectory from the current directory, no matter what permissions you have on the current directory.

    The requirement that a directory be empty before it can be unlinked is there because it is generally assumed that directories are only linked from a single parent (“..” links excepted) and form a DAG – normal users simply aren’t allowed to make multiple links to a directory, and the operation may even fail for “root” for a number of reasons. And you’re not allowed to delete a non-empty directory, because then you’d lose the links to the files within. Unless the operation was automatically recursive, but recursiveness is generally “not done” for system calls.

    1. I think you misinterpreted the statement. It’s not saying that you have delete permission recursively all the way down. It’s saying you can remove subfolders of the thing you have DELETE_CHILD permission on. (Those subfolders must first be empty, and emptying the subfolder requires its own permissions.)

      1. David-T says:

        Perhaps a clearer version of the strengthened statement would be “and empty subfolders.”

      2. Karellen says:

        Ah, yes, that is what I had read into it. My mistake.

        (What’s that? Yes, I have been bitten by not being able to delete a subdirectory, despite having full access to its parent, in the past. How did you guess?)

  2. Joshua says:

    Well, hmmm. I discovered that the claim that SMB shares leaked password-equivalents over the wires in 1999, but this was in the days of telnet for my college so nobody cared. What do you know, a security fix for this comes out in 2012 and the lowest OS version to get it is Vista.

    It was kind of too bad partly that XP didn’t get it, but worse in a way. DOS didn’t get it, and networked DOS was still a thing for image deployment. Having to run an old server version just so the DOS CDs could connect was painful.

  3. MarcK4096 says:

    There have been many times when I called in a support issue and later when I read the actual text of the ticket, it wasn’t even close to what I told the technician. These were always the most critical problems because we were encouraged to call in instead of using the online ticket system in order to get a faster response. These days, I put in cases first and then just call to request an escalation.

Comments are closed.

Skip to main content