It rather involved being on the other side of this airtight hatchway: Gaining code execution from a Trojan horse
A security vulnerability report arrived that went roughly like this:
The Xyz object can be used to execute arbitrary command lines.
LoadLibrary(L"xyz.dll");GetProcAddressforDllGetClassObject.- Call
DllGetClassObjectwithCLSID_XyzandIID_IXyz.- From the resulting object, call
IXyz::Initialize, and thenIXyz::Execute.
So far, we don’t have any statement of vulnerability. Sure, the Xyz object can be used to execute arbitrary command lines, but how is that a security vulnerability?
We asked the finder some questions to clarify the nature of the alleged vulnerability.
Q: What is the attack vector?
A: The attack vector is a Trojan horse executable. The victim needs to double-click the executable, which triggers the exploit.
Q: Is there elevation of privilege?
A: Not at this time.
Q: Is this remote code execution.
A: Essentially, it is not. The exploit must be downloaded to the victim machine in order to proceed with the attack.
Q: As a result of this exploit, what can the attacker do that they couldn’t do without this issue?
A: I don’t know. I am not a professional attacker. The main attack technique is as described in the original report. I think I explained it like this.
What we have is another case of if I can trick you into running my program, then I have gained code execution, also known jokingly as MS07-052: Code execution leads to code execution.
If you have gained sufficient trust with the victim that they will run any program you give them, then you don’t need the Xyz object in order to launch arbitrary command lines. You already have arbitrary code execution: That’s even better than command line execution! You don’t need to find an existing program that does whatever bad thing you want to do; you can just make your custom program do that bad thing directly.
Tying up some loose ends: The command line passed to IXyz::Execute runs with the same privilege as the caller, so there is no elevation of privilege.
Bonus chatter: Not long afterward, we received the following security vulnerability report:
Download and run the following script. It deletes all your files. If run as an administrator, it can delete operating system files.
That’s nice, but there is no security vulnerability yet. The script can delete only files that the user has permission to delete. In a way, you can say that the script “unlocks the user’s full file deletion potential”.
If the point of the attack is that the user can be tricked into deleting all their files by running this suspicious script, well, that’s not particularly surprising. If you can trick a user into running a suspicious script, then you have effectively tricked them into granting you full access to their account, and it’s not surprising that you can delete all their files.
Light
Dark
4 comments
I’d be curious to know what the review process of these reports looks like. What percentage of reports are like this?
Yes, I’d love to know the same. Certainly it’s not news that there are “security researchers” out there who don’t have the slightest idea what they’re doing, nor that there are scoundrels who’ll spam crap reports in the hope of picking up some bounties. But I’d love to know what percentage is… what’s the signal/noise ratio for security reports?
On the other hand, on closed platforms such as Xbox and (the late) Windows Mobile, if the end user can create, install, and execute a program even with only limited user privilege, the system is considered compromised.
And even in that case, this vulnerability report is bogus. The vulnerability would be how the rogue process got onto the system, not in what the rogue process can do once it’s there.