since some time Mozilla Firefox and Thunderbird for Windows come with
a "maintenance service" (running privileged under the SYSTEM account):
<https://support.mozilla.org/
The maintenanceservice_installer.
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.
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\
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>
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/
<http://support.microsoft.com/
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.
Komentarų nėra:
Rašyti komentarą