Hi @ll, since some time Mozilla Firefox and Thunderbird for Windows come with a "maintenance service" (running privileged under the SYSTEM account): <https://support.mozilla.org/en-US/kb/what-mozilla-maintenance-service> The maintenanceservice_installer.exe (which is extracted into the resp. installation directory) is executed during the end of the Firefox/Thunderbird installation when the user has not deselected the "[x] Install maintenance service" option ... and has quite some deficiencies: #1. it exits with code 0, even when it fails to install the maintenance service. To trigger such a failure create an (empty) file "%ProgramFiles%\Mozilla Maintenance Service". #2. the main installers ['][²] don't check the return code of the call used to start the maintenanceservice_installer.exe and don't inform the user who started the installation about this failure. Apparently Mozilla's developers never learnt the 101 of computer programming: ALWAYS check return and exit codes! To trigger this failure add the NTFS ACE "(D;OIIO;WP;;;WD)" meaning "Deny execution of files for everyone, inheritable to all files in all subdirectories" to your %USERPROFILE% and perform a user-defined installation to the custom installation directory "%USERPRPROFILE\Desktop\Mozilla". JFTR: after setting this NTFS ACE (as well as activating SAFER alias "software restriction policies" or Windows' "parental controls"; see <http://mechbgon.com/srp/>) all methods Mozilla uses to update their "products" fail: Mozilla "products" download an executable ['][²] into their profiles but don't check whether execution is allowed there, nor do they check the return code of the call used to start this executable! #3. it ignores a user-defined custom installation directory, but uses the hardcoded "%ProgramFiles%\Mozilla Maintenance Service". [Mozilla] "That is intentional since the service runs as the system and could be exploited." The BOFH creates a junction MkLink /J "%ProgramFiles%\Mozilla Maintenance Service" "%USERPROFILE%\Desktop" and runs the installer [³]. OUCH! The files created on the desktop are exploitable: they inherited the NTFS DACL of the parent directory giving full access to the user. JFTR: what's the difference of a user-defined custom installation directory via the corresponding installer option and the redirection via reparse point? The installer ignores the first, why not ignore the latter too? [Mozilla] "The maintenance service is a shared component of Firefox and Thunderbird." According to the 20+ years old "Designed for Windows" guidelines! shared components go to "%CommonProgramFiles%\<vendor>\<component>". JFTR: are you kidding? (why) are Gecko, NSS, XUL, ICU etc. NO shared components? stay tuned Stefan Kanthak ['] Windows SetupAPI exists since 20 years now and doesnt need any 3rd party binaries/executables: just write a .INF and package it with the files to install into a .CAB, then run the .INF via RunDll32.Exe AdvPack.Dll,LaunchINFSectionEx *.INF,,*.CAB,... [²] the Microsoft (now: Windows) installer exists since 15 years and was a Windows component before Mozilla started Phoenix^W Firefox. It too doesnt need any 3rd party executables. JFTR: would you dare to distribute software for a UNIX/Linux system which does not use the native package manager of the target system? [³] quite some script kiddies have the bad habit to move "%ProgramFiles%" away from "%SystemDrive%", despite <http://support.microsoft.com/kb/949977> or <http://support.microsoft.com/kb/2876597>: they create a junction or symlink from "%ProgramFiles%" to some other location but typically forget to set an appropriate NTFS DACL on the target to protect the files installed there from tampering/exploitation.
