Application restart #1

I'm a pretty carefree guy, experimenting with all kinds of weird applications from dubious sources. The domain and the network is pretty well secured, but my virtual lab computers are like people in the old west; unregulated and easily killed off if they become to unwieldy.

Still, when something suspicious happens I wan't to know why, because of course I wan't.

Some time ago the following dialog suddenly popped up when I logged in to my work computer;

What? No, I would not like to allow Regedit.exe to make changes to my device. Searching through the startup locations with Sysinternals excellent Autoruns didn't reveal anything and concurrent logons did not start Regedit.exe. Probably, it was launched by the RunOnce registry key. Difficult to troubleshoot when the traces are gone.

Weeks later it appeared again! What program is causing this? Why does it want to start Regedit.exe? How do I find out when it only happens once every month or so? None of my coworkers have had the same experience and even though I have a black belt in Google-fu searching the web was hard, only resulting in how to use Regedit. I know this already!

Then it appeared on my clean virtual lab computer, not in any way related to my domain joined work computer. Luckily I had just done a snapshot of it and Regedit.exe wanted to start every time I restored. Finally some progress! Using my incredible skills I finally found the culprit using Procmon, the greatest tool of all time;

Indeed it was a RunOnce registry key and the name of it, "Application Restart #1" is the clue. Since some version ago (who knows which, versioning sucks) Windows restarts select applications that were running when the computer was shut down. Not only during forced restarts from updates, but when you manually shut down the computer. Apparently I am not very good at closing programs before shutting the PC down.

Not all programs are restarted and how Windows decides this is still a mystery to me. It's a badly documented feature with a badly thought through workaround. This is what Microsoft Answers says about it.

Regardless, Regedit.exe, or any program requiring elevation, should not be started automatically!

Or is it requireing? Require-ing? Reqiruing? My Google-fu might not be as advanced as I thought.

Installation failed because reasons

Sometimes installations fail. Often, the reason for failure is logical and easily found in a log file, sometimes you just get an 1603 with no indication whatsoever what went wrong.

And sometimes the install fails by design. A retarded design.

Solid Works 2016 installs Microsoft SQL Server 2008, Microsoft SQL Server 2012 and Microsoft SQL Server 2014.

I think most people see a probable cause for disaster right there. But surprisingly it usually works.

Unless your organisation has done the rare but sensible and rational thing and set a password policy:

As it happens, Microsoft SQL Server adheres to the group policy dictating the password policy for the domain.

There are workarounds found when googleing, but they either require disabling the password policy or modifying the way the database is created. Neither of these methods might be possible for an unattended install from a third party vendor.

Mostly because I don't feel like talking to the vendor, nor to my collegues managing the domain.

So here is how you install an SQL instance without supervision, without modifying the install and without modifying the domain:


; Removing password-requirements with secedit:

RunWait('secedit.exe /export /cfg "' & @TempDir & '\sectmporg.cfg" /quiet',"",@SW_HIDE)

FileCopy(@TempDir & '\sectmporg.cfg', @TempDir & '\sectmpcpy.cfg',1)
IniWrite(@TempDir & '\sectmpcpy.cfg',"System Access","MinimumPasswordLength","0")
IniWrite(@TempDir & '\sectmpcpy.cfg',"System Access","PasswordComplexity","0")

RunWait('secedit.exe /configure /db secedit.sdb /cfg "' & @TempDir & '\sectmpcpy.cfg" /quiet',"",@SW_HIDE)
RunWait("gpupdate.exe","",@SW_HIDE)

; **********************
;
; THE INSTALL GOES HERE!
;
; **********************

; Restoring password-requirements:

RunWait('secedit.exe /configure /db secedit.sdb /cfg "' & @TempDir & '\sectmporg.cfg" /quiet',"",@SW_HIDE)
RunWait("gpupdate.exe","",@SW_HIDE)

Code is AutoIt, but I'm sure you figure it out in any language.

The requested execution level require administrator!

Executables that make changes to the system requires higher privilegies. Users will normally be asked to give admin credentials, and even members of the local administrator group will be asked for consent before elevating to a higher level of privilegies.

This is great!

However, some applikations require administrative privilegies even though they do NOT make or need to make any system changes.

That is retarded!

It actually lowers the overall security because if you don't know how to handle it users will have to be given, or some users might even have the balls to demand, administration rights.

An hilariously ironic example is InstallShield, one of the most common msi-editors. I can imagine some tools like the Response Transform Wizard might need admin rights, but otherwise there is no need. Another trouble maker is mmc.exe even though the snap-in you wan't does not. This makes it difficult to save a folder view and give to users to administer groups, for instance. Add to this various third party programs that only need to run as admin because the developer is lazy. Nothing wrong with laziness, unless it gives ME more work.

A program might ask for elevation for various reasons, where the correct and common reason is requestedExecutionLevel in the programs manifest is set to Level=requireAdministrator.

There are other reasons, some of which you can force. You can make a shortcut where you specify Advanced - Run As Administrator. This setting is in the lnk-file and will remain if copied. You can set the executable compability mode to Run As Administrator. This is stored in HKCU or HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers and includes the full path. Therefor it will break if the file is renamed or copied.

If the file lacks a manifest you can just rename the file as setup.exe and Windows will force consent on you. That didn't come out right.

The other way around, running a program that requires admin rights without admin rights, is slightly more convoluted.

There are a couple of ways to do it, where the easiest way is to set the environment variable __COMPAT_LAYER = RunAsInvoker. Note the initial double underscore.

Using a script or by coding it is trivial to make a launcher. In AutoIt:

#NoTrayIcon
#AutoIt3Wrapper_Icon=Some icon preferably same icon as the program this is supposed to launch.ico

$RunAsInvoker_command = 'set __COMPAT_LAYER=RunAsInvoker'

Run(@ComSpec & ' /c ' & $RunAsInvoker_command & ' & start "" /D "' & @ScriptDir & '" ' & $cmdlineraw, @ScriptDir, @SW_HIDE)

Another way to more permanently change the application is to edit its manifest and simply replace level="requireAdministrator" with level="asInvoker" using your preferred manifest editor that works. They don't always work. If the file is signed, not even a hex-editor works.

That is the easy part. Then you need to make sure the program actually works running with only user rights. For this task, you'll need Procmon, the greatest tool ever made. I said that already.

UAC and Admin Approval Mode can be turned off in various ways. DO NOT DO THIS. On the contrary, if it was up to me (it isn't) I would enable Prompt for credentials for ConsentPromptBehaviorAdmin, so that even admins have to enter a password before elevating.

The system corrupts

An update is due again, as it always is. This time it is the digital signage program Dise. Previously deployed version is 1.6 and when I try on my lab computer both uninstalling this version and installing the new one works beautiful with just a /S switch. A good five minutes of work that I can charge $500 for. I can lean back, take a sip of coffee and browse the internet for "news".

I deploy the application but curiously I don't get any statistics in System Center, nothing seems to happen. Suddenly I hear screaming. The staff at the call center seem distressed. I find that after a restart the computers don't boot anymore, all thats left of our entire environment is this:

It turns out that uninstalling Dise 1.6 with the SYSTEM accound wipes the boot sector for no reason. The computer is now a brick.

Fortunately the above scenario didn't play out, because I actually spent more than five minutes and caught this before deploying.

Many installs behave differently when installing as SYSTEM as opposed to an ordinary administrator account. Every install MUST be tested with this account before being deployed sitewide. I recommend at least having a CMD shortcut on the desktop that uses psexec.exe to launch as SYSTEM.

Some old issetup.dll, a component in Installshield built setups, had a bug that launched the install as the currently logged on user, which of course failed with tons of access denied. Some installs deploy settings only to the running users profile, which in this case is C:\Windows\System32\config\systemprofile or might fail to write user settings altogether. Some installs get confused for other reasons when the environment is different from a standard user.

Few installs are as awful as Dise, but there are more ways to completely destroy a computer. More about that in a later post.

Firewall rulez!

If your program needs to add firewall rules, your installer should provide the option.

DO NOT rely on the person installing your application to know what needs to be done.

DO NOT ignore it and let Windows pop up the Security Alert, this one:

Not the user nor the administrator knows or cares what firewall rules your application requires. The user probably, preferably, don't even have permission to allow access.

A lazy application manager, one like me for instance, might even consider turning off the local firewall altogether if it get complicated enough.

A prime example is the Flexera LMFlex, a pretty common manager for floating licenses used by a wide range of applications such as Autodesk AutoCAD, Pitney Bowes MapInfo and Safe Software FME.

LMFlex does not configure the rules for you, it requires a range of ports to be open, uses random ports as default, and every dependent application is managed by a separate LMgrd.exe process.

I could write an entire post about LMFlex, and probably will, but for now I'll just sigh and turn off the firewall.

I don't have time for this, I have porn to discover.

Everybody writes to program files!

Now and then I am given a program to deploy that doesn't work. Just kidding, I get such programs all the time.

Actually, I am quite surprised when something works straight out of the box. I have a hard time fathoming how people without my amazing skills get anything to work on their computer at all.

Well, one of the reasons is that most people are using their home computers with an account that has administrative privilegies. Some people even turn off UAC to get rid of some annoying consent-dialogs.

In a corporate environment, this is a very very bad idea. Ask anyone working at an Iranian nuclear facility. (Full disclosure: I don't have a clue about the infrastructure at any nuclear facility, Iranian or otherwise).

A very common problem I face is programs that require write-permissions in its program folder. Older programs, binaries that does not include a manifest with a requested execution level, have their writes redirected by modern Windows to the users profile, to %localappdata%\VirtualStore. This, however, only works with UAC enabled.

But so far so good, these old crap program works somewhat, thanks to the pile of workarounds that is Windows.

New crap programs does not.

They are getting less and less common but I still get them.

Why not just give users write-permissions, you may ask. Because they don't deserve it I may answer, but that would be wrong. No, it's because it's a major security concern.

Having write access to program or system folders is different than having write access anywhere else, because a malicious program could replace files the user launches, and unlike executables saved on the desktop or the download folder, users don't have a clue what they are launching when starting an already installed program.

Also, it makes further security restrictions like AppLocker a pain to administer. Imagine you manage a restricted environment where users are only allowed to start prior approved programs, that you have tried, tested and deployed. The users are not local administrators, so they can't install anything, and you wan't to configure AppLocker so that they can't even start binaries but the programs you deploy.

Pretty much the only AppLocker rules you would need then are the default rules, like this one:

While this isn't entirely true if you use stuff like Click-to-Run, ClickOnce (stupid names, by the way) or AppV, it covers most of what you need.

However, if only ONE folder that fits within your Allow-rules are writable by users, it all falls apart! Any user or a malicious program can then launch whatever they want, and the added security AppLocker is supposed to provide is to no avail.

Microsoft has a tool, Sysinternals AccessChk that will help you after the fact, but you will need to be the person to avoid installing programs that changes permissions on folders.

If you absolutely MUST, install the program elsewhere. Not in the root directory, but maybe in C:\ProgramData or make a new folder called C:\Program Files Secure.

Or why not C:\Program Files That Suck!

Then you'll need to add new AppLocker rules separately. But it works.

Your updater sucks!

You've released a new version of your awesome program, and you wan't everyone to upgrade! Unfortunately you are a Windows developer so you have to rely on your own wit and skill for automatic upgrades. Fortunately you have billions of investor dollars to spend, because you work at Spotify or whatever.

So you have made a mechanism on the client that checks for updates now and then and downloads them automatically. The massive amount of money you spent didn't make you God though:

You need to ASK before you FUCK. It's called consent.exe.

You didn't consider that your program might be located somewhere on the computer where the user doesn't have permission to write. You didn't consider that because billions of dollars still can't make you think.

There are uncountable number of solutions to this problem, some of which are:

• Have settings to disable updates and let the admins (me) manage it.
• Check for write permissions and only upgrade if you know you're able to.
• Write a service or scheduled task, like Google does. A service means a service, not just a stupid user process. Lika Java does.
• DON'T update automatically! This is the best option.

Humorously you might totally break your program if you can't even start it without upgrading once it downloaded a new version, unless you edit the registry or some stupid xml-file.

Breaking your own program, is that what you want? Is it?