This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Accept
Reject
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
hype261
Level 3
‎Jul 16, 2015 02:10 PM

MS15-074: Vulnerability in Windows Installer service

We have a basic MSI project built with Installshield 2012. Upon trying to install we are getting the following error message.

Error 27555.Error attempting to apply permissions to object 'CURRENT_USER\Software\Settings'. System error: The system cannot find the file specified. (2)

We have narrowed the error to happening when the MS15-074 is installed on the machine. https://support.microsoft.com/en-us/kb/3072630

We have seen the issue on both Windows 7 and 8.

Does Installshield have a work around for the issue or a plan to fix it?

James
Labels (1)
Labels
0 Kudos
(4) Replies
afogiel
Level 3
‎Jul 16, 2015 02:57 PM

I am having the exact same issue linked to the same windows update.
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran
‎Jul 16, 2015 03:25 PM

It would appear that this update closes a rather large security hole that gives things like custom actions running in SYSTEM context access to the current user registry of the user that launched the installation. The permissions support runs in system context to be able to set permissions on machine wide resources (HKLM, Programs Files subfolders, etc.). Now that this hole is closed, the custom action does not have access to user specific locations (HKCU), therefore the error is accurate.

As a possible workaround you could change the In-Script Execution setting of the ISLockPermissionsInstall action to "Deferred Execution". However, if you are attempting to set permissions on any machine wide resources, the action will fail due to insufficient privileges.

In general, setting permissions on resources that a user has access to seems a bit counter intuitive. Can you provide any information on what use case requires allowing access to a user's data that they wouldn't already have access to?
0 Kudos
afogiel
Level 3
‎Jul 17, 2015 05:21 PM

I was able to get things working.
For some reason some of our registry entries had permissions set (I inherited this project, not sure of the history)
To fix, I installed our software with logging on. The log pointed to some items while setting the ISLockPermissions.
I then went to the Direct Editor> ISLockPermissions and looked for the items noted in the log. Once found I noted the permission value in the Permission column and looked for all values in the LockObject column that had the same Permission value. I then went to the Direct Editor>Registry and found the item in the Registry column that matched the LockObject. This then told me the key. Then I went to the System Configuration> Registry and navigated to the keys in the Destination computer section and right clicked on any keys with the lock symbol. I then removed the manual permissions. Everything worked fine afterwards.
Thanks,
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran
‎Aug 04, 2015 02:05 PM

We have released a hot fix that should resolve this issue. Officially it's only available for InstallShield 2015, and thus is only supported there, but in practice the DLL in question can be substituted into most earlier versions of InstallShield that have the same DLL.
0 Kudos