Closed Bug 514004 Opened 13 years ago Closed 13 years ago

PFS2 should expose vulnerability info for plugins

Categories

(addons.mozilla.org Graveyard :: Plugins, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ozten, Assigned: lorchard)

Details

Currently the PFS2 API has current version information for the list of plugins returned, but there is no notion of 'vulnerable versions'.

Certain releases of plugins become 'vulnerable versions' when an exploit is published.

Expected:
A caller of PFS2 should be able to determine if version x.y.z of plugin foo is vulnerable

Actual:
PFS 2 results contains a version, but no vulnerability flag, or list of vulnerable versions.
Perhaps a 2nd API is need which takes a plugin guid and version as inputs and returns a boolean indicating if the plugin is vulnerable or just out of date.
An alternative to comment 1 is that the pfs2 response includes a list of vulnerable versions.
Okay, starting to finally get time to wrap my head around this.  I'm going to ramble a bit here:

The PFS2 API is a clone of PFS1 that uses a database.  As such, my understanding is that it's only a plugin finder, meant to look up the single latest version of a plugin for a given mime-type / app / OS / locale so Firefox & friends can suggest it for install when an unsupported object appears in a page.  PFS has no concept of previous versions and has no idea about vulnerabilities.

Given that, I think something a bit different is needed for this project.  Maybe not enormously different, but different.

So, some thoughts to get this moving, if only for thinking out loud:

1) I need to get an idea of the available inputs.  PFS2 accepts mimetype, OS, appID, appVersion, appRelease, and chromeLocale to use in lookups.  

Are you able to find all of what PFS2 accepts? Is there anything else available from JS that might help in identifying a plugin and whether it's out of date? It's been ages since I did plugin detection in a browser.

2) What kind of output would be helpful for the JS detection lib?  PFS2 spits out some JSON right now that I tried to match to the original PFS1 RDF, which I didn't/don't quite understand. :) Are there additional things that would help determine whether a given installed plugin is out of date or vulnerable?  

If we had a list of known vulnerable plugin versions, I could include those in the response for matching mime-type & etc.  That seems like straightforward flagging and matching, unless I'm missing something.

But, for whether a plugin is out-of-date, how would version comparisons work?  I wouldn't want the service or JS lib to say a plugin is out of date, when it's actually brand new and we just haven't gotten a chance to add it to the DB yet.  Seems like every vendor has their own idea about version numbers, so I don't think they can just be compared alpha/numerically.

3) Where do we get plugin data from?  The current PFS2 database is transcribed from a pile of regexes and runs of if/else in PFS1.  Do we have someone who tracks plugin versions and vulnerabilities?  And actually, looking at the data I have available, there aren't even version numbers for most of the plugins.

I've been thinking I need to rework PFS2 a bit to accept updates as maybe simple JSON files, since updating isn't supported by it at all right now.  Would be nice if someone had that data on hand - unless it eventually turns into a research task for me.
(In reply to comment #3)
> Are you able to find all of what PFS2 accepts? Is there anything else available
> from JS that might help in identifying a plugin and whether it's out of date?
> It's been ages since I did plugin detection in a browser.

I was able to find all the inputs.

Currently used
plugin.name - "Shockwave Flash"
plugin.description - "Shockwave Flash 10.0 r12"
mime.type - "application/x-shockwave-flash"

Going off of Firefox... elements we could use, which I'm not currently using:
plugin.filename - "Flash Player.plugin"
mime.suffixes - "swf"

I think mime type is our best bet for "finding" and plugin.name for "matching".
(In reply to comment #3)
> 2) What kind of output would be helpful for the JS detection lib?  PFS2 spits
> out some JSON right now that I tried to match to the original PFS1 RDF, which I
> didn't/don't quite understand. :) Are there additional things that would help
> determine whether a given installed plugin is out of date or vulnerable?

Existing output that's needed:
version
name
url (or installer_location, manual_installation_url)

Would be useful:
list of alternate names?
either:
  * a vulnerable flag (assumes a new input of plugin name and plugin version)
  * a vulnerable field which is a list of version numbers
  * some other way to capture vulnerability
(In reply to comment #3)
> If we had a list of known vulnerable plugin versions, I could include those in
> the response for matching mime-type & etc.  That seems like straightforward
> flagging and matching, unless I'm missing something.

Yep, I like it. The client will have two matching tasks for each plugin
* match which plugin info (out of the list returned)
* match if the version number is in the vulnerable version list
(In reply to comment #3)
> But, for whether a plugin is out-of-date, how would version comparisons work? 
> I wouldn't want the service or JS lib to say a plugin is out of date, when it's
> actually brand new and we just haven't gotten a chance to add it to the DB yet.
>  Seems like every vendor has their own idea about version numbers, so I don't
> think they can just be compared alpha/numerically.

I've taken a first stab at this with my plugin name/description parser. It attempts to create a "version chain" which is a list of version elements. Elements begin with a digit and then can either be more digits, a seperator, or alpha characters.

Once you have two version chains, they are compared elementwize from head to tail.

This may be general enough to work for all cases. We can use a pre-compare
hook for out of the ordinary versioning schemes.
(In reply to comment #3)
> 3) Where do we get plugin data from?  The current PFS2 database is transcribed
> from a pile of regexes and runs of if/else in PFS1.  Do we have someone who
> tracks plugin versions and vulnerabilities?  And actually, looking at the data
> I have available, there aren't even version numbers for most of the plugins.

> I've been thinking I need to rework PFS2 a bit to accept updates as maybe
> simple JSON files, since updating isn't supported by it at all right now. 
> Would be nice if someone had that data on hand - unless it eventually turns
> into a research task for me.

Maybe we should create the unknown plugin discovery piece sooner than later to bootstrap our dataset. Can you sketch out your file format and I will add this to Perfidies, so you can easily get the file for the browser your using.
Okay, some progress on this in r51068, r51177, r51178, and r51231

I've got a demo install of things on khan, here (/etc/host entry needed):

http://pfs2.lorchard.khan.mozilla.org/

The main changes are that multiple mimetypes can be supplied in a space-separated list for the ?mimetype parameter, and you should get a list of records for known plugin releases corresponding to the parameters.  Releases with known vulnerabilities should offer properties 'has_vulnerability', 'vulnerability_url', and 'vulnerability_description'

For example, I just mocked up some data for Flash and got this:

$ echo ; curl -s 'http://pfs2.lorchard.khan.mozilla.org/?mimetype=application/x-shockwave-flash&appID=%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D&appVersion=2008052906&appRelease=3.5&clientOS=mac&chromeLocale=ja-JP' | prettyjson

[
    {
        "app_release": "3.5", 
        "app_version": "*", 
        "vendor": "Adobe", 
        "pfs_id": "adobe-flash-player", 
        "url": "http://www.adobe.com/go/getflashplayer", 
        "modified": "2009-09-10T22:19:35+00:00", 
        "app_id": "{ec8030f7-c20a-464f-9b0e-13a3a9e97384}", 
        "manual_installation_url": "http://www.adobe.com/go/getflashplayer", 
        "version": "11.0.0.0", 
        "license_url": "http://www.adobe.com/go/eula_flashplayer_jp", 
        "locale": "ja-JP", 
        "guid": "{89977581-9028-4be0-b151-7c4f9bcd3211}", 
        "xpi_location": "http://fpdownload.macromedia.com/get/flashplayer/xpi/current/flashplayer-mac.xpi", 
        "os_name": "mac", 
        "name": "Adobe Flash Player"
    }, 
    {
        "app_release": "3.5", 
        "app_version": "*", 
        "vendor": "Adobe", 
        "pfs_id": "adobe-flash-player", 
        "url": "http://www.adobe.com/go/getflashplayer", 
        "has_vulnerability": 1, 
        "modified": "2009-09-10T22:19:35+00:00", 
        "app_id": "{ec8030f7-c20a-464f-9b0e-13a3a9e97384}", 
        "vulnerability_description": "Makes your computer kick puppies", 
        "vulnerability_url": "http://google.com", 
        "version": "10.0.22.87", 
        "license_url": "http://www.adobe.com/go/eula_flashplayer_jp", 
        "manual_installation_url": "http://www.adobe.com/go/getflashplayer", 
        "locale": "ja-JP", 
        "guid": "{89977581-9028-4be0-b151-7c4f9bcd3211}", 
        "xpi_location": "http://fpdownload.macromedia.com/get/flashplayer/xpi/current/flashplayer-mac.xpi", 
        "os_name": "mac", 
        "name": "Adobe Flash Player"
    }
]
I'm going to close this bug since PFS2 exposes vulnerability info now.  We should open new bugs for further work past this
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.