Back to list
Defense in depth -- the Mozilla way: return and exit codes are dispensable
Mar 15 2015 03:11PM
Stefan Kanthak (stefan kanthak nexgo de)
since some time Mozilla Firefox and Thunderbird for Windows come with
a "maintenance service" (running privileged under the SYSTEM account):
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
#1. it exits with code 0, even when it fails to install the
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
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
#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 [³].
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
[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?
['] 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
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
[ reply ]
Copyright 2010, SecurityFocus