5 Replies Latest reply on Apr 26, 2012 8:00 PM by montrealpaul

    False Positives with Adobe Flash

    montrealpaul

      Hello! I'm new to both MVM (version 7) and this forum, so I'll start out slow, with just one of the issues I'm having... BTW, I have looked through all 414 discussions, and did not see anything which corresponded to my issue.

       

      We have uninstalled Flash from all of our Customer's systems, using the Adobe Flash uninstaller. I've run a java script against some test stations, and it confirms that Flash is indeed not present.

       

      However, MVM still "detects" hundreds of Flash "vulnerabilities". (actually, just over 50, but multiplied by all the hosts, it amounts to over 800 instances).

       

      Here are just a few:

      (APSA11-01) Adobe Flash Player ".xls" files Denial Of Service
      (APSA11-02) Adobe Flash Player/Acrobat/Reader Doc Remote Code Execution
      (APSB10-14) Adobe Flash Player Base Buffer Overflow Vulnerability
      (APSB10-14) Adobe Flash Player Heap Corruption Vulnerability
      (APSB10-14) Adobe Flash Player Indexing Weakness Vulnerability

       

      I don't want to disable these scans, because we still want to detect hosts which were "missed", or on which Flash may somehow reappear, perhaps due to a re-installation.

       

      Thank you!

       

      -Paul

       

      P.S.: The Flash Uninstaller can be found here: http://helpx.adobe.com/flash-player/kb/uninstall-flash-player-windows.html

        • 1. Re: False Positives with Adobe Flash

          We are relatively new to MVM (we've had it for a year) and I am just now going through the false positive process with 2nd-level support.

          Based on my as-of-yet-incomplete experience, I would say the following:

           

          It's possible that MVM is detecting traces of the flash install: things left behind in the registry, or perhaps an empty directory left behind by the uninstall.  We have had the empty directory issue with a particular Adobe utility, and I suspect the registry-traces issue on another detection.  It's also possible that the flash uninstall actually leaves behind a vulnerable executable or library or something, in which case you would be dealing with an actual vulnerability.

           

          Whether you pursue a detection that seems dubious in your environment depends on the rest of your business needs.  Do you have compliance drivers?  Is your auditor going to be looking at MVM reports?  Do you have other, higher-priority issues/detections you should be focusing on?  Do you think you have strong enough evidence to make the case for a false postive with McAfee support (and the time to pursue that)?  How high a profile do you want the issue of possibly-incorrect MVM results to have in your organization?

           

          Your options include the following:

               1. Marking the dubious detections (tickets) as 'false positive' or 'ignore' for the systems where you know you don't have flash installed

               2. If you use a registry cleaner in your environment, trying that on a sample system to see if it cleans up some of your detections

               3. Pursing the false positive process with McAfee support (I'd start with just one detection, on a system where you won't be disrupting anybody else's work with your investigation.)

               4. Maybe other approaches; I hope others chime in.

           

          I would be interested in hearing where you go with this.

           

          J.

           

          Message was edited by: jldunn on 4/24/12 12:20:38 PM CDT
          • 2. Re: False Positives with Adobe Flash
            montrealpaul

            Hi, J, and thanks for your reply

             

            I will try to address all of your questions in order, inline:

             

            It's possible that MVM is detecting traces of the flash install: things left behind in the registry, or perhaps an empty directory left behind by the uninstall.  We have had the empty directory issue with a particular Adobe utility, and I suspect the registry-traces issue on another detection.  It's also possible that the flash uninstall actually leaves behind a vulnerable executable or library or something, in which case you would be dealing with an actual vulnerability.

            MP: On one test system, I removed all known traces of Flash installs; this includes ALL files in C:\Windows\System32\Macromed\Flash, as well as searched for and removed anything in the Registry containing or pertaining to Flash. To qualify this last item: I manually searched through the registry for "Adobe", "Macromedia", and "Flash", the latter of which returned many, many items pertaining to flash drives, drivers, etc, but not Adobe/Macromedia Flash. I also did a manual search for *.ocx, Flash*.*, and  NPSWF*.dll.

            MVM Still reported "vulnerabilities".

            What else could there be? What might be contained in the detection scripts, NASL, or whatever? This is apparently a deep, dark secret...

             

            Whether you pursue a detection that seems dubious in your environment depends on the rest of your business needs.  Do you have compliance drivers?  Is your auditor going to be looking at MVM reports?  Do you have other, higher-priority issues/detections you should be focusing on?  Do you think you have strong enough evidence to make the case for a false postive with McAfee support (and the time to pursue that)?  How high a profile do you want the issue of possibly-incorrect MVM results to have in your organization?

            MP: We are running MVM at the site of a high-profile Customer, and deliver the results to them on a monthly basis (as well as handle the patching/remediating itself) as part of our SLA. Every vulnerability marked "High" is considered serious, and in need of addressing.

            With all due respect, please let me be the judge of where to focus, and my ability to prioritize ... (for the record, I'm an IS professional with 30 years in IT, 12 of them in IS)

            Yes, I have strong evidence, but no, not a lot of time (and am frustrated by the need to spend this time, instead of saving it, as the promotional literature suggests I would)

            Every "False Positive" (and there seem to be many - I'm only addressing the Flash one here) makes MVM - and us - less credible in the eyes of our Customers. We don't want to MAKE it into a high-profile issue, but would rather rectify it before it becomes one.

             

            Your options include the following:

                 1. Marking the dubious detections (tickets) as 'false positive' or 'ignore' for the systems where you know you don't have flash installed

            MP: Can we mark 'false positives' on a host level, or only at the vulnerability level? The danger of disabling an alert is, similar to removing the battery from a beeping smoke detector, is that you won't know when a "real" vulnerability is present (i.e. the component somehow was re-installed).

             

                 2. If you use a registry cleaner in your environment, trying that on a sample system to see if it cleans up some of your detections

            MP: I could try that... I could set up a system to emulate the Customer's. Do you recommend a particular registry cleaner, which would have a good chance of clearing out the 'junk', plus give a report? (I wouldn't want to run a registry cleaner at the Customer's - too risky.

             

                 3. Pursing the false positive process with McAfee support (I'd start with just one detection, on a system where you won't be disrupting anybody else's work with your investigation.)

            MP: Yes... I started a call with them, jumping through a few "authentiation" hoops, but ended up having to hang up the call, after waiting on hold for a long time, because I had to go deal with other issues. I was hoping to get some support here, but you're the first to respond, after more than a week.


                 4. Maybe other approaches; I hope others chime in.

            MP: Me too!

             

            I would be interested in hearing where you go with this.

            MP:  I will definitely report my results.

             

            Thanks again for your response and suggestions!

             

            Salutations,

              -Paul


            • 3. Re: False Positives with Adobe Flash

              Paul,

               

              I thought of one other issue you may be experiencing:  If a system with vulnerabilites has been removed from the network, MVM has no way of knowing it's gone and not just temporarily down.  The vulnerabilities will remain in the database until the asset ages out.  Similarly, if a service has a vulnerability detected by MVM, and your particular remediation is to down (remove) the service rather than patching the service, then MVM has no way of knowng the service is permanently down and not just temporarily down; the vulnerability will remain in the database and show up in asset reports.  Other people may have other ways of dealing with this, but for systems that are gone, I delete the asset.  For systems that have changed what services/ports they have open, I delete the asset from MVM, and then re-scan it to re-discover it; this ensured vulnerability information is up-to-date.  You could try something like this with a test system that has flash detections but flash has been removed.


              I don't have a recommendation for a registry cleaner; i spoke to a coworker today who has used cclean.  No warranty implied; YMMV.

               

              MVM Technical support has access to FASL script information and may (or may not ) be able to provide you with an indication of what the detection script is looking for.

               

              With regards to marking vulnerabilities as false positives: if you're using the remediation/internal ticketing process in MVM (under 'tickets'), you can mark an individual ticket for an individual vulnerability on an individual host with 'ignore' or 'false positive.'  This essentially makes that designation on a per-host basis without disabling the actual vulnerability test/detection.  I am not sure how long that designation lasts, as 'stale tickets' eventually get deleted.  In any case, an 'ignored' vulnerability (via this marking) should not show up in future scan reports, although it will still show up in asset reports.  If you have the skills in house to query the DB and construct your own reports from the ticket information, that will give you a work-around for the reporting limitations.

               

              Based on my (limited) current experience with customer support, to escalate a suspected false positive, you will need to supply tech support with the following:

              1. the output from FSDiag (download this tool from McAfee) for the specific FASL script corresponding to the vulnerability in question
              2. HTML output (i.e. a scan report) from a scan of just that host
              3. Your evidence that this is (or may be) a false positive

              You can open your support ticket via phone and then attach these items to the ticket.  It also helps to have physical access or RDP access to the system in question.

               

              Do keep us posted; I am sure others can benefit from your experiences.

              J.

               

              Message was edited by: jldunn on 4/24/12 6:16:36 PM CDT
              • 4. Re: False Positives with Adobe Flash

                Hi Paul,

                 

                You can get the diagnostic tool here:

                 

                https://kc.mcafee.com/corporate/index?page=content&id=KB55996

                 

                The instructions ( solution 1, be sure to MAP the drives ) are in the above KB as well.

                 

                The script names for the vulnerabilities you mentioned above are:

                 

                (APSA11-01) Adobe Flash Player ".xls" files Denial Of Service
                >> wham-misc-adobe-flash-player-and-reader-and-acrobat-APSA11-01.fasl3

                (APSA11-02) Adobe Flash Player/Acrobat/Reader Doc Remote Code Execution
                >> wham-misc-adobe-flash-player-doc-remote-code-exec-APSA11-02.fasl3

                (APSB10-14) Adobe Flash Player Base Buffer Overflow Vulnerability
                >> wham-misc-adobe-flash-player-CVE-2010-2185.fasl3

                (APSB10-14) Adobe Flash Player Heap Corruption Vulnerability
                >> wham-misc-adobe-flash-player-CVE-2010-2162.fasl3

                (APSB10-14) Adobe Flash Player Indexing Weakness Vulnerability
                >> wham-misc-adobe-flash-player-CVE-2010-2161.fasl3

                 

                The response from the systems (in the diagnostic tool) will give you a clue what the script is keying on.  These results are what you need for any Service Request you open anyway, so it's a good start.

                 

                I'm sorry to hear about your experience over the phone.  You might try opening the ticket at:

                mysupport.mcafee.com

                or making sure to call during US Business hours.

                 

                I hope that helps!
                Cathy

                • 5. Re: False Positives with Adobe Flash
                  montrealpaul

                  Thanks, Cathy, That looks very helpful! I'll need to get some "lab time" to run this, and get back with the results.

                   

                  Thanks to you, too, J, for your additional comments and suggestions. My apologies for not responding sooner, but I've been rather swamped lately!

                   

                  Cheers!

                   

                    -Paul