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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Sun, 15 Mar 2015 16:11:57 +0100
From: "Stefan Kanthak" <>
To: <>
Cc: <>
Subject: 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):

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
    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

    JFTR: after setting this NTFS ACE (as well as activating SAFER
          alias "software restriction policies" or Windows' "parental
          controls"; see <>) 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?

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
    <> or
    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

Powered by blists - more mailing lists