Closed Bug 1127481 (CVE-2015-2720) Opened 5 years ago Closed 5 years ago

Run updater.exe from the application directory when not using the service for an update

Categories

(Toolkit :: Application Update, defect)

x86
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla40
Tracking Status
firefox37 --- wontfix
firefox38 --- verified
firefox38.0.5 --- verified
firefox39 --- verified
firefox40 + verified
firefox-esr31 --- wontfix
firefox-esr38 --- verified
b2g-v2.0 --- unaffected
b2g-v2.0M --- unaffected
b2g-v2.1 --- unaffected
b2g-v2.1S --- unaffected
b2g-v2.2 --- unaffected
b2g-master --- unaffected

People

(Reporter: robert.strong.bugs, Assigned: robert.strong.bugs)

References

Details

(Keywords: csectype-priv-escalation, qawanted, sec-high, Whiteboard: [adv-main38+])

Attachments

(3 files, 6 obsolete files)

16.94 KB, patch
robert.strong.bugs
: review+
abillings
: sec-approval+
Details | Diff | Splinter Review
16.42 KB, patch
robert.strong.bugs
: review+
Details | Diff | Splinter Review
16.45 KB, patch
robert.strong.bugs
: review+
Details | Diff | Splinter Review
+++ This bug was initially created as a clone of Bug #945192 +++

From bug 945192 comment #250
"The patch as it stands I believe covers loading all dll's placed in the directory alongside the updater.exe except for the following cases using Firefox x86:
Windows Vista x86 and x64 - apphelp.dll
Windows XP x64 - wow64log.dll

Firefox x64 is fixed.

To fix this for the two cases above the directory where the updater.exe would need to be secured which we can't guarantee with our current policy of allowing users to install into a directory of their own choosing and the fact that the user can change the permissions of the directory.

To address these two cases I am planning on running the updater from the application directory when not using the service. This would require not staging updates when not using the service which I don't see as a major issue since the vast majority of users use the maintenance service with less than 5% not using it according to telemetry. The visible affect of not using staging is it taking longer to apply an update during startup.

Making app update use the updater.exe from the application directory will take time to implement and I am unsure of the amount of time it will take. Since the affected systems after the current patch lands are a very small subset of the Windows install base we need to decide whether or not we should hold off on landing the current patch until this additional work is completed."
Remaining dll loads that will be fixed by this bug.

Win XP x86 - Firefox x86
updates\0\LPK.DLL - loads before preloading - elevated since there is no UAC
updates\0\USP10.dll - loads before preloading - elevated since there is no UAC
updates\0\updater.exe.Local\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll - elevated since there is no UAC

Win XP x64 - Firefox x86
updates\0\wow64log.dll - loads before preloading - elevated since there is no UAC
updates\0\updater.exe.Local\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.3959_x-ww_5FA17F4E\comctl32.dll - elevated since there is no UAC

Win Vista x86 - Firefox x86
updates\0\apphelp.dll - loads before preloading - unelevated and elevated
updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18005_none_5cb72f96088b0de0\comctl32.dll - unelevated and elevated

Win Vista x64 - Firefox x86
updates\0\apphelp.dll - loads before preloading - unelevated and elevated
updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18005_none_5cb72f96088b0de0\comctl32.dll - unelevated and elevated

Win 7 x86 - Firefox x86
updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll - only unelevated

Win 7 x64 - Firefox x86
updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll - only unelevated

Win 7 x64 - Firefox x64
updates\0\updater.exe.Local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_fa396087175ac9ac\comctl32.dll - only unelevated
Blocks: 1129209
QA Contact: kjozwiak
Assignee: nobody → robert.strong.bugs
Status: NEW → ASSIGNED
Duplicate of this bug: 708378
Attached patch patch in progress (obsolete) — Splinter Review
I'd like to get feedback on this approach. Note: the nsUpdateDriver.cpp code will be refactored in bug 1156046 and I'd like to keep the changes to it simple in this bug so it can be easily uplifted.
Attachment #8597006 - Flags: feedback?(netzen)
I landed the code and a couple of fixes on oak and updating is working as expected so far. Yay!
Attached patch patch in progress (obsolete) — Splinter Review
Includes a couple of fixes
Attachment #8597006 - Attachment is obsolete: true
Attachment #8597006 - Flags: feedback?(netzen)
Attachment #8597392 - Flags: feedback?(netzen)
Comment on attachment 8597392 [details] [diff] [review]
patch in progress

Review of attachment 8597392 [details] [diff] [review]:
-----------------------------------------------------------------

neat :)

::: toolkit/mozapps/update/updater/updater.cpp
@@ +896,5 @@
> +      NS_tsnprintf(childPath, sizeof(childPath)/sizeof(childPath[0]),
> +                   NS_T("%s/%s"), path, entry->d_name);
> +      rv = remove_recursive_on_reboot(childPath, deleteDir);
> +      if (rv) {
> +// Log

// pls

@@ +901,5 @@
> +      }
> +    }
> +  }
> +
> +  NS_tclosedir(dir);

nit: Make sure dir is non null

::: toolkit/xre/nsUpdateDriver.cpp
@@ +414,5 @@
>                     nsIFile *appDir, int appArgc, char **appArgv)
>  {
>    nsresult rv;
>  
> +#ifndef XP_WIN

nit: Pls explain here why we don't do this on Windows.
Attachment #8597392 - Flags: feedback?(netzen) → feedback+
I've tested the different paths this can take and all is looking good. I'll clean up the patch and submit it for review soon.
Attached patch patch rev1 (obsolete) — Splinter Review
(In reply to Brian R. Bondy [:bbondy] from comment #6)
> ::: toolkit/mozapps/update/updater/updater.cpp
> @@ +896,5 @@
> > +      NS_tsnprintf(childPath, sizeof(childPath)/sizeof(childPath[0]),
> > +                   NS_T("%s/%s"), path, entry->d_name);
> > +      rv = remove_recursive_on_reboot(childPath, deleteDir);
> > +      if (rv) {
> > +// Log
> 
> // pls
Actually the error will already have been logged so I just added a comment explaining this.

> @@ +901,5 @@
> > +      }
> > +    }
> > +  }
> > +
> > +  NS_tclosedir(dir);
> 
> nit: Make sure dir is non null
There is already that dir is non null after it is opened.

> ::: toolkit/xre/nsUpdateDriver.cpp
> @@ +414,5 @@
> >                     nsIFile *appDir, int appArgc, char **appArgv)
> >  {
> >    nsresult rv;
> >  
> > +#ifndef XP_WIN
> 
> nit: Pls explain here why we don't do this on Windows.
Done
Attachment #8597392 - Attachment is obsolete: true
Attached patch patch rev1 (obsolete) — Splinter Review
Attachment #8598412 - Attachment is obsolete: true
Attached patch patch rev1 (obsolete) — Splinter Review
Attachment #8598414 - Attachment is obsolete: true
Attached patch patch rev1 (obsolete) — Splinter Review
Though with a little work it should be possible to merge remove_recursive_on_reboot with ensure_remove_recursive I don't want to do that in this bug since it would add risk to the patch and this patch will likely get uplifted.
Attachment #8598415 - Attachment is obsolete: true
Attachment #8598417 - Flags: review?(spohl.mozilla.bugs)
I verified the following scenarios work for both an install under program files and an install in a writable location using oak:

service and staging
service and no staging
no service and staging
service and staging with the directory in use
service and staging with a second instance of the application running
Comment on attachment 8598417 [details] [diff] [review]
patch rev1

Review of attachment 8598417 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM!

::: toolkit/mozapps/update/updater/updater.cpp
@@ +863,5 @@
> +    return rv;
> +  }
> +
> +  if (!S_ISDIR(sInfo.st_mode)) {
> +    NS_tchar tmpDeleteDir[MAXPATHLEN];

nit: Since we're dealing with a file here, maybe |tmpDeleteFile| is a better variable name?

@@ +865,5 @@
> +
> +  if (!S_ISDIR(sInfo.st_mode)) {
> +    NS_tchar tmpDeleteDir[MAXPATHLEN];
> +    GetTempFileNameW(deleteDir, L"rep", 0, tmpDeleteDir);
> +    NS_tremove(tmpDeleteDir);

nit: I think |rename_file| removes the destination file if it exists (and has extra logging in case of failure).

::: toolkit/xre/nsUpdateDriver.cpp
@@ +421,3 @@
>    // Steps:
>    //  - copy updater into updates/0/MozUpdater/bgupdate/ dir
>    //  - run updater with the correct arguments

nit: I wonder if these steps should be kept outside of the #ifndef, since running the updater with the correct arguments still applies to Windows. This is even more the case for the steps in |ApplyUpdates| later in this file. Maybe the step about copying the updater could be changed to say "on all platforms but Windows", or something like that?
Attachment #8598417 - Flags: review?(spohl.mozilla.bugs) → review+
(In reply to Stephen Pohl [:spohl] from comment #13)
> Comment on attachment 8598417 [details] [diff] [review]
> patch rev1
> 
> Review of attachment 8598417 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> LGTM!
> 
> ::: toolkit/mozapps/update/updater/updater.cpp
> @@ +863,5 @@
> > +    return rv;
> > +  }
> > +
> > +  if (!S_ISDIR(sInfo.st_mode)) {
> > +    NS_tchar tmpDeleteDir[MAXPATHLEN];
> 
> nit: Since we're dealing with a file here, maybe |tmpDeleteFile| is a better
> variable name?
Done

> @@ +865,5 @@
> > +
> > +  if (!S_ISDIR(sInfo.st_mode)) {
> > +    NS_tchar tmpDeleteDir[MAXPATHLEN];
> > +    GetTempFileNameW(deleteDir, L"rep", 0, tmpDeleteDir);
> > +    NS_tremove(tmpDeleteDir);
> 
> nit: I think |rename_file| removes the destination file if it exists (and
> has extra logging in case of failure).
I considered that and instead rely on the logging that follows this since that is all that is needed.

> ::: toolkit/xre/nsUpdateDriver.cpp
> @@ +421,3 @@
> >    // Steps:
> >    //  - copy updater into updates/0/MozUpdater/bgupdate/ dir
> >    //  - run updater with the correct arguments
> 
> nit: I wonder if these steps should be kept outside of the #ifndef, since
> running the updater with the correct arguments still applies to Windows.
> This is even more the case for the steps in |ApplyUpdates| later in this
> file. Maybe the step about copying the updater could be changed to say "on
> all platforms but Windows", or something like that?
Done
[Security approval request comment]
How easily could an exploit be constructed based on the patch? Not too easily and less easily than other patches I've landed to mitigate this bug.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? No

Which older supported branches are affected by this flaw? All

If not all supported branches, which bug introduced the flaw?

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? Not yet but it should be fairly simple to backport.

How likely is this patch to cause regressions; how much testing does it need? Manual testing leads me to believe that this won't cause regressions but I still want this on nightly for around a week before uplifting.
Attachment #8598417 - Attachment is obsolete: true
Attachment #8598828 - Flags: sec-approval?
Attachment #8598828 - Flags: review+
Attached patch aurora patchSplinter Review
only test changes for aurora
Attachment #8598861 - Flags: review+
Attached patch beta patchSplinter Review
test changes and context difference in updater.cpp
Attachment #8598863 - Flags: review+
Tests pass locally on aurora and beta. I'll provide steps for verification next
To verify this bug you should be able to just use procmon and verify that the updater.exe process doesn't try to load any dll's from the updates directory.
Process Name updater.exe and the path to your Windows profile should be sufficient for a filter. Then just search for .dll
Comment on attachment 8598828 [details] [diff] [review]
patch for landing

sec-approval+. It will be nice to get this fixed.
Attachment #8598828 - Flags: sec-approval? → sec-approval+
Pushed to mozilla-inbound
https://hg.mozilla.org/integration/mozilla-inbound/rev/34da940cd412

I'll request branch approvals after this has baked.
Target Milestone: --- → mozilla40
I will be away from my computer until around 5/6. I don't expect any issues but if there are any please contact Stephen (:spohl) or Benjamin Smedberg during this time.
Sylvestre, how long can I let this bake on Nightly and still get it in for Firefox 38 so it makes it into ESR?
Flags: needinfo?(sledru)
Liz, perhaps you can answer the question in comment #25
Flags: needinfo?(lhenry)
Comment on attachment 8598861 [details] [diff] [review]
aurora patch

Approval Request Comment
[Feature/regressing bug #]: None
[User impact if declined]: They will still have this vulnerability
[Describe test coverage new/current, TreeHerder]: Landed on m-c, the tests exercise this code, and the update from Thursday to Friday used this code without any bug reports.
[Risks and why]: It would be nice to let this bake a little longer but there are no known issues at this time. 
[String/UUID change made/needed]: None
Attachment #8598861 - Flags: approval-mozilla-aurora?
Comment on attachment 8598863 [details] [diff] [review]
beta patch

Approval Request Comment
[Feature/regressing bug #]: None
[User impact if declined]: They will still have this vulnerability
[Describe test coverage new/current, TreeHerder]: Landed on m-c, the tests exercise this code, and the update from Thursday to Friday used this code without any bug reports.
[Risks and why]: It would be nice to let this bake a little longer but there are no known issues at this time. 
[String/UUID change made/needed]: None
Attachment #8598863 - Flags: approval-mozilla-beta?
(In reply to Robert Strong - out until 5/6 [:rstrong] (use needinfo to contact me) from comment #25)
> Sylvestre, how long can I let this bake on Nightly and still get it in for
> Firefox 38 so it makes it into ESR?
I was told over irc that it would need to land by Sunday.
Flags: needinfo?(sledru)
Flags: needinfo?(lhenry)
Attachment #8598861 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #8598863 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Ryan, could you land this for 38 and 38esr?
Flags: needinfo?(ryanvm)
(It'll merge to other 38 branches from there)
I'd prefer not landing this on esr31 but I'll create a patch if it is wanted.
Whiteboard: [adv-main38+]
Alias: CVE-2015-2720
Robert, is manual testing needed for this fix? If yes, can you provide us some detailed steps to verify it?
Flags: needinfo?(robert.strong.bugs)
* Reproduced the original issue using the following build:
** http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/02/2015-02-09-03-02-04-mozilla-central/

* Went through verification using the following build:
** http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015-05-01-03-02-05-mozilla-central/

For each of the OS's listed below, went through the following as well:

Scrubbing through procmon to see if DLL's are being loaded into "\updates\0\" or "\updates\0\updater.exe.Local"
* Older build: found the original DLL's listed above
* Build with fix: couldn't find the DLL's listed above

Win XP Pro SP3 x86 - PASSED
==================

* \updates\0\lpk.dll
** Older build: never appeared for me as an affected DLL, going through it either way as it appears in comment #1
** Build with fix: no cmd prompt spawned (ran through update twice)

* \updates\0\usp10.dll
** Older build: never appeared for me as an affected DLL, going through it either way as it appears in comment #1
** Build with fix: no cmd prompt spawned (ran through update twice)

* \updates\0\updater.exe.Local\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll
** Older build: couldn't reproduce the original issue
** Build with fix: no cmd prompt spawned (ran through update twice)

I also tried \updates\0\MozUpdater\bgupdate\updater.exe.Local\ without any luck reproducing the original issue

Win XP Pro SP2 x64: - PASSED
=================== 

* \updates\0\updater.exe.Local\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.5190_x-ww_B8C2A5B7\comctl32.dll
** Older build: spawned 1 cmd prompt (integrity level not available in XP)
** Build with fix: no cmd prompt spawned (ran through update twice)

Win Vista Ultimate SP2 x86 - PASSED
==========================

* \updates\0\apphelp.dll
** Older build: crashed the updater and spawns 1 medium integrity cmd prompt (fx doesn't update)
** Build with fix: no cmd prompt spawned and updated without crashes (ran through update twice)

* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll
** Older build: spawned 3 medium and 2 high integrity cmd prompts
** Build with fix: no cmd prompt spawned and updated without crashes (ran through update twice)

Win Vista Ultimate SP2 x64 - PASSED
==========================

* \updates\0\apphelp.dll
** Older build: crashed the updater and spawns 1 medium integrity cmd prompt (fx doesn't update)
** Build with fix: no cmd prompt spawned and updated without crashes (ran through update twice)

* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll
** Older build: spawned 3 medium and 2 high integrity cmd prompts
** Build with fix: no cmd prompt spawned (ran through update twice)

Win 7 Pro SP1 x86 - PASSED
=================

* \updates\A3710B8EBB50CD3\updates\0\version.DLL
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)

* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)

* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)

Win 7 Pro SP1 x64 - PASSED
=================

Using FX x86:

** \updates\EEFEA8717BC47F65\updates\0\version.DLL
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)

* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)

Using FX x64:

FX x64:
* \updates\A3710B8EBB50CD3\updates\0\version.DLL
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)

* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)

* \updates\0\updater.exe.Local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_fa396087175ac9ac\comctl32.dll
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)
Flags: needinfo?(robert.strong.bugs)
Kamil, do you think you could also do a quick check for this on ESR 38.0?
Flags: needinfo?(kjozwiak)
* Went through verification using the following build:
** http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015-05-02-00-40-03-mozilla-aurora/

Used the same method as comment # 38. Not adding as much detail as it's the same test, just a different channel.

Win XP Pro SP3 x86 - PASSED
==================

* \updates\0\lpk.dll
* \updates\0\usp10.dll
* \updates\0\updater.exe.Local\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll


Win XP Pro SP2 x64: - PASSED
=================== 

* \updates\0\updater.exe.Local\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.5190_x-ww_B8C2A5B7\comctl32.dll

Win Vista Ultimate SP2 x86 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll


Win Vista Ultimate SP2 x64 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll


Win 7 Pro SP1 x86 - PASSED
=================

* \updates\A3710B8EBB50CD3\updates\0\version.DLL
* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Win 7 Pro SP1 x64 - PASSED
=================

Using FX x86:

* \updates\EEFEA8717BC47F65\updates\0\version.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Using FX x64:

* \updates\A3710B8EBB50CD3\updates\0\version.DLL
* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
* \updates\0\updater.exe.Local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_fa396087175ac9ac\comctl32.dll
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #39)
> Kamil, do you think you could also do a quick check for this on ESR 38.0?

Ya, I'll verify it on ESR 38.0 as well. Could you link me to the build?
Flags: needinfo?(kjozwiak) → needinfo?(florin.mezei)
Currently can't verify the following channels:

* fx38 - the two latest builds are from 29-Apr-2015 and 04-May-2015. Because the fix was merged on 01-May-2015 (comment # 33), I need two builds that have been created after 2015-05-01 to correctly update. Right now, there's only the build from 04-May-2015.

* fx38.0.5 - not created yet (will need two builds to test updating)

* fx-esr38 - only a single nightly build is currently available from 05-May-2015. As mentioned above, I need two builds.

I can't use debug builds (2015-05-05-mozilla-esr38-debug) nor tinderbox builds because they're not nighties and don't have updates enabled. I'll have to wait until I either have two nightly builds that have been created after the fix was merged.

Robert, let me know if there's anything else I can do. I'll leave the needinfo for Florin (comment # 39) in case he knows any other builds that have been created that I can use but can't find.
Flags: needinfo?(robert.strong.bugs)
There is a way to force an update using the complete to verify. I'll set that up for you
Flags: needinfo?(robert.strong.bugs)
You can use the following to force the latest esr38 to update to itself
http://exchangecode.com/robert/work/snippets/esr38.xml

You can also use the following url to apply an empty update to test this.
http://exchangecode.com/robert/work/snippets/general.xml

Just add a new string pref named app.update.url.override with the value of the url you are using
Thanks Robert, that definitely did the trick. I used your xml file(s) as the template but had to upload it to my server as I had to change the hash values:

* http://kamiljozwiak.com/esr38.xml
Flags: needinfo?(kjozwiak)
Kamil, I'm not sure if you still need it, but here's the link to the 38 ESR builds location: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/38.0esr-candidates/build1/.
Flags: needinfo?(florin.mezei)
* Went through verification using the following build:
** http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/38.0esr-candidates/build1/

Used the method outlined in comment # 44 for updates. Also wanted to mention that I couldn't test FX x64 on the Win 7 x64 machine as the build doesn't exist.

Win XP Pro SP3 x86 - PASSED
==================

* \updates\0\lpk.dll
* \updates\0\usp10.dll
* \updates\0\updater.exe.Local\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll


Win XP Pro SP2 x64: - PASSED
=================== 

* \updates\0\updater.exe.Local\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.5190_x-ww_B8C2A5B7\comctl32.dll

Win Vista Ultimate SP2 x86 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll


Win Vista Ultimate SP2 x64 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll

Win 7 Pro SP1 x86 - PASSED
=================

* \updates\A3710B8EBB50CD3\updates\0\version.DLL
* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Win 7 Pro SP1 x64 - PASSED (Couldn't test check on FX x64 as only x86 builds of FX are available)
=================

Using FX x86:

* \updates\EEFEA8717BC47F65\updates\0\version.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Using FX x64: (only x86 builds available)
* Went through verification using the following build:
** http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/38.0-candidates/build2/

Used the same method outlined in comment # 44 for updates using the following URL:

- http://kamiljozwiak.com/fx38.xml

I also wanted to mention that I couldn't test FX x64 on the Win 7 x64 machine as fx x64 builds for the release candidate haven't been created.

Win XP Pro SP3 x86 - PASSED
==================

* \updates\0\lpk.dll
* \updates\0\usp10.dll
* \updates\0\updater.exe.Local\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll


Win XP Pro SP2 x64: - PASSED
=================== 

* \updates\0\updater.exe.Local\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.5190_x-ww_B8C2A5B7\comctl32.dll


Win Vista Ultimate SP2 x86 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll


Win Vista Ultimate SP2 x64 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll

Win 7 Pro SP1 x86 - PASSED
=================

* \updates\A3710B8EBB50CD3\updates\0\version.DLL
* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Win 7 Pro SP1 x64 - PASSED (Couldn't test fx64, builds not available for candidates builds)
=================

Using FX x86:

* \updates\EEFEA8717BC47F65\updates\0\version.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Using FX x64: (only x86 builds available for the candidates builds)
I'll go through fx38.0.5 verification once the build is released on Sunday/Monday. I'll use the same update method as outlined in comment # 44.
Thanks Kamil! You thoroughness is appreciated!
* Went through verification using the following build:
** http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/38.0.5b1-candidates/build2/

Used the same method outlined in comment # 44 for updates using the following URL:

- http://kamiljozwiak.com/fx385x86.xml [fx86]
- http://kamiljozwiak.com/fx385x64.xml [fx64]

Win XP Pro SP3 x86 - PASSED
==================

* \updates\0\lpk.dll
* \updates\0\usp10.dll
* \updates\0\updater.exe.Local\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll

Win XP Pro SP2 x64: - PASSED
=================== 

* \updates\0\updater.exe.Local\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.5190_x-ww_B8C2A5B7\comctl32.dll

Win Vista Ultimate SP2 x86 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll

Win Vista Ultimate SP2 x64 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll

Win 7 Pro SP1 x86 - PASSED
=================

* \updates\A3710B8EBB50CD3\updates\0\version.DLL
* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Win 7 Pro SP1 x64 - PASSED
=================

Using FX x86:

* \updates\EEFEA8717BC47F65\updates\0\version.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Using FX x64:

* \updates\A3710B8EBB50CD3\updates\0\version.DLL
* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
* \updates\0\updater.exe.Local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_fa396087175ac9ac\comctl32.dll
Status: RESOLVED → VERIFIED
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.