Bugzilla

bug 1481907 comment #19

The linked patch does not seem to prevent directory junctions, the following PowerShell commands from the original report still create the update.status file in C:\Windows\System32:
New-Item -Type Junction -Force -Path C:\Temp\updates\0 -Value C:\Windows\System32
(Get-Service MozillaMaintenance).Start(@("MozillaMaintenance", "software-update", "updater.exe", "C:\Temp\updates\0", "C:\X", "C:\X"))

Tested with an install of https://archive.mozilla.org/pub/firefox/nightly/2018/08/2018-08-16-10-00-35-mozilla-central/firefox-63.0a1.en-US.win32.installer.exe on Windows 1703 x64.

To back the point I was trying to make in comment #11, please find attached a new PoC that works with this version, and demonstrates the use of OpLock to place object manager symbolic links after the initial checks and the temporary file creation, but before the file is moved.

(Note: the PoC expects the standard install path "C:\Program Files (x86)\Firefox Nightly", or the script can be adjusted accordingly.)

As for a full fix suggestion, it would be safer IMHO to change the location of the status file (e.g. to C:\Program Files\Mozilla Maintenance Service\status\) when it's generated by the service/updater, because it directly tackles the root cause / risky behaviour (manipulating user-controlable resources from a privileged process) instead of trying to address individual exploitation techniques (junctions/symlinks) which requires checking for all possible bypasses and corner cases.

From bug 1481907 comment #19

The linked patch does not seem to prevent directory junctions, the following PowerShell commands from the original report still create the update.status file in C:\Windows\System32:
New-Item -Type Junction -Force -Path C:\Temp\updates\0 -Value C:\Windows\System32
(Get-Service MozillaMaintenance).Start(@("MozillaMaintenance", "software-update", "updater.exe", "C:\Temp\updates\0", "C:\X", "C:\X"))

Tested with an install of https://archive.mozilla.org/pub/firefox/nightly/2018/08/2018-08-16-10-00-35-mozilla-central/firefox-63.0a1.en-US.win32.installer.exe on Windows 1703 x64.

To back the point I was trying to make in comment #11, please find attached a new PoC that works with this version, and demonstrates the use of OpLock to place object manager symbolic links after the initial checks and the temporary file creation, but before the file is moved.

(Note: the PoC expects the standard install path "C:\Program Files (x86)\Firefox Nightly", or the script can be adjusted accordingly.)

As for a full fix suggestion, it would be safer IMHO to change the location of the status file (e.g. to C:\Program Files\Mozilla Maintenance Service\status\) when it's generated by the service/updater, because it directly tackles the root cause / risky behaviour (manipulating user-controlable resources from a privileged process) instead of trying to address individual exploitation techniques (junctions/symlinks) which requires checking for all possible bypasses and corner cases.