Dubious security vulnerability: A program that adds a user to the Administrators group in the usual way

A security vulnerability report indicated that Windows was vulnerable to having a user added to the Administrators group. The finder attached a program demonstrating the issue. (To make things more exciting, they characterized the program as "malicious" and the person running it as an "attacker".)

The finder didn't include source code, but the program was small enough that it could be reverse-compiled without too much difficulty. The program employs the usual mechanisms for adding a user to the Administrators group. Nothing particularly fancy. Just calling documented functions in documented ways to accomplish the documented effect. When you run the program as a standard user, it fails with Access denied, as expected. Only if you run it as an administrator does it succeed in adding a user to the Administrators group.

Which is as things should be.

There didn't appear to be anything unusual going on here. No security boundary was crossed. Nothing suspicious happened.

The finder explained that this program, when run elevated, adds a user to the Administrators group, and no anti-malware program flagged it as suspicious.

Well yeah, because it's not suspicious. It does something perfectly legitimate, via perfectly legitimate means, and it doesn't attempt to subvert any security measures. Indeed, this is the sort of quick little program that you might see in a system administrator's toolbox.

It's expected that a program which does nothing suspicious is not flagged as suspicious.

Bonus reading: The Ten Immutable Laws of Security (Version 2.0), specifically law #1: If a bad guy can persuade you to run his program on your computer, it's not solely your computer anymore.

Comments (25)

  1. Brian_EE says:

    I bet if you write a program that creates a file, and you run it as an administrator, then you can create a file *anywhere* in the file system. Sounds like a security hole to me.

    1. thedarkfreak says:

      Is this a jab at the recent X11 vulnerability?

      1. Brian_EE says:

        No. It’s just an obvious analog of the scenario in Raymond’s article.

  2. Recently, I’ve been getting this kind of stuff more. I can tell where these people are coming from: The mobile world, where the #1 law does not apply. In Android and iOS the equivalent of such a thing would be a security vulnerability.

    1. No, it does apply, which is exactly why they spend so much effort on sandboxing. (Also, aside from the certainly of explorable bugs in any sandbox, you have to give at least SOME capabilities if you intend to have any slightly useful programs at all)

      1. I understand your point. But let’s not get sidetracked by fine distinctions; these guys report these things to me because they come from a platform where the philosophy is “an app CANNOT do with is not necessary for an app to do”. In Windows, the philosophy is “an app SHOULD NOT be granted privileges to do what is not necessary for an app to do.” Hence, a bad guy in Windows needs to persuade the end-user for privileges; in iPhone it is of no use. In Windows you need security updates and antivirus; on iPhone you only need security updates.

        1. Apps can ask for privileges even on iPhone. E.g. access your GPS, microphone, calendar. If the app asks for microphone permission and you grant it, then the app can do something bad with its privileges (e.g., spy on you whenever you use the app). In a sense the antivirus software is the App Store itself. So yes, iPhones have anti-virus software. It’s running in the cloud.

          1. I’d point out that you are distorting reality and confusing MAC with DAC at the same time, but let’s assume you are right for moment. What’s your point?

          2. “If you give an app permission to do scary things, it might do scary things.”

          3. That’s true. I actually assumed this is something all of us have long accepted.

            I was just merely pointing out that the computing ecosystem is changing. Scary things that once were okay are no longer okay. And the person who gets blamed for it is now a different person.

    2. IanBoyd says:

      > In Android and iOS the equivalent of such a thing would be a security vulnerability.

      Rule#1 does apply to Apple and Android. If i run my application on the phone as root: it is no longer solely my phone anymore.

      1. Yuri Khan says:

        No. If you manage to run your application as root, then it’s not solely the manufacturer’s phone anymore. It becomes your phone (a little bit).

    3. I suspect they just didn’t think of adding administrators as something to be done programmatically at all.

      1. Indeed.

        That reminds me: In the mobile platform, the utility software is almost nonexistent. Almost everything is application software; hence the term “app”. But your comment is correct, regardless of this observation.

      2. Better not tell them about NET LOCALGROUP groupname name /ADD then…

        (This account is using the email address I was using before it became necessary to log in, but I guess I must have another account somewhere thus the unusual display name…)

  3. I wonder what they think -should- happen, if they even thought it through that far…

    1. If my experience with the mobile device platform is any indication, I’d say they expect one and only one official component in charge of security settings; one that is digitally signed with an exclusive certificate, tamper-proof, and invoked only by Local Security Authority Subsystem (LSASS.exe). Actually, I think Microsoft once proposed something similar in Next-Generation Secure Computing Base, although you probably shouldn’t trust my memory on this.

      1. Gee Law says:

        *Cough* The reporter would then require that subsystem to ask the user every time whether such operation is allowed and the UI must be tamper-proof (nobody can simulate the user). Otherwise, the API could simply ask LSASS for assistance.

        By the way, it seems that one can no longer post comments as a guest?

        1. You are making it both easy and difficult at the same time. No. None of that. I’m afraid if you already don’t know what a walled garden is, it would take me hours to explain it to you. But I tell you this: Not only there isn’t any “asking user every time”, there isn’t any “every time” to begin with. There is no debugging or hooking into other apps either.

          1. Paradice says:

            You’re continually switching platforms between mobile and Windows in order to try and claim everyone else is wrong about everything. Case in point: in your top-level comment, you talk about a world where LSASS.exe manages security settings (clearly this world would be Windows, as LSASS.exe is a Windows subsystem), but when someone replies to say, yeah that wouldn’t help anything due to APIs, suddenly you switch worlds to mobile and claim they’re wrong because that functionality doesn’t exist and you don’t have time to explain.

            Please check the blog you’re on and assume people are talking about Windows.

          2. Oh, my! Someone doesn’t know what comparison and contrast means.

            This blog is for grownups. Please finish elementary school before commenting.

          3. Gee Law says:

            The “asking user every time” is done by the official component (LSASS), not the app, if you read carefully. Look at Windows Runtime. Every time an app wants to pin a tile to Start, Windows intercepts the request and asks the user (somehow, on behalf of the app) for permission before proceeding.

          4. You’ve officially crossed the borders of patent nonsense. So, I am un-following this conversation. Consider this a courtesy notice.

  4. IanBoyd says:

    I Discretionary Access Control List, that I do not have the discretion to change, is the moral equivalent of a Mandatory Access Control List (Because it’s the Owner’s discretion – and they’re not the owner).

    If you don’t want users of the phone to be able to do bad things, then don’t grant them that permission.

    1. RSmead says:

      I think you have the terms backwards. DAC allows the owner of the object to set/change permissions on the object. MAC is controlled by the Operating System (not the owner). With MAC, the owner of an object may not be able to set/change permissions on the object.

Skip to main content