BugTraq
Defense in depth -- the Mozilla way: return and exit codes are dispensable Mar 15 2015 03:11PM
Stefan Kanthak (stefan kanthak nexgo de)
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.

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus