1453317 - Update Visual Studio 2017 used for builds in automation to version 15.6.6

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

Attachment: switch to VS2017 15.6.6

Yesterday, Microsoft issued a security advisory for Visual Studio. I don't *think* the impact is huge in practice, but it doesn't seem like a bad idea to take the update just to be on the safe side.

Try is green:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a017f597bdb99c42e89f9a6b208322a7135cbb74

Comment 1

[Nathan Froyd [:froydnj]]

Comment on attachment 8966976 [details] [diff] [review]
switch to VS2017 15.6.6

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

WFM.  OOC, do you have a link to the security advisory?

Comment 2

[Ryan VanderMeulen [:RyanVM]]

According to the advisory (see the URL field of this bug), this affects all versions of Visual Studio going back to at least 2010.

We've got a bit of a problem here in that we're currently using the following versions to build in automation:
61+: VS 2017 15.6 (can be fixed with the patch in this bug)
58-60: VS 2017 15.4 (no patch available)
ESR52: VS 2015 Update 3 (patch available)

I'm honestly not sure how we want to proceed here. I'm having a bit of a difficult time parsing the advisory as to how severe the issue is in practice, but I'm worried about information leaks from our build machines.

To be safe, I'd vote for updating, but that runs into big problems with 60 since we'd have to switch to newer compiler version to do so, and it's awful late in the cycle for that...

Comment 3

[Nathan Froyd [:froydnj]]

To be clear, this is information disclosure of uninitialized memory of the build machines through the PDB files that we generate and upload for all of our builds:

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-1037

Comment 4

[Ryan VanderMeulen [:RyanVM]]

FYI, Microsoft rated this issue as "3 – Exploitation Unlikely".

Per their docs:
> Microsoft analysis shows that successfully functioning exploit code is unlikely to be utilized in
> real attacks. This means that while it might be possible for exploit code to be released that could
> trigger the vulnerability and cause abnormal behavior, the full impact of exploitation will be more
> limited. Moreover, Microsoft has not observed instances of this type of vulnerability being actively
> exploited in the past. Thus, the actual risk of being exploited from this vulnerability is significantly
> lower. Therefore, customers who have reviewed the security update to determine its applicability within
> their environment could prioritize this update below other vulnerabilities within a release.

https://technet.microsoft.com/en-us/security/cc998259.aspx?f=255&MSPPError=-2147217396

Comment 5

[(not currently active) Ted Mielczarek]

"An attacker who took advantage of this information disclosure could view uninitialized memory from the Visual Studio instance used to compile the PDB file."

I don't think it's uninitialized memory from the machine, just from the compiler itself.

"What information is leaked in PDB files compiled with a vulnerable instance of Visual Studio? The memory leaked is limited to typically low-risk variables used in the application build environment, and only information that the Visual Studio executable uses when compiling projects. If your PDB/symbol files are shared publicly, this information could be extracted."

This seems unlikely to be actually harmful in practice, but updating on trunk is totally sensible.

Comment 6

[(not currently active) Ted Mielczarek]

The CVE page mentions that they provided an updated pdbcopy tool that can check PDB files: https://support.microsoft.com/en-us/help/4131751/pdbcopy-update-to-fix-pdb-security-issue

I downloaded that and fetched xul.pdb from the Nightly version I'm running on my Windows machine and it says the issue isn't present there:
$ /c/build/pdbcopy.exe c:/symcache/xul.pdb/93C2359FD2CF4F42938EEA2D41150CE32/xul.pdb /tmp/xul.pdb -CVE-2018-1037 verbos
e
[CVE-2018-1037] OK -- leak is not detected in `c:/symcache/xul.pdb/93C2359FD2CF4F42938EEA2D41150CE32/xul.pdb'

That page additionally says "This vulnerability affects only PDBs that have been updated after they were created." so it may be that the way we produce builds in automation simply doesn't hit this issue.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Thanks for the analysis, Ted! Based on that, I think we can just update trunk and get on with life.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f041c724fb80
Update VS2017 used in automation to version 15.6.6. r=froydnj

Comment 9

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/f041c724fb80

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/7bbcca9141e8
Port bug 1453317: Update VS2017 used in automation to version 15.6.6. rs=bustage-fix