1230354 - Executable planting / Drive-by cache vulnerability

Status: NEW

(Core :: Networking: Cache, defect, P5)

Description

[firace]

User Agent: Mozilla/5.0 (Windows NT 6.3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36

Steps to reproduce:

The IMG HTML tag can be misused to plant an arbitrary executable in the hard disk cache, with no warnings or prompts. This submission is not a code *execution*,  but a code planting / 'drive-by cache' vulnerability. However it can still easily lead to Arbitrary Code Execution or Denial of Service in the following scenarii: 


A. A legitimate Windows application or script working with Firefox's cache or userprofile files, if written with insufficient precautions, could be induced into running the executable file rather than simply opening it for viewing.


B. Many organizations (for instance, in government or banking industry) choose to immediately re-image a machine if any sort of malware is detected.  If website or forum frequently visited by users of that organization is made to carry an IMG tag delivering a known malware file (for instance through malvertising, or a forum avatar image upload), the helpdesk could quickly be flooded with calls and business impact can ensue, even if no code gets executed.  

 
C. Social engineering: Unsuspecting users could easily be tricked into unwittingly triggering the executable themselves, for instance by running a seemingly harmless command - see this simple POC:

  http://trax.x10.mx/fx1_poc_egg.htm
  
  
D. Lastly, this vulnerability could obviously be chained to any another suitable exploit to lead to code execution.

Thanks for looking into this issue and its possible ramifications.

Regards

Firas Salem
@hexatomium



Note: I believe I have found a similar issue in IE and Chrome, and have submitted a report to the appropriate teams.



Actual results:

A functional MZ (Windows executable) is silently downloaded to the Firefox hard disk cache. (See PoC above for a quick demo)


Expected results:

Arbitrary MZ / PE executable files should not be allowed to reside in cache folders.
One possible way to mitigate it could be to simply forbid caching of any files with an "MZ" header, regardless of file extension.

Comment 1

[firace]

If someone has trouble running the social engineering test with the latest Firefox version, let me know. I might need to review and update the PoC to make it more reliable.

Comment 2

[Daniel Veditz [:dveditz]]

The for loop is clever, but if you can socially engineer someone into running a command line you probably don't even need an executable in the cache (power shell is quite powerful, for example). Wouldn't be quite as obfuscated as `& "%g.log"`, but we really need to train people "don't Win+R" rather than hope they can figure out the difference between a safe commandline and an unsafe one. 

SafeBrowsing would eventually block the download as would local anti-virus, but only after some large number of initial victims.

Since this is basic browser behavior a public discussion aimed at some kind of industry consensus would be more effective than individual private bugs with each browser vendor.

Comment 3

[firace]

* Pardon my ignorance of such matters, but who would initiate such a public discussion?

* Wouldn't the bigger issue in the above POC be the trivial abuse of the IMG tag, rather than the Win+R command line?

* As public discussion could take a long time before producing results,  wouldn't it be a good tactical measure for browsers to also check the validity of image files before saving them to cache?

* Also, training people to beware of weird instructions involving Win+R would also take a long time,
with many users *still* opening suspicious email attachments and links, even after years of training...

Comment 4

[Daniel Veditz [:dveditz]]

The best place to discuss this would be in our networking newsgroup/mailing list or in the general platform group.

https://www.mozilla.org/en-US/about/forums/#dev-platform
https://www.mozilla.org/en-US/about/forums/#dev-tech-network

Can we unhide the bug for the discussion, or do you want to leave the details obscured while you're discussing with the IE and Chrome teams?

Comment 5

[firace]

Could you please keep it hidden till end of March?

Comment 6

[Tom Ritter [:tjr]]

I believe this can be unhidden now. Dan?

Comment 7

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258