full-disclosure - [FD] Defense in depth -- the Mozilla way: return and exit codes are dispensable

Open Source and information security mailing list archives

Date: Sun, 15 Mar 2015 16:11:57 +0100
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <bugtraq@...urityfocus.com>
Cc: fulldisclosure@...lists.org
Subject: [FD] Defense in depth -- the Mozilla way: return and exit codes are
	dispensable

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.

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives