• Dev Blogs
  • The Old New Thing
  • It rather involved being on the other side of this airtight hatchway: Attacking a user by modifying that user’s files
January 18th, 2023

It rather involved being on the other side of this airtight hatchway: Attacking a user by modifying that user’s files

Raymond Chen
Raymond Chen

A security vulnerability report arrived that went something like this:

Windows is vulnerable to remote code execution as follows:

  • Modify the file %USERPROFILE%\AppData\Local\Contoso\BlahBlah and add this line to the PlugIns section.
  • Run the contoso.exe program.
  • The contoso.exe program loads its configuration from the BlahBlah file.
  • When the Contoso app starts, it tries to create a plug-in from the object you configured in PlugIns section, passing the initialization data you also specified in the PlugIns section.
  • By crafting the initialization data, you can get the system-provided object to run a command controlled by the attacker.

That’s all very interesting, but what is the vulnerability?

They never said.

The fact that the system-provided object can be induced into executing a command based on its initialization data is not surprising in this case: The initialization data for this particular system-provided object contains a serialized COM object, and deserializing it would naturally end up creating whatever you serialized.

My guess is that the finder was excited that they could modify a file in a way that leads to code execution when a program is run. But let’s look at our usual questions.

Who is the attacker?

The attacker is presumably somebody who is able to modify the configuration file.

Who is the victim?

The victim is presumably the user whose configuration file got modified.

What has the attacker gained?

Actually, if you look back at the earlier two questions, you’ll see that the attacker and the victim are the same person!

In order to modify a user’s files, you have to be that user or an administrator. In all cases, you haven’t gained any privileges beyond what you already had. If you’re the user, then you are attacking yourself. If you’re the administrator, well, it’s not interesting that the administrator can attack any user.

If you already had the power to modify the user’s files, then you don’t need to go to all the work of editing an obscure configuration file for a program the user might not even run. Just drop a batch file in the user’s Startup folder.

Category
Old New Thing
Topics
Other

Author

Raymond Chen

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.

4 comments

Discussion is closed. Login to edit/delete existing comments.

Newest
Newest Popular Oldest
  • abc def

    I usually don't like to get involved with stuff that I don't fully understand, but in this case I'll try to play the devil's dumb advocate: what if the Contoso app is misconfigured and it always wants to run with elevated privileges? The user is accustomed to just clicking OK on the security prompt because they trust the application. Even if they are not accustomed to clicking OK, they might just shrug it off as a hiccup after an automatic update and ignore it anyway. The user might be a lot more careful with an unknown script or application placed...

    Read more
    • Antonio Rodríguez

      Right, in that case, it could be a privilege elevation vulnerability in Contoso. But given the wording of the report, I don't think it is the case: if it were, the reporter would have noted it. Anyhow, I think replying the reporter in that way would solve it: the ball would be again in their field, and if there were an elevation of privilege, s/he would be able to reply telling it.

      That said, the attacker and the victim does not have to be the same person. An admin has access to every other user's files, so it can "attack" other...

      Read more
    • Andy Cadley · Edited

      You’re still attacking yourself though. You modified the config file and you have permission to elevate the executable, so you aren’t doing anything you couldn’t do anyway since if you can run Contsoso.exe elevated you could run malware.bat elevated if you chose to.

      If the contoso.exe had installed a system service that read it’s plugin config from an unprotected directory, then an unprivileged user could cause plugins to be loaded with higher permissions than the user has. That would be a vulnerability in contoso.exe and not Windows, however.

    • Raymond ChenMicrosoft employee Author

      Requiring that the plug-in be in a secure folder doesn’t help. (1) Most users want to use plug-ins without requiring admin privileges. Imagine if you had to be admin to install a browser plug-in. (2) The executable in this case is indeed in a secure folder. It’s a system DLL that is being repurposed by the attacker. In order to carry out this attack, you must have already gained file planting access to the user, and it’s the file planting that is the vulnerability, not the consequences of the file planting.

Read next