1

I have a machine which does not have Google chrome installed but when I try to scan it using Nexpose and Retina all the Chrome related vulnerabilities are listed in the report and it shows it as vulnerable.

Has anyone else faced this issue? Am I missing anything here?

guntbert
  • 1,963
  • 2
  • 18
  • 21
Hammad Qureshi
  • 11
  • 1
  • I've run into similar problems with Retina. At the time I experienced the issue (6ish years ago), Retina was using regex on file/path names to target files. After an policy update, all of my workstations were reporting this XML vuln. After finding the regex, I spot-checked it against some files and they returned as bad so then I looked up the CVE id against what is actaully vulnerable and the version of the file I had was way past the vulnerable version. I ran the scan with another scanner without the update and it did not flag--bug in the regex. Verify the check vs the result. – thepip3r Jan 02 '19 at 20:10
  • Do the tools show what made them trigger? It's possible other software has installed Chrome as a dependency. – paj28 Jan 02 '19 at 20:33
  • I tried running a full audit scan in Nexpose. i am not sure where can i find the regex on Retina. – Hammad Qureshi Jan 03 '19 at 07:50

1 Answers1

2

Check which files are reported as vulnerable. There are a lot of programs that embed significant chunks of Chrome - not the actual browser window (the "chrome") but the rendering engine, JS, engine, the sandboxing framework, possibly the Google account stuff (in other words, the parts that are actually likely to have vulnerabilities), and it is possible that the scanner is noticing these things. For example, CEF (Chromium Embedded Framework) is pretty common in a lot of software that wants to make a desktop version of what was originally written as a web app, but CEF components need to be kept up to date as bugs are found and patched in the Chromium code from which they come.

Of course, most apps that embed Chrom(e|ium) components are only using them to render a very limited selection of content, so the risk is generally a lot lower (harder for an attacker to slip malicious script into a dedicated app that only loads scripts from its one server than into a web browser that loads scripts from literally anywhere).

CBHacking
  • 48,401
  • 3
  • 90
  • 130