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.
>If the path contains traversals, the security system verifies that the user has permission to traverse those directories
Does it actually? It seems everyone and their dog has the “bypass traverse checking” privilege on by default…
Edit: No wait, checking whether the user has this privilege enabled counts as checking that the user can traverse.
That’s as crazy as reporting Notepad for being a security vulnerability.. oh wait, apparently it is, now. :\
Lack of psychic powers considered a security vulnerability. Sounds like a human generated report to me. AI may make a lot of bad security reports, but they are much more bland than that.
Looks like somebody knows about Living Off the Land Binaries but hasn’t grasped the full magnitude of the situation. Fixing the code doesn’t help because they proxy in an old version of a MS signed Windows binary.
Looks like the “security researcher” believes that checking the file’s extension is format validation…
Looks a bit like “bugs” certain scanner tools detect when scanning code.
Complaining at a command line tool that opens the file that is passed in through arguments. Make sure the path is not “tainted”. Well duh, the program is supposed to open the file. That’s what it was created for.
All of the would be a security vulnerability if the program were a server and accepted a file path from a network request. But for a (non-SETUID) command-line tool, there’s only one user involved.
Indeed, our own scanner tool does the same.
Indeed this “report” feels so generically bad, if it was written by a human we need to make them stop before they steal the jobs from AI.
If you were seeing “security” “vulnerability” “reports” this bad, I can’t imagine what AI-generated reports are like. I feel bad for the cURL developers (among others).