It rather involved being on the other side of this airtight hatchway: Messing with somebody’s registry


A security vulnerability report came in that went something like this:

If a user obtains write access to another user's registry, then the user can make that other user's life miserable by making the following changes to the victim's registry. … A proof of concept program is attached which makes the necessary changes to the registry.

While the above statement is true, it doesn't really say anything interesting either.

  • It is possible for users to make their own lives miserable.
  • If you get write access to another user's settings, you can change those settings in a way that makes that user's life miserable.

The proof of concept program edits keys in the HKEY_CURRENT_USER registry hive, so it must be run by the user whose life you are trying to make miserable (or by someone who has permission to make that user's life miserable).

It is not a security vulnerability that users can make their own lives miserable. If you want to deny yourself access to your own files, or if you want to render parts of your own work environment non-functional, then go ahead. Smash your television set. Take the books from your bookshelf and throw them onto the floor. It's your television set. They're your books. If you want to make using them inconvenient or impossible, then that's your prerogative.

The obstacle to wreaking all this havoc on other users is obtaining write access to their registry. The finder didn't actually demonstrate how to obtain this; they merely noted that if you could obtain such access, then you could make the other user's life miserable.

Well, yeah. If you have the keys to somebody's house, you can go in and smash their television set and throw their books on the floor.

But it all hinges on getting the keys to the house.

Until you show how to get access to the other user's registry, you haven't stated anything that isn't already obvious.

Comments (11)

  1. Brian_EE says:

    I did this once – we had a coworker that we liked to prank. Let’s call him “Joe”.

    Back before the days of remote desktop in the OS (I’m thinking this was Win2K Pro in enterprise environment) we would use VNC to remote to our office PCs from the engineering lab PCs. VNC stored the connection password in the registry. It was encrypted. With DES. With a key that was hardcoded in the source. VNC was open source.

    I wrote a small command line program that would take the key as a command line argument and spit out the plaintext connection password and stored the .exe on a shared network resource. When “Joe” walked away from the lab PC one time without locking it, I sat down, did a remote registry connect to his office PC (with his own credentials from the unlocked lab machine), extracted the encrypted password and then decrypted it.

    Fun times ensued when I went back to my office and VNC connected to “Joe’s” machine while he was using it – random mouse movements and keypresses. Ah – the good old days!

  2. Neowen says:

    This is interesting because while this shows one of the great strengths of Windows, especially for enterprise, that also proves to be a major weakness. The security model is largely around protecting the user from external sources. Contrast this with something like IOS security model, which protects the system from the user, and the user’s stuff from software (even if the user is running it). While it provides tons of limitations, it also makes for a much more stable experience. I know the store apps model attempts to get many of these same benefits, but I wonder if it will ever get the traction required. It would really help if store style apps were installable from other sources, so you could get some of these same benefits without locking people into an ecosystem.

    1. You give the key about iOS when you talk about the Windows Store: iOS model is focused more on controlling the ecosystem (and milking third party developers through App Store commissions) than on security. In practice, it is difficult to argue that the “store” app model is more secure than the traditional desktop model: Android is plagued with malware and iOS has its own share. If the OS is reasonably secure, it’s easier to trick the user than to exploit a security vulnerability. And the OS or the app store can only go so far to prevent it.

      Related to this, some people say Unix is more secure than Windows because Linux doesn’t have malware. But on mobile the opposite is true: Windows is the cleanest platform, against Unix-based Android and iOS. What do Linux and Windows Phone have in common? An usage quota under 2% – which makes the malware industry ignore them.

    2. You give the key about iOS when you talk about the Windows Store: iOS model is focused more on controlling the ecosystem (and milking third party developers through App Store commissions) than on security. In practice, it is difficult to argue that the “store” app model is more secure than the traditional desktop model: Android is plagued with malware and iOS has its own share. If the OS is reasonably secure, it’s easier to trick the user than to exploit a security vulnerability. And the OS or the app store can only go so far to prevent it.

      Related to this, some people say Unix is more secure than Windows because Linux doesn’t have malware. But on mobile the opposite is true: Windows is the cleanest platform, against Unix-based Android and iOS. What do Linux and Windows Phone have in common? An usage quota under 2% – which makes the malware industry ignore them.

      (Had to post this twice because the first time it came as an empty comment; if duplicate, feel free to delete one copy :-) ).

    3. Gee Law says:

      Did you know (today’s tip): you could install Store-style apps from external sources other than the Store. Adobe Reader DC installs an appx (serving as a notification manager) to the user when the user signs into his/her Adobe account for the first time.

  3. DavidMCandy says:

    A long time ago some used to advocate that computer users’ should be licensed. Maybe that should be revisited?

  4. This is a rather hilarious version of an otherwise valid security concern. The writer of this report has sniffed the problem but does not know exactly what it is. Hence, the hilarity of the report. However, this hilarious report has much verbal similarity to a report about those nightmarish ransomware.

    The real problem is while you can smash your own television set by your own bare hands, you cannot delete a file by your bare hands. You need a program to act on your behalf. When you say “I deleted a file” you are employing metonymy; you mean I ordered “File Explorer to delete a file and it did it”. That’s what malware take advantage of. They encrypt your files and hold them for ransom, and it is then you feel the need to peel off that layer of metonymy.

    In fact, this kind of security concerns has brought about the invention of mandatory access control and User Account Control. In an OS that supports MAC (Windows does not), when the malware reaches the other side of the hatchway, it is still denied write access to the user’s settings. Only a certain trusted and digitally signed app has write access.

    1. Store apps are security principals and do not have access to all the files that the user can access, unless the user grants them access. So if you are willing to stop running Win32 apps, you have process-level protection. The app would have to break out of the low integrity container in order to smash your television set.

      1. Yes. There are a lot of good ideas in the UWP architecture. I almost feel sorry for those good ideas if not for the whole platform. (Since I want to be a good pleasant blog reader who does not wander off topic, I’ll just sigh for now.) We seem to have a semblance of agreement here. That’s good for today.

    2. brliron says:

      Well, computers are all about countless layers. You say you ordered “File Explorer to delete a file and it did it”, but it didn’t actually did it. It just asked the OS to do it. And the OS didn’t actually do it, it just asked the hard disk driver to do it.
      And you didn’t order File Explorer to delete the file either. You only talked to the keyboard driver and the mouse driver, who talked to the window manager, who talked to the file explorer.

      1. True.

        But the point of Fleet Command’s comment was that when we employ these intermediary layers we have to trust that they will do what they say they will do. e.g. File Explorer, the OS, and the HDD and all the rest of the stack will delete exactly the file requested AND avoid doing any nasal daemons. The whole point of malware is that it is fundamentally Untrustworthy; it can and will do anything.

        The nub of the problem FC is pointing out is that the pre-UWP security model of Windows, designed in those oh-so-innocent Dayes of Yore, in effect assumes all code the user can be persuaded (implicitly or explicitly) to execute, is fully trusted by the user, and hence by the OS, to do anything and everything the user could use any other application to do.

        The original CAS facility in early .Net was an attempt to move towards explicit and limited trust of code. Sadly it came out of the gate too awkward to use and in some ways ahead of its time: the dev world wasn’t ready to go to that much extra effort to maximially lock down each function in each executable. So practically nobody used it and it fell by the wayside by .Net 4.0.

Skip to main content