To be clear, the real security concern I have is the ability for the BA to
launch any executable elevated. The real security threat is if the engine
provides an API that says IBootstrapperEngine::LaunchConfigToolElevated(LPWSTR
sczFullPathToTool). Then a *non-elevated* process can insert a thread into the
non-elevated BA and call that engine API to launch any executable elevated.
That’s much badness.
Note: verifying a file is the correct file on disk won’t help if the file is
not placed in a secure location. The issue is that while you can lock the file
to verify it, you either have to unlock the file to let the Windows loader load
the file or open the file “share for delete” (because the Windows loader will
load the file with “share for delete” as well). If you do “share for delete”
then another process can move the file you are verifying out of the way and put
the bad executable it its place. This is why Burn does the whole “.unverified”
dance when caching elevated payloads, to ensure that files cannot be tampered
with between verification and placement in their final resting location.
The proposal to include an executable path (that probably has to be configured
with variables) in the Burn manifest is probably the necessary way to go. I
suppose we could allow several different well known identifiers that each point
at a path to be launched.
With this feature, the user does have to be conscious of the security
implications. They too must point to files that were installed to safe
locations (ProgramFilesFolder is safe). In all likelihood they already have a
variable that points to the root of that path (InstallFolder) and hopefully can
just tack on to that, like “[InstallFolder]my\path\to\configurationtool.exe”.
I also agree that I don’t like the design of using a “fake ExePackage” for this
scenario. That seems like overloading the “package” concept to be something
that isn’t a package.
I also don’t know how much we should bother adding executables to the Bundle
that aren’t just installed files. If the config tool is at all interesting, it
probably has dependencies and stuff that is shared with the larger application.
So, IMHO, it seems better to just tell people to install their config tool and
allow the Bundle+BA to launch it at the right time.
PS: Sorry I’ve been absent on these interesting design discussions. Being sick
sucked.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Sean Hall [mailto:[email protected]]
Sent: Friday, May 16, 2014 2:03 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIP3249 - Allow BA to Run Elevated Async Process
Through the Engine
Let's take a look at the security involved here. Can the BA currently execute
arbitrary processes with elevation with only one UAC prompt? Yes, there are
two ways. One way is to hack the .exe manifest to require administrator.
There's nothing we can do to prevent this. (Well, I guess the engine could
refuse to run in this scenario but would we really implement that?) The second
way is to put an EXE package in the chain that simply runs the executable
specified in its command-line arguments. We can't prevent this either without
crippling EXE packages.
I think we already agree that there are legitimate use cases for a Bundle to
launch an executable elevated without a UAC prompt. Neither of the current
ways are secure. Running the BA elevated is asking for trouble. When you
include an EXE package in the chain that will run anything you tell it, that
means that compromising the BA gives an attacker the ability to run elevated
code, which means game over. The question is what's the best way for the
Bundle to securely run an elevated process after calling Apply?
I don't like the suggestion to include an EXE package in the chain that is hard
coded to launch the "real" .exe and make it easier to execute it outside of
Apply. It's a slippery slope to the EXE package above that will run anything.
It's a "fake" package: it's not installing anything. I think it's unnecessary
and undesirable to separate the logic of which .exe to run from the BA.
Ideally, we would require that the elevated process was installed onto the
system from a package in the chain. I don't think that's possible. For
example, let's say the Bundle installs a third party product which is deployed
through an EXE package and the Bundle wants to launch an .exe that's installed
by that EXE package. Henning mentioned that he's using an .exe to work around
IIS's decision to require admin privileges to read the IIS config, another
reason not to fixate on the idea of requiring that the target .exe comes from a
package in the chain. The more barriers that we put in front of this new
feature, the more we push the Bundle to the two insecure ways described in the
beginning. This is why I proposed to make the Bundle register the .exe files
that it wants to run at compile time. The bundle can run any .exe on the
machine (as long as it registered it at compile time), because that's what it
can do already. This way, the engine can verify that the target .exe is
exactly the same as it was at compile time, making it much more secure.
This feature was opened more than a year before Burn was released. Please help
me get this designed in time to get into 3.9 (since it sounds like this is the
last opportunity to get it into 3.x).
On Tue, May 13, 2014 at 11:44 AM, Sean Hall
<[email protected]<mailto:[email protected]>> wrote:
My problem with requiring that .exe is somewhere in the chain is how you would
enforce that. For example, what if your Bundle A has Bundle B as an EXE
package, and you want to run an .exe inside an MSI that's in Bundle B?
On Mon, May 12, 2014 at 10:10 PM, Bob Arnson
<[email protected]<mailto:[email protected]>> wrote:
The use case is to run a config tool (that requires elevation) without leaving
the bundle running in the background. You can do that today with a simple .exe
that launches the config tool and exits. The goal of the feature request is to
make that easier. I'm concerned about putting the BA in charge of it, because
of the potential for abuse and the additional effort required.
That said, I can see that (1) the feature might need more flexibility than you
can get from just bundle authoring and (2) I'm usually in favor of the approach
you're suggesting (adding engine primitives the BA can use).
What if the focus is on an executable installed elsewhere in the chain? (i.e.,
no separate payloads, only a component GUID/file id from an installed package)
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
WiX-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs
