1273265 - (CVE-2017-7765) Firefox Mark of the Web bypass (MSVR 1533)

Status: RESOLVED FIXED

(Firefox :: File Handling, defect)

Description

[MSVulnReport]

Attachment: 85231FFExploit.htm

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2486.0 Safari/537.36 Edge/13.10586

Steps to reproduce:

Dan from Microsoft Vulnerability Research (MSVR) here.  We’ve found a way to bypass Mark of the Web in FireFox. I have a repro available at the following URL: http://payloadhoster.cloudapp.net/85231FFExploit.htm

(the same file is attached, but would need to be hosted somewhere along with a file to download in order to repro the issue)

To reproduce the issue:
1.	On a Windows 10 machine with Office installed, browse to the page in Firefox
2.	Click the link
3.	Select either to save the file locally, or open in PowerPoint

This vulnerability appears to be caused by links with a “download” attribute that causes the filename to be longer than what’s allowed in Windows.  It’s likely that the cause here is trying to call one Windows API or another with a string that’s too long.

Thank you for reviewing this report and we'll pass on any questions from the engineering team to the finder promptly. We look forward to hearing your team's analysis.  For our prompt attention, please email [e-mail] and reference MSVR 1533 in the title.


Actual results:

mark of the web is not applied in either case



Expected results:

mark of the web is applied and the file is open in protected view

Comment 1

[Al Billings [:abillings - ex-MoCo]]

This is a DOM related issue. Can you take a look at this?

Comment 2

[Daniel Veditz [:dveditz]]

jimm might have an idea of an appropriate owner as well.

Comment 3

[:Gijs (out for now; he/him)]

AIUI this is because of:

https://dxr.mozilla.org/mozilla-central/source/toolkit/components/jsdownloads/src/DownloadIntegration.jsm#632

which is going to have the file name suggested by the download attribute.

Now... we could change the filename to not be so long, but AIUI the filename needs to match that of the file we're saving, otherwise it still won't be marked as "from the web". I don't know where we modify the actual filename - presumably, we need to ensure that we save the file somewhere where it doesn't actually get the super-long filename, and we have 'space' left at the end to tag on the ":Zone.Identifier" stuff.

Paolo originally wrote this code (bug 909022), and generally knows our download code, so I think it'd be best if he took this.

Comment 4

[Jim Mathies [:jimm]]

This used to be in the download manager c++ code, but I guess we ported it over js. Not really my area anymore.

Comment 5

[:Paolo Amadini]

(In reply to :Gijs Kruitbosch from comment #3)
> Now... we could change the filename to not be so long, but AIUI the filename
> needs to match that of the file we're saving, otherwise it still won't be
> marked as "from the web". I don't know where we modify the actual filename -
> presumably, we need to ensure that we save the file somewhere where it
> doesn't actually get the super-long filename, and we have 'space' left at
> the end to tag on the ":Zone.Identifier" stuff.

We rely indirectly on the nsIFile.createUnique function to shorten the path at the time it is chosen, it can be tricky to make room for the ":Zone.Identifier" part there:

https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/downloads/DownloadPaths.jsm#55

We could try prepending "\\?\" during our "OS.File" call in Downloads.jsm to increase the 260 characters limit for that particular operation, I'm not sure if that works with the Alternate Data Stream syntax though. We may have to be careful about features we lose like the automatic conversion of forward slash to backslash.

Comment 6

[:Paolo Amadini]

I experimented with the prefix on my Windows 7 system on an NTFS partition:

let streamPath = "\\\\.\\" + aDownload.target.path + ":Zone.Identifier";

This still result in Windows error 3 (The system cannot find the path specified), presumably returned when CreateFileW is called by OS.File. I also tried this without the ADS syntax, just in case:

let streamPath = "\\\\.\\" + aDownload.target.path + "_Zone.Identifier";

And the result is the same. So, apparently the prefix that according to the documentation should increase the limit accepted by the API to 32767 characters doesn't work here.

What are the correct Windows API calls to apply an ADS to a file with a long name using the Windows API?

Comment 7

[:Paolo Amadini]

(And both calls above work correctly with shorter names).

Comment 8

[Andrea Marchesini [:baku]]

Wondering why nsIFile doesn't use MAX_PATH to check what is allowed and what is not on Windows.

Comment 9

[:Paolo Amadini]

(In reply to Andrea Marchesini (:baku) from comment #8)
> Wondering why nsIFile doesn't use MAX_PATH to check what is allowed and what
> is not on Windows.

CreateUnique makes an assumption that 255 excluding the NUL terminator works for all platforms:

https://dxr.mozilla.org/mozilla-central/source/xpcom/io/nsLocalFileCommon.cpp#53

For the rest, we don't have to check for MAX_PATH explicitly because the OS will raise an error for us if needed. The issue we have only arises when we append the ADS syntax to the file name.

Comment 10

[:Gijs (out for now; he/him)]

(In reply to :Paolo Amadini from comment #9)
> (In reply to Andrea Marchesini (:baku) from comment #8)
> > Wondering why nsIFile doesn't use MAX_PATH to check what is allowed and what
> > is not on Windows.
> 
> CreateUnique makes an assumption that 255 excluding the NUL terminator works
> for all platforms:
> 
> https://dxr.mozilla.org/mozilla-central/source/xpcom/io/nsLocalFileCommon.
> cpp#53
> 
> For the rest, we don't have to check for MAX_PATH explicitly because the OS
> will raise an error for us if needed. The issue we have only arises when we
> append the ADS syntax to the file name.

Is anything going to be terribly upset if we just #ifdef XP_WIN that limit to whatever MAX_PATH is on Windows minus the length of the ADS syntax ? Or is that a dumb idea for other reasons? :-)

Comment 11

[:Paolo Amadini]

(In reply to :Gijs Kruitbosch from comment #10)
> Is anything going to be terribly upset if we just #ifdef XP_WIN that limit
> to whatever MAX_PATH is on Windows minus the length of the ADS syntax ?

It's kind of linked to the specific ADS name we are using, ":Zone.Identifier", so not terribly great but it's a quick and dirty solution that could work as I think it's the only ADS we'll ever use (hehe, I mean, the only ADS we're currently using).

We may introduce regressions as we may prevent downloads to be saved at all in deeply nested folders where it would be otherwise legitimate to have a short file name, but it may be a cost we need to pay if the Windows API doesn't give us a better solution anyways...

Comment 12

[MSVulnReport]

FYI: if this issue is fixed and an acknowledgement given, credit should go to:
Jonathan Birch and Microsoft Vulnerability Research

Comment 13

[MSVulnReport]

Has there been any updates on this bug?

Comment 14

[:Paolo Amadini]

(In reply to MSVulnReport from comment #13)
> Has there been any updates on this bug?

Thanks for asking, I have a technical question for you from comment 6. We might be dealing with a limitation of the Windows API or NTFS with regard to file name length in the presence of an ADS. It's possible this is something that should be fixed on the Microsoft side, even though we might have a workaround.

I experimented with the prefix on my Windows 7 system on an NTFS partition:

let streamPath = "\\\\.\\" + aDownload.target.path + ":Zone.Identifier";

This still result in Windows error 3 (The system cannot find the path specified), presumably returned when CreateFileW is called by OS.File. I also tried this without the ADS syntax, just in case:

let streamPath = "\\\\.\\" + aDownload.target.path + "_Zone.Identifier";

And the result is the same. So, apparently the prefix that according to the documentation should increase the limit accepted by the API to 32767 characters doesn't work here.

What are the correct Windows API calls to apply an ADS to a file with a long name using the Windows API?

Comment 15

[Raymond Forbes[:rforbes]]

This needs to be backported to ESR as this has a larger effect on enterprise customers. This decision is from conversation with Microsoft, Google, and partners.

Comment 16

[:Paolo Amadini]

(In reply to Raymond Forbes[:rforbes] from comment #15)
> This needs to be backported to ESR as this has a larger effect on enterprise
> customers. This decision is from conversation with Microsoft, Google, and
> partners.

It would be nice if Microsoft, Google, and partners took a look at the questions I raised in this bug.

The bug or limitation might be in the Windows API and affect other products as well.

Comment 17

[Raymond Forbes[:rforbes]]

@paolo we had a meeting with the microsoft team yesterday at Blue Hat. The engineer who would be working on this is planning on making a bugzilla account and responding very soon.

Comment 18

[Al Billings [:abillings - ex-MoCo]]

(In reply to :Paolo Amadini from comment #16)
> 
> It would be nice if Microsoft, Google, and partners took a look at the
> questions I raised in this bug.

In fact, I added a Microsoft representative from our meeting to this bug yesterday. He'll be working with the developers on their end to get questions answered.

Comment 19

[:Paolo Amadini]

That's great, thanks for the update!

Comment 20

[Jonathan Birch]

This is Jonathan Birch, with Microsoft Office Security. I'm meeting with the relevant API owners tomorrow, but in response to this:

> I experimented with the prefix on my Windows 7 system on an NTFS partition:
> 
> let streamPath = "\\\\.\\" + aDownload.target.path + ":Zone.Identifier";
> 
> This still result in Windows error 3 (The system cannot find the path
> specified), presumably returned when CreateFileW is called by OS.File. I
> also tried this without the ADS syntax, just in case:
> 
> let streamPath = "\\\\.\\" + aDownload.target.path + "_Zone.Identifier";
> 
> And the result is the same. So, apparently the prefix that according to the
> documentation should increase the limit accepted by the API to 32767
> characters doesn't work here.

They've gotten back to me to say that the syntax you're looking for might be \\?\ rather than \\.\

Also, I'm not currently receiving email sent to me through Bugzilla, due to issues with S/MIME on my end. I'm not sure if that matters, but I'm working on getting is solved.

Comment 21

[:Paolo Amadini]

(In reply to Jonathan Birch from comment #20)
> This is Jonathan Birch, with Microsoft Office Security. I'm meeting with the
> relevant API owners tomorrow, but in response to this:
> They've gotten back to me to say that the syntax you're looking for might be
> \\?\ rather than \\.\

Ah, sorry! So, just prepending \\?\ works fine and it fixes the bug when saving to a local file system. If I understand correctly, however, it won't give the correct result for UNC paths, and won't normalize slashes into backslashes.

So here is a new question for the API owners: do I really have to pass the path to the undocumented RtlDosPathNameToNtPathName_U function to work around the MAX_PATH limit and still preprocess the path, as described in the following blog post I just found?

https://googleprojectzero.blogspot.it/2016/02/the-definitive-guide-on-win32-to-nt.html

If the conversion rules are very simple we might just reimplement them in JavaScript without the complications of accessing an ntdll export.

Note that we want to keep compatibility back to Windows 7 at least.

> Also, I'm not currently receiving email sent to me through Bugzilla, due to
> issues with S/MIME on my end. I'm not sure if that matters, but I'm working
> on getting is solved.

I'll also notify you of this message directly.

Comment 22

[Jonathan Birch]

> Ah, sorry! So, just prepending \\?\ works fine and it fixes the bug when
> saving to a local file system. If I understand correctly, however, it won't
> give the correct result for UNC paths, and won't normalize slashes into
> backslashes.
> 
> So here is a new question for the API owners: do I really have to pass the
> path to the undocumented RtlDosPathNameToNtPathName_U function to work
> around the MAX_PATH limit and still preprocess the path, as described in the
> following blog post I just found?
> 
> https://googleprojectzero.blogspot.it/2016/02/the-definitive-guide-on-win32-
> to-nt.html
> 
> If the conversion rules are very simple we might just reimplement them in
> JavaScript without the complications of accessing an ntdll export.
> 
> Note that we want to keep compatibility back to Windows 7 at least.

Based on discussion with API owners: You can get the canonicalized path name by prepending \\?\ and then calling GetFullPathName on the full string. There should be no need to call RtlDosPathNameToNtPathName_U. The resulting path should be passable to any Win32 API for saving files and not subject to MAX_PATH limits. 

This will probably end up giving the user a file they can't open due to its filename being too long.

Filename segments are still limited to 255 characters, so you'll still need to truncate in some way. My impression is that you have some other solution to that issue already.

Is that enough information to help you solve this issue?

Comment 23

[:Paolo Amadini]

(In reply to Jonathan Birch from comment #22)
> Based on discussion with API owners: You can get the canonicalized path name
> by prepending \\?\ and then calling GetFullPathName on the full string.
> There should be no need to call RtlDosPathNameToNtPathName_U. The resulting
> path should be passable to any Win32 API for saving files and not subject to
> MAX_PATH limits.

That works for converting slashes to backslashes, but still doesn't support UNC paths out of the box.

Considering that we are operating under some well known restrictions, and we don't need to provide generic access to paths whose length is beyond MAX_PATH, I've special cased the UNC "DOS" paths and I believe that it works sufficiently well in combination with GetFullPathName for the problem we're trying to solve here.

The only issue would be if GetFullPathName misses other normalizations that RtlDosPathNameToNtPathName_U does, beyond handling UNC paths, resulting in an attempt to access a file with a different name in the presence of some special characters, but this is for the API owners to tell. Note that we filter allowed file names, and we've already accessed the file before.

> This will probably end up giving the user a file they can't open due to its
> filename being too long.
> 
> Filename segments are still limited to 255 characters, so you'll still need
> to truncate in some way. My impression is that you have some other solution
> to that issue already.

We already operate withing the MAX_PATH limitations for all other operations, and I've tested the file can still be opened and its properties inspected from Windows Explorer after the ADS is added.

> Is that enough information to help you solve this issue?

I'll post a patch with an implementation that solves the bug for the test case, when saving to local paths or UNC paths. I may need more information on the normalization question above, and the patch can be a good starting point if the API owners want to take a look.

Comment 24

[:Paolo Amadini]

Attachment: The patch

Gijs, you may also want to take a look in the meantime.

Comment 25

[:Gijs (out for now; he/him)]

Comment on attachment 8810055 [details] [diff] [review]
The patch

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

I think Jim would be a better reviewer/feedback-giver here. :-)

Comment 26

[Jim Mathies [:jimm]]

Comment on attachment 8810055 [details] [diff] [review]
The patch

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

::: toolkit/components/osfile/modules/osfile_win_front.jsm
@@ +353,5 @@
> +       if (options.winAllowLengthBeyondMaxPathWithCaveats) {
> +         // Use the \\?\ syntax to allow lengths beyond MAX_PATH. This limited
> +         // implementation only supports a DOS local path or UNC path as input.
> +         let isUNC = path.length >= 2 && (path[0] == "\\" || path[0] == "/") &&
> +                                         (path[1] == "\\" || path[1] == "/");

Why do we check for forward slashes here, afaict this isn't allowed for unc paths.

Comment 27

[:Paolo Amadini]

(In reply to Jim Mathies [:jimm] from comment #26)
> Why do we check for forward slashes here, afaict this isn't allowed for unc
> paths.

Most Windows APIs actually accept forward slashes and convert them to backslashes automatically, so we need to check for forward slashes as well. Given that this path prefix is set by the Firefox preferences UI, though, it is unlikely that the full path checked here would have forward slashes, unless about:config has been edited directly by an advanced user.

I think we're now only waiting for Jonathan Birch to relay the patch and comment 23 to the Windows API owners to tell if this fix is good enough or it may introduce known regressions on shorter paths.

Comment 28

[:Paolo Amadini]

For the record, that might happen after the holidays, as I just got an out of office automated reply.

Comment 29

[Jonathan Birch]

I have a thread in progress regarding the question in Comment 23. I'll relay the patch as well. I'll post back here as soon as I have an answer.

Comment 30

[Jonathan Birch]

Sorry for the delay in getting this patch reviewed. There were a few complications on our end.

I've had people knowledgeable about path canonicalization examine the source for this patch, and they say it looks correct. I have not been able to perform any practical testing of the patch itself, as it's not clear that I can actually build Firefox from source.

Is that enough for you to move forward with checking in this fix? You still have the original repro to check your fix against for practical testing.

Comment 31

[:Paolo Amadini]

Comment on attachment 8810055 [details] [diff] [review]
The patch

(In reply to Jonathan Birch from comment #30)
> I've had people knowledgeable about path canonicalization examine the source
> for this patch, and they say it looks correct.

Thanks, this is definitely helpful! I'm asking Jim for the final review.

Comment 32

[Jim Mathies [:jimm]]

Patch looks good, can we put a test together for this?

Comment 33

[:Paolo Amadini]

It will be a while before I can find the time to put together a test case, as I'm traveling right now. It's definitely possible to have one, it would just rely on the same new API when reading the Alternate Data Stream.

Any test case would need to be verified in automation, but only after we've landed the patch properly in all branches. I'm not quite sure about the landing process for security patches. Gijs, what happens after the patch gets a final review?

Comment 34

[:Gijs (out for now; he/him)]

(In reply to :Paolo Amadini from comment #33)
> It will be a while before I can find the time to put together a test case,
> as I'm traveling right now. It's definitely possible to have one, it would
> just rely on the same new API when reading the Alternate Data Stream.
> 
> Any test case would need to be verified in automation, but only after we've
> landed the patch properly in all branches. I'm not quite sure about the
> landing process for security patches. Gijs, what happens after the patch
> gets a final review?

This bug is rated sec-moderate, so as far as I understand https://wiki.mozilla.org/Security/Bug_Approval_Process you should be able to land the patch without explicit sec-approval once it has review. You'll probably want to ask for approval for branch patches for 53 and 54, and possibly 52-esr. The wikipage suggests NOT landing tests until after we ship the fix.

That said, I would strongly encourage you to write the test ASAP, and run it against beta locally (not on try) after you create a branch patch, to ensure we actually fix the issue and successfully test for it in automation, even if we then don't land it until afterwards.

Does that answer your question?

Comment 35

[:Paolo Amadini]

Attachment: The test

Comment 36

[:Paolo Amadini]

I ran the test locally on Nightly for now, not on a Beta build yet. The affected OS.File code has not been touched very much recently, and I expect the patch to apply cleanly to all branches.

It looks like we might be able to land the patch in the next two days, for Beta 10:

https://calendar.google.com/calendar/embed?src=bW96aWxsYS5jb21fZGJxODRhbnI5aTh0Y25taGFiYXRzdHY1Y29AZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ

Comment 37

[:Paolo Amadini]

Comment on attachment 8810055 [details] [diff] [review]
The patch

This bug is sec-moderate because it cannot be used alone to run arbitrary code on the user's computer, but it removes the security warning that the Windows operating system shows before running executables downloaded from the Internet.

While sec-approval is not needed, I'm requesting it so I can get help with the landing process. I'll be around in the next few days, but note that the sheriffs may also be able to land the patch without assistance if needed.

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
- Easily.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
- People familiar with the Windows file system can very easily understand the issue being fixed.

Which older supported branches are affected by this flaw?
- All branches

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
- The patch should apply easily to all branches

How likely is this patch to cause regressions; how much testing does it need?
- There is a very slim chance of regressions with file names with special characters, but this is mitigated by the fact that the code has been reviewed by Microsoft experts.

Comment 38

[:Paolo Amadini]

Comment on attachment 8810055 [details] [diff] [review]
The patch

Approval Request Comment
[Feature/Bug causing the regression]: Downloads
[User impact if declined]: For downloaded executables with long file names, the Windows security warning is not shown.
[Is this code covered by automated tests?]: Yes
[Has the fix been verified in Nightly?]: No
[Needs manual test from QE? If yes, steps to reproduce]: See the attached exploit
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: Low risk
[Why is the change risky/not risky?]: Manual and automated tests have been executed locally. There is a very slim chance of regressions with file names with special characters, but this is mitigated by the fact that the code has been reviewed by Microsoft experts.
[String changes made/needed]: None

Comment 39

[Al Billings [:abillings - ex-MoCo]]

This is a sec-moderate. Sec-moderate bugs do not need to have sec-approval+ to land on trunk.

https://wiki.mozilla.org/Security/Bug_Approval_Process

Comment 40

[Jim Mathies [:jimm]]

Comment on attachment 8854382 [details] [diff] [review]
The test

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

Thanks!

Comment 41

[:Paolo Amadini]

(In reply to :Paolo Amadini from comment #37)
> While sec-approval is not needed, I'm requesting it so I can get help with
> the landing process.

Hey Al, do I just go ahead and land the patch on trunk myself now? Do I include a commit message and a description?

Comment 42

[Al Billings [:abillings - ex-MoCo]]

Well, it is still a security bug so I would be careful what the commit message and description say. As to whether you land or not, you can land or ask sheriffs to land. Yes, it can land though.

Comment 43

[:Paolo Amadini]

If we can we get Beta approval and land later today, can this land this for Beta 10?

Comment 44

[Liz Henry (:lizzard) (relman/hg->git project)]

Yes, that's fine, if you can land on m-c first and tests pass.  We will go to build Thursday morning, and I'll be checking for uplift requests over the day today.

Comment 45

[Liz Henry (:lizzard) (relman/hg->git project)]

This could still land for beta 10, I just don't want to mark it approved till it lands and sticks on trunk - I will have another look in the morning, and may end up going to build later in the day Thursday anyway.

Comment 46

[:Paolo Amadini]

https://hg.mozilla.org/integration/mozilla-inbound/rev/af83078c48588a2b1e39cc0fb7fac250a58b107f

https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=af83078c48588a2b1e39cc0fb7fac250a58b107f

Comment 47

[Liz Henry (:lizzard) (relman/hg->git project)]

Wes, can you make sure we land this on trunk, so I can approve it for aurora/beta? Thanks!

Comment 48

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 49

[:Paolo Amadini]

So... has this landed on any branches yet?

Comment 50

[Andrew McCreight [:mccr8]]

(In reply to :Paolo Amadini from comment #49)
> So... has this landed on any branches yet?

It has not. When it has been, the affected flags for those branches will be set to fixed. It is still waiting for branch approvals.

Comment 51

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8810055 [details] [diff] [review]
The patch

Let's uplift to aurora, but this has missed beta 10 and so I'd like to let the fix ride with 54.

Comment 52

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/143182787f1f

Comment 53

[Julien Cristau [:jcristau]]

wontfix for 53 based on comment 51.  will keep on the list for 52.2esr.

Comment 54

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8810055 [details] [diff] [review]
The patch

The patch is low risk, has been in 54 for almost a month, ESR52.2+

Comment 55

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr52/rev/7902fea300b8

Comment 56

[Jonathan Birch]

Just to confirm something, will there be a CVE for this? If so, I would like to be credited.

Comment 57

[:Gijs (out for now; he/him)]

(In reply to Jonathan Birch from comment #56)
> Just to confirm something, will there be a CVE for this? If so, I would like
> to be credited.

--> Al?

Comment 58

[Al Billings [:abillings - ex-MoCo]]

A CVE will be assigned before our release. We don't put the names of people on CVE so CVE assignment is immaterial for credit.

This will be mentioned as fixed in the advisory for the appropriate release. The advisory will list the reporter credit as "Jonathan Birch and Microsoft Vulnerability Research" within it.

Comment 59

[Matt Wobensmith [:mwobensmith][:matt:]]

Hello, would you be able to confirm this issue as fixed on your end?

Comment 60

[:Paolo Amadini]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=769a12e43f7ac884920afbc6113b6c7c34d6a193

Comment 61

[:Paolo Amadini]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=8a2ef11875385395366de43a34370fac016c9901

Comment 62

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/673af834eacb
Test writing zone information for files with long names. r=jimm

Comment 63

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/673af834eacb