Skip to content
This repository has been archived by the owner on Feb 25, 2020. It is now read-only.

Detect access to navigator plugin and mimeType details #19

Open
gunesacar opened this issue Apr 23, 2015 · 9 comments
Open

Detect access to navigator plugin and mimeType details #19

gunesacar opened this issue Apr 23, 2015 · 9 comments

Comments

@gunesacar
Copy link

Currently Chameleon cannot intercept access to high entropy plugin properties such as name, filename and description. It only counts the number of accesses to navigator.plugins.

Here's a simple demo page. The script on the page enumerates all the details about navigator.plugins, but the access to individual plugin properties goes unnoticed.

@ghostwords
Copy link
Owner

Chameleon's injected page script detects the navigator accesses (as per the following developer-mode page console output), but it looks like Chameleon proper never receives that info.

Navigator.plugins prop access: https://securehomes.esat.kuleuven.be/~gacar/dev/test/navfp/nav_plugins_fp.html:6:29
Error
    at Navigator.Object.defineProperty.get [as plugins] (<anonymous>:11:1064)
    at enum_plugins (nav_plugins_fp.html:6)
    at onload (nav_plugins_fp.html:14)

Navigator.plugins prop access: https://securehomes.esat.kuleuven.be/~gacar/dev/test/navfp/nav_plugins_fp.html:8:17
Error
    at Navigator.Object.defineProperty.get [as plugins] (<anonymous>:11:1064)
    at enum_plugins (nav_plugins_fp.html:8)
    at onload (nav_plugins_fp.html:14)

Navigator.plugins prop access: https://securehomes.esat.kuleuven.be/~gacar/dev/test/navfp/nav_plugins_fp.html:8:17
Error
    at Navigator.Object.defineProperty.get [as plugins] (<anonymous>:11:1064)
    at enum_plugins (nav_plugins_fp.html:8)
    at onload (nav_plugins_fp.html:14)

Navigator.plugins prop access: https://securehomes.esat.kuleuven.be/~gacar/dev/test/navfp/nav_plugins_fp.html:8:17
Error
    at Navigator.Object.defineProperty.get [as plugins] (<anonymous>:11:1064)
    at enum_plugins (nav_plugins_fp.html:8)
    at onload (nav_plugins_fp.html:14)

Navigator.plugins prop access: https://securehomes.esat.kuleuven.be/~gacar/dev/test/navfp/nav_plugins_fp.html:8:17
Error
    at Navigator.Object.defineProperty.get [as plugins] (<anonymous>:11:1064)
    at enum_plugins (nav_plugins_fp.html:8)
    at onload (nav_plugins_fp.html:14)

Navigator.plugins prop access: https://securehomes.esat.kuleuven.be/~gacar/dev/test/navfp/nav_plugins_fp.html:8:17
Error
    at Navigator.Object.defineProperty.get [as plugins] (<anonymous>:11:1064)
    at enum_plugins (nav_plugins_fp.html:8)
    at onload (nav_plugins_fp.html:14)

I think the document.write calls clear the document (since they run after the document finished loading), which breaks Chameleon's communication channel between its injected page script and its injected content script.

@ghostwords
Copy link
Owner

While this scenario might be an acceptable edge case, it is true that Chameleon does not trap Plugin properties, only Navigator properties (such as PluginArray).

@gunesacar
Copy link
Author

Great!
I think trapping plugin properties may help a lot with filtering out false positives (e.g. just checking if you have Flash vs. plugin enumeration with full details).

Also, even when I get rid of document.write, I still get the ~same error you mentioned on the DevTools console. Here's a demo which accesses navigator.plugins and mimetypes without using document.write.

It seems simply accessing navigator.plugins or navigator.mimeTypes causes the error. For the record, I'm using the master branch on Chromium 41.0.

@ghostwords
Copy link
Owner

Oh, sorry, those aren't errors! It's just Chameleon figuring out the originating script using Chrome stack traces and me not bothering to edit the traces before dumping them to the console in dev mode.

@gunesacar
Copy link
Author

Ugh, I see :)
That make me feel like this: https://imgur.com/SL88Z6g

@ghostwords
Copy link
Owner

Ha ha!

@ghostwords
Copy link
Owner

On that second demo page Chameleon currently picks up a single hit for navigator.plugins and a single hit for navigator.mimeTypes. While that's correct, I agree it would be great to have a fuller picture of what happened to those properties that are in themselves enumerable lists of properties.

Also, "navigator enumeration" right now isn't as interesting as "font enumeration" or "canvas fingerprinting", I feel like. It's probably too coarse a metric; perhaps the solution is to break it down into "plugin enumeration" and "MIME type enumeration".

@gunesacar gunesacar changed the title Detect access to navigator plugins details Detect access to navigator plugin and mimeType details Apr 26, 2015
@gunesacar
Copy link
Author

I think breaking it into plugin and mimeType enumeration is definitely a good idea.

Perhaps, enumeration of the remaining navigator properties could still be useful (e.g. for detecting scripts that traverse the navigator by for prop in navigator, or similar ways.)

@ghostwords
Copy link
Owner

Now that I turned off raw counting of property accesses (96f3468), this ticket should help (re-)light Chameleon on Panopticlick.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants