1392955 - (CVE-2019-11696) JNLP should be treated as executable

Status: VERIFIED FIXED

(Firefox :: File Handling, defect)

Description

[Abdulrahman Alqabandi]

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

Steps to reproduce:

The .JNLP (Java web start app) should be treated as executable.

Visit: https://docs.oracle.com/javase/tutorial/deployment/webstart/deploying.html
Press 'Launch' 


Actual results:

The downloaded file is not treated as executable. 


Expected results:

Given that the result of this file is that Java is executed then this should be the same as .jar files. Granted, initially these files are always opened with restricted mode, but apparently they can be signed to bypass this. I don't think it's far fetched to imagine someone malicious is capable of signing these with rogue certs.

Also, (hate to do this) but Google Chrome treats it as dangerous.

Comment 1

[:Gijs (he/him)]

I thought on Windows what got treated as executable was dependent on the OS's pathext stuff or similar. Paolo, is that right? Do we have additional hardcoded lists?

Comment 2

[:Paolo Amadini]

It's a static list of file extensions:

https://dxr.mozilla.org/mozilla-central/rev/1867d7931c0a70ab90edf4aa84876525773a7139/xpcom/io/nsLocalFileWin.cpp#3003-3079

Comment 3

[Daniel Veditz [:dveditz]]

We have this in the application reputation code -- we really need to sync these lists

https://searchfox.org/mozilla-central/source/toolkit/components/downloads/ApplicationReputation.cpp#489

Comment 4

[François Marier [:francois]]

(In reply to Daniel Veditz [:dveditz] from comment #3)
> We have this in the application reputation code -- we really need to sync
> these lists
> 
> https://searchfox.org/mozilla-central/source/toolkit/components/downloads/
> ApplicationReputation.cpp#489

Yes, we really should.

The one in ApplicationReputation.cpp comes from https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/resources/safe_browsing/download_file_types.asciipb, which I monitor.

Comment 5

[:Paolo Amadini]

There's ".pdf" in there though, that I'm pretty sure we don't want to warn about being executable, although apparently we may still want to scan for malware. I know some document types may contain dangerous macros when used with certain viewers, or they can be used to trigger security bugs, but this is true of any downloaded document type regardless of type. To be useful, the list would have to be curated based on real-world usage.

Comment 6

[François Marier [:francois]]

(In reply to :Paolo Amadini from comment #5)
> There's ".pdf" in there though, that I'm pretty sure we don't want to warn
> about being executable, although apparently we may still want to scan for
> malware. I know some document types may contain dangerous macros when used
> with certain viewers, or they can be used to trigger security bugs, but this
> is true of any downloaded document type regardless of type. To be useful,
> the list would have to be curated based on real-world usage.

Ok, so maybe we do need two lists:

1. list of executables (in nsLocalFile*)
2. list of files to scan (in ApplicationReputation)

but the second would make use of the first and not include any entries that we already consider executable.

Then whenever Chrome adds new executables to their list, we can decide which of these lists it should be added to.

Also, we should never remove anything from the first list without adding it to the second.

Comment 7

[:Paolo Amadini]

I filed bug 1472631 to investigate serving the list of extensions in nsLocalFile in a hotfixable way. I don't know if a similar bug exists or is needed for the list in ApplicationReputation.

In the meantime, apart from ".jnlp", are there other file extensions from the list used by Chrome that we should add to the nsLocalFile list?

Comment 8

[François Marier [:francois]]

(In reply to :Paolo Amadini from comment #7)
> I filed bug 1472631 to investigate serving the list of extensions in
> nsLocalFile in a hotfixable way. I don't know if a similar bug exists or is
> needed for the list in ApplicationReputation.

So far, the updates have not been frequent enough to justify investing a lot of time in making this list more dynamic.

Comment 10

[:Gijs (he/him)]

Attachment: Bug 1392955, r=dimi

Comment 11

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/45b70e8a557b8e179ab87a66ade201eed0257196
https://hg.mozilla.org/mozilla-central/rev/45b70e8a557b

Comment 12

[Ryan VanderMeulen [:RyanVM]]

I'm inclined to let this ride the trains. Do you agree, Gijs?

Comment 13

[:Gijs (he/him)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #12)

I'm inclined to let this ride the trains. Do you agree, Gijs?

Yep.

Comment 14

[Rares Doghi, Desktop QA]

Hi, This issue seems to be Fixed on windows 10 in the latest Firefox Beta - 67.0b3, I will mark this issue accordingly. Please note that I don't have access to all available extensions mentioned in Comment 2 and I confirmed this bug based on the file from its Description.
If anybody else has any links that might redirect me to those other extension files, I'll be happy to check those as well.

Comment 15

[Frederik Braun [:freddy]]

Requesting bounty consideration on behalf of the reporter.

Comment 16

[Donald Smith]

I believe this bug is an error or oversight. FWIW, I run Java SE Product management at Oracle, and we've had a good relationship with the Firefox team dating back to 2013 or so. Unfortunately it would seem a lot of the people we used to work with are gone (Coates, Smedberg come to mind), or perhaps someone would have thought to reach out to myself or someone from Oracle to help work through this.

This change has caused harm and is causing your users to switch back to Chrome, Safari and Edge for their WebStart needs. Ironically these are the users that had switched to you years ago because you were offering the best and safest experience.

JNLP is not an executable. JNLP should be treated the same as any Word Document. A JNLP file will not cause execution on a system unless it has a valid signature, and the user explicitly authorizes the launching based on information provided by the signature. Moreover, we even check if the Java runtime (if there is one) is current, and prompt the user to update if required, something you wouldn't experience with a docx file, for example. We're happy to discuss with anyone at Mozilla, I would reach out but as I already noted, apparently our contacts are all long gone.

Comment 17

[johannes.michler]

For enterprise applications it would be helpful to define trusted domains or at least remove the jnlp from this list to avoid the message confusing users. Or at least to have a remember this page as secure.

Any chance to implement this?

Comment 18

[Thierry Guérin]

I second Donald Smith on this, a JNLP is NOT an executable. Java is launched, but before the downloaded jars are run, the user has to confirm if he really wants to execute the application.

It impacts the usability of our enterprise application, because now every time a user want to run our app, a new file is downloaded in his download folder, and he has to make sure to then click on the latest version of this file, otherwise it won't work (each run gives a different JNLP file because of credentials).
And now instead of these jnlp files being hidden in a temp folder (which can be automatically cleaned), they accumulate in his download folder, where they have absolutely no value.

Please reconsider, or at least implement what Johannes Michler has suggested.

Comment 19

[Pieter Breugelmans]

Given the fact that this bug is closed, we've gone ahead and filed a new bug 1576616 CVE 2019-11696 Should not treat JNLP files as Executables.

Comment 21

[:Gijs (he/him)]

Dan said he'd update this bug, so passing the needinfo to him.

Comment 22

[Daniel Veditz [:dveditz]]

To stop the immediate pain for organizations that use Java Web Start we are backing out the fix for this bug from ESR-68 in bug 1576616.

(In reply to Thierry Guérin from comment #18)

I second Donald Smith on this, a JNLP is NOT an executable. Java is launched, but before the downloaded jars are run, the user has to confirm if he really wants to execute the application.

You just described an executable. You can argue that a prompt from Java is good enough that Firefox doesn't also need to prompt, but you can't say it's not an executable. In any case there are obvious problems with the user interactions here that we should address. In particular it shouldn't behave worse than downloading an actual .exe. There are also platform disparities we need to address. This fixed bug is not the place to address those issues so I'm filing a new bug for that. I suppose bug 1576616 could have been that, but 1) we took that over to land a fix on ESR, and 2) the usability issues are bigger than just JNLP.

Comment 23

[Donald Smith]

Thanks Daniel!

It feels like we're using different meanings for "executable". jnlp is just like a docx file -- it isn't executable itself, but does trigger a separately installed application (Microsoft Word) to execute with it. If a user doesn't have Word installed, the OS would ask what to do with it, ditto for Java and JNLP. It feels from our perspective they (.jnlp and .docx) should be treated similarly.

Happy to discuss or elaborate, and glad to hear the immediate pain point can be managed.

Comment 24

[Daniel Veditz [:dveditz]]

We can address the remaining issues in bug 1576762

Comment 25

[Daniel Veditz [:dveditz]]

(In reply to Donald Smith from comment #23)

It feels like we're using different meanings for "executable". jnlp is just like a docx file -- it isn't executable itself, but does trigger a separately installed application (Microsoft Word) to execute with it. If a user doesn't have Word installed, the OS would ask what to do with it, ditto for Java and JNLP. It feels from our perspective they (.jnlp and .docx) should be treated similarly.

This is a disagreement we're unlikely to resolve. To us a word file is fundamentally a "document" like HTML while Java is a programming language.

Comment 26

[Mark Straver]

(In reply to Daniel Veditz [:dveditz] from comment #25)

This is a disagreement we're unlikely to resolve. To us a word file is fundamentally a "document" like HTML while Java is a programming language.

By that reasoning a word file should also be considered an executable, considering word documents can contain macros and scripting in VBA, a programming language. The same kind of safeguards apply to that as to JNLP (user is explicitly prompted before execution). Same for excel, and any other document that has extended scripting capabilities.

I have to agree with Donald here that you shouldn't treat this any differently.

Comment 27

[Markus Buch]

Facing the same problem I found one workaround. Add following example content to the "mimeTypes" collection in handlers.json located in %USERPROFILE%\AppData\Roaming\Mozilla\Firefox\Profiles\xxxxxxxx.default. Afterwards you will be able to assign any program you like to open jnlp with in Firefox settings.

"application/x-java-jnlp-file":{"action":2,"handlers":[{"name":"start-jre.bat","path":"C:\\JRE\\start-jre.bat"}],"extensions":["jnlp"]}