1053417 - Adobe Reader for Windows - plugins vulnerable 2014-08-12 - APSB14-19

Status: RESOLVED FIXED

(Plugin Check Graveyard :: Database, defect, P1)

Description

[DJ-Leith]

Security Updates available for Adobe Reader and Acrobat
Release date: August 12, 2014
Vulnerability identifier: APSB14-19
http://helpx.adobe.com/security/products/reader/apsb14-19.html

> Adobe has released security updates for Adobe Reader and Acrobat XI (11.0.07)
> and earlier versions for Windows. These  updates address a vulnerability that
> could allow an attacker to circumvent sandbox protection on the Windows
> platform.  Adobe Reader and Acrobat for Apple's OS X are not affected.
... lower down

> For users of Adobe Reader X (10.1.10) and earlier versions for Windows,
> who cannot update to version 11.0.08, Adobe has made available version 10.1.11.
This ESR version would be for bug 986588
I don't think the 'detection and reporting of the ESR verson of Adobe reader'
is working on the 'Plugincheck service' but I think is should. 

Please add the plugins to the Database.

DJ-Leith

Comment 1

[DJ-Leith]

Attachment: Plugincheck-Screenshot-Win7-Fx31-After-Flash-Before-Reader-update-shows-Reader-WRONG-20140819.png

"Plugincheck-Screenshot-Win7-Fx31-After-Flash-Before-Reader-update-shows-Reader-WRONG-20140819.png"

I have not been able to test this until today because I had already
updated Reader before I started to collect evidence (on 13th July).

We are getting this WRONG result for Reader.

DJ-Leith

Comment 2

[DJ-Leith]

See 
https://bug1053417.bugzilla.mozilla.org/attachment.cgi?id=8475528
"Plugincheck-Screenshot-Win7-Fx31-After-Flash-Before-Reader-update-shows-Reader-WRONG-20140819.png"
which I attached in comment # 1.

Here "Adobe Acrobat" (AKA Adobe Reader) version "11.0.7.79" is reported as "Up to Date".
This is WRONG.  It should be "vulnerable".

This is a 'false sense of security'.

From comment # 0
> Please add the plugins to the Database.
Has anybody updated the Database for Reader (as in comment # 0)?


I can't test this as I have now completed the updating of all the
PCs that I support - all now have "Adobe Reader XI 11.0.08"
which Plugincheck (on Fx 31) reports as "11.0.8.4".

DJ-Leith

Comment 3

[DJ-Leith]

Once you have updated the Database, while you are still thinking about Adobe Reader,
please consider the following: 

On 2014-08-13, in bug 1020133 comment # 19, I posted this 'correct' result
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8472634

for what I did see AFTER I had updated
BOTH Adobe Flash (see bug 1053409 for updating the Database for Flash) and
Adobe Reader (this bug).

As you can see, Adobe Acrobat / Adobe Reader the version is "11.0.8.4" - which 
is CORRECT for "Up to Date".


Also, as is illustrated in bug 1020133 "Improve Adobe Acrobat plugin reporting", the results for
'Plugincheck - using enumeration - on Release (Fx 31)' are fairly good.

However, the results for
'Plugincheck - using JSON list - Fx 32+'
are NOT accurate for Reader.

It is the inconsistent results, with the inconsistent 'names for Reader', in the
inconsistent section of the 'report';
e.g. "Outdated Plugins" vs "Potentially vulnerable plugins" in e.g.
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8472629

Flash was a vulnerable version (so this is correct for Flash when this screenshot was taken).
Reader was NOT, it had been updated to 11.0.8.4, and so the result for Reader is WRONG.


A further issue is being reported in bug 1023718
"Plugin checker for newly installed FF 30.0 shows Adobe Acrobat plugin "vulnerable"
but update button just reloads plugin checker"

DJ-Leith, in bug 1023718 comment # 10 (about possible duplicates) said:
> Bug 1023653 "Adobe Acrobat plugin on Windows detected as Mac, can't update" 
> Schalk, bug 1023653 comment # 4 has useful data from the JSON list.

In bug 1023718 comment # 13, there is now a reporter (rapier216) who is using
Fx 32 (i.e.) Beta and Windows who is also affected by the
"Adobe Acrobat NPAPI plug-in" - to use the name as reported in the Screenshot
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8472629


I believe that a key point to consider when trying to explain
'How are we getting DIFFERENT results for the same Reader plugin?'

Is to ask yourself
'How are we getting ANY results?'

With
'Plugincheck - using enumeration - on Release (Fx 31)'
you

1.  Find the plugins (using the JavaScript at Plugincheck to enumerate the
visiting browser's plugins).
This will find "Adobe Acrobat".

2. THEN, for each 'detected plugin', test to see if they are "Up to Date" etc.

3. Then report.


With
'Plugincheck - using JSON list - Fx 32+'
you

1.  Use the JSON List.

2.  If any match, then test to see if they are "Up to Date" etc.

If the JSON List [1] has BOTH 

>  "adobeformacreaderfround": {
>      "display_name": "Adobe Acrobat NPAPI Plug-in",
>      "description": "Adobe Acrobat NPAPI Plug-in",
and
>  "adobe-reader": {
>      "display_name": "Adobe Reader",
>      "description": "Adobe PDF Plug-In For Firefox and Netscape",

Which one is tested?
What versions is 'the Plugincheck Service' using to assess the plugin?

We ARE seeing "Adobe Acrobat NPAPI Plug-in" in the screenshots,
these are the WRONG results.

I think what needs to be improved is making sure that you also assess the OS.

So for Mac, perhaps use the
>  "adobeformacreaderfround": {
section?

For Windows, perhaps use the
>  "adobe-reader": {
section?

For Linux I can't remember (is there a version?).

DJ-Leith


[1]
The full JSON list is here.
https://plugins.mozilla.org/en-us/plugins_list.json
I use Scratchpad, Pretty Print, to look at it.

For
>  "adobeformacreaderfround": {
look at line 61 onwards.
For
>  "adobe-reader": {
look at line 1603 onwards.

Comment 4

[Schalk Neethling [:espressive]]

Thanks for the info DJ, I am looking into all of this today. I have been pulled to another project for a while and had no time to look at this.

Comment 5

[Schalk Neethling [:espressive]]

The database has now been finally updated. One thing I have noticed though is that in the database we have, for example, a version such as 11.0.7.0 but, in the security bulletin by Adobe they refer to it as 11.0.07 and that the update is 11.0.08

Now I wonder is this an anomaly such as with java version that all start with 1. or do we actually have the version numbers wrong in the database?

Comment 6

[Schalk Neethling [:espressive]]

Hmmm, looking at what is reported by the browser, it is neither 11.0.0.7 nor 11.0.07 but in fact 11.0.7

Comment 7

[Dan Pernokis]

This problem persists as Bug #1068357.  Adobe 11.0.08 (11.0.8.4) has just been superseded by 11.0.09 (11.0.9.29), but 8 still shows as "up-to-date" in the plugincheck on FF 32.0.2 release.

And re Comment #5 and Comment #6:  I posted a comment previously in Bug 1038685 (re VLC plugin in a similar situation) -- my guess that the extra digit looks to be a 'file version' on the release, since it is part of the metadata (Windows file directory info):

>> The metadata for npvlc.dll says "2.1.0.0".  So the plugin file's metadata contains the 
>> trailing ".0" -- makes sense, so they can build/create and issue several renditions of 
>> a file without changing the inherent version ID.

So for Adobe, "11.0.9" would be the version of the plugin (nppdf32.dll) accompanying Adobe Reader XI version 11.0.09 -- and it happens that this is the 29th issue/build/whatever of the file under that version, hence "11.0.9.29".  The "29" does not appear anywhere in the plugin file if you look with an appropriate text-type viewer.  (Previously 11.0.8.4 -- and the 4 didn't appear anywhere else.)

Comment 8

[javascriptjedi]

This is still broken.  I have Acrobat 11.0.6.70 installed (as reported by Plugin Check), but it's reported in green as "Up to Date" (FF33 and FF31 ESR, Windows 7 x64).  This is wrong - spectacularly so since there are 3 newer versions (11.0.9 is current).  It's absolutely critical to be able to trust Plugin Check or it's worthless, since we then have to go somewhere else to "really" check or risk malware/viruses.

Is it really that hard for Mozilla to have one machine configured for automatic updates of these products that can be configured to report the versions?

Comment 9

[DJ-Leith]

(In reply to javascriptjedi from comment #8)
> This is still broken.  I have Acrobat 11.0.6.70 installed (as reported
> by Plugin Check), but it's reported in green as "Up to Date" (FF33 and
> FF31 ESR, Windows 7 x64).  This is wrong - spectacularly so since there
> are 3 newer versions (11.0.9 is current).  It's absolutely critical to
> be able to trust Plugin Check or it's worthless, since we then have to
> go somewhere else to "really" check or risk malware/viruses.

I agree.
"It's absolutely critical to be able to trust Plugin Check or it's worthless".

This has been my main motivation for putting in so much time in reporting
issues as the 'Plugincheck Service' has been developed in 2014.

However, the whole development of the 'Plugincheck Service' in 2014 has turned
out to be more difficult do; compared to what some people were anticipating,
back in December 2013.

See bug 956905 comment # 148 onwards for background and 'unofficial terms'
that I will use (and have used - above) in this bug.

Since May 2014 we have had the 'Plugincheck Website' using TWO methods
to 'do the plugincheck':

* Release (now Fx 34) using plugin enumeration and
* Beta, Aurora and Nightly using the 'JSON List'.
  The 'JSON List' went live on 2014-05-12.

As each version of Fx (e.g. Fx 31, 32 etc) has been released the code to
'detect the User Agent' of the visiting browser at 'Plugincheck Website'
has been bumped on.

Since 2014-05-14 (see bug 1010132 comment # 7) the 'reporting of Adobe Reader',
using the 'JSON List' method, has been inaccurate.

***
Note: bug 1020133 is the main bug for "Improve Adobe Acrobat plugin reporting".
***

Since 2014-11-24
  (see bug 1020133 comment # 85
   and bug 1101613 "PluginCheck Database Clearance")
there have been at least one 'change to production'
which has resulted in 'more odd results seen'.

It seems to me that the 'Plugincheck Website' is using, since 2014-11-24,
a combination BOTH methods.

The 'Plugincheck Website' is showing data from the 'JSON List', if you use
Fx 35+, BUT 'enumeration of plugins is needed to get any result';
so a combination of 'both methods' is being used.

Some of this is quite difficult to notice (for an example, see bug 1105312).


javascriptjedi,
please can you attach a screenshot of one of your tests.
Please say which version of Firefox you were using and the date of your test.


(In reply to javascriptjedi from comment #8)
> Is it really that hard for Mozilla to have one machine configured for
> automatic updates of these products that can be configured to report the
> versions?

Yes, this would be good to do as well.
See also bug 850992 "Automate Plugincheck Script running on the Server to
detect newest versions."

However,
possibly even harder to do is 'keep some old plugins for testing'.
Recently, I have deliberately not updated Flash so that I have a
'vulnerable plugin to use in tests' (see bug 1084537).


javascriptjedi, your report of "11.0.6.70" being reported as "Up to Date" - in ERROR
is very important and harder to test if one 'keeps plugins updated'.

DJ-Leith

Comment 10

[Schalk Neethling [:espressive]]

I am just giving a general status update here, and will copy this over to any other relevant bugs where a needinfo request has been logged for me.

For the past quarter i.e. 1024-Q4, plugincheck has not been on my radar in any way, shape or form as I was moved to work on another project and 100% of my time was assigned to it. I have kept my eye on bugs etc. that has come an gone and have had the service in the back of my mind though and, from what I have seen this service is still very important to users and Mozilla for a variety of reasons which I will not go into here.

With all of that said, during this time there was also some out reach done to other groups within in Mozilla to take over part, or all, responsibility for plugincheck but, as of right now, there has been no takers.

AS I mentioned though, I completely understand and appreciate the importance of this service and, I also acknowledge that in it's recent, and current state, it does not provide the 'answers' users need but, I am moving pluginchck back as a top priority for myself in Q1 of 2015 and I am currently in the progress of planning for the year in general and then for Q1 specifically.

I want to open this up to the user base to get your input on what is important and the biggest pain points but, have not decided how I will do this.

Once all of these ducks are in a row, I will post a message to either a specific bug, to yammer or both. Please except my apologies for the steady decline of this service, thanks for your patience and continued feedback and I am certain that plugincheck is going to turn the corner in a positive way in 2015.

Comment 11

[Dan Pernokis]

>> I have also posting this to Bug 1020133.

I recently upgraded FF to 34.0 (on 01-DEC-2014, the day of release, I believe).  At that time, the plugin check (TOOLS menu) said everything was "up to date".  (The VLC "2.1.3" plugin comes up "vulnerable, but I really have 2.1.5 which is the latest.)  On 07-Dec-2014, I updated TB to 31.3.0, and at that time all plugins were still showing "up to date" (except VLC).

Late evening 10-Dec-2014 (crossing midnight Eastern Standard Time here in North America), I was doing a wide range of updates on the laptop.  I had checked FF and TB earlier -- both latest versions and all plugins up to date.  I updated Windows, which rebooted and triggered version checks of Adobe AIR and FLASH PLAYER.  Both had updates available.  (AIR is not reported by plugin-checker; FLASH had shown OK.)  I updated both, and plugin check showed all up-to-date.  THEN I checked Adobe READER -- it had Update 11.0.10 available.

Next morning, I updated the Tower -- FLASH was now correctly showing "vulnerable".  But I also noticed something really odd:  the "Adobe Acrobat" (nppdf32.dll) being reported was "9.5.5.316" -- the version for the genuine Acrobat PDF Creator program (which it never reported before) -- and it DID NOT report the version of READER at all, even though the ADD-ONs MANAGER clearly showed both installed.  I confirmed this behaviour on the Laptop too.  

Recall some time ago we discussed this situation -- my Acrobat PDF Creator is old, and its plugin (a copy of the same for READER back at 9.5.5) is in a different location.  Looks like the READER location is not being looked at now by plugin-check.

To recap:  Adobe Flash was reported late, Adobe Reader isn't being checked at all (unless once it sees the Acrobat version, it skips the Reader one).

And just for the record:  The proper nppdf32.dll plugin verbally describes itself as "Adobe Acrobat 11.0.10.32" and "Adobe PDF Plug-In For Firefox and Netscape 11.0.10" -- the key word being "Acrobat", whether used for Reader or genuine Acrobat.  The same plugin is used by both Acrobat and Reader (and AIR, for that matter) -- same file, but from different locations.  My Reader is current, so plugin-check should find and report the 11.0.10 file (same as AIR).  My Acrobat is old, only 9.5.5, and that gets reported.  But the report shows only the 9.5.5 file, not both.