A security vulnerability report came in that claimed that a program was vulnerable to information disclosure when run as an administrator because it opened whatever file you passed on the command line and read from it, before reporting an error because the file is in the incorrect format.

They identified multiple issues.

• The program does no path validation. It accepts any file name and blindly opens it and reads its contents.
• The program does not block path traversal via ...
• The program does not check that the file is in an approved directory.
• The program does not validate that the user has permission to access the file.
• The program does not validate that the file is in the correct format before opening it.

According to the report, all of these defects lead to information disclosure.

Okay, as usual, we have to figure out who the attacker is, who the victim is, and what the attacker has gained.

The attacker is, presumably, the person running the carefully-crafted command line.

The victim is, presumably, the person whose file contents are disclosed.

But those are the same person!

Remember, the security term “information disclosure” is just a shorthand for unauthorized information disclosure. It is not a security vulnerability to disclose information to someone who is authorized to see it.

In this case, it’s fine for the program to take the information from the user and use it to access a file while running as that user. The security check happens as that user, so it’s not true that “The program does not validate that the user has permission to access the file.” The validation happens when the program tries to open the file and maybe gets “access denied” if they don’t have access.

The claim that there is no “approved directory” check is a bit spurious, since the program doesn’t have any concept of an “approved directory” to begin with.

There is nothing wrong with directory traversal or the lack of path validation, because the file is opened as the user. If the path contains traversals, the security system verifies that the user has permission to traverse those directories. If the provided path is illegal, then the open call will fail with an “invalid file name”. The underlying Create­File call does the validation. Let the security system do the security checks. Don’t try to duplicate their work, because you’re probably going to duplicate it incorrectly and introduce a security vulnerability.

If you think about it, the finder’s complaints about this program also apply to the TYPE command. It opens the file whose path is provided as the command line argument and prints it to the screen. So why did they file the security issue against this program? Probably because it makes their report sound more interesting.

Bonus chatter: The finder also considered it a security vulnerability that the program does not validate that the file is in the correct format before opening it. But how could it validate the file format without opening the file, reading the contents, and validating those contents? This is like handing someone a sealed envelope and saying, “Don’t read the enclosed letter if it contains spelling errors. But if it’s error-free, follow the instructions written in the letter.” Do they expect the program to be psychic and know whether the file contents are valid without reading it? If so, then why even open the file at all? You already used psychic powers to know what’s in the file, so just operate on the file contents you determined via your psychic powers.