Bug: Google Chrome Version Detection

Vulnerability Tests
1

Conclusion: When S/MIME is installed, openVAS mistakenly assigns the S/MIME version number to Google Chrome resulting in almost 200 false positive vulnerabilities.

I just started learning NASL yesterday, so I could be mistaken in how I am reading the code (so please help if I missed something), but I am fairly certain I have found a bug.

I am running OpenVAS scans using AV OSSIM. 3 computers registered 105 high vulnerabilities which weren’t present on the rest of the workstations. They were all related to Google Chrome.

The report stated that Google Chrome version 15.21.8108 was installed. After digging around in openVAS to figure out how it determines the version number, I found:
/var/lib/openvas/plugins/gb_google_chrome_detect_win.nasl

It appears to look for a registry key in one of two locations depending on the osArch.

if(“x86” >< osArch){
key = "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall";
}

else if(“x64” >< osArch){
key = "SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall";
}

My workstations are x64, but the Google Chrome registry key is actually stored in "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall". However, S/MIME is stored in "SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall".

The full name is “Microsoft S/MIME Control for Outlook on the web for Microsoft Edge and Google Chrome” which causes it to pass the next test in the plugin where it looks for “Google Chrome” in the DisplayName.

foreach item (registry_enum_keys(key:key))
{
appName = registry_get_sz(key:key + item, item:“DisplayName”);

if(“Google Chrome” >< appName)
{
chromeVer = registry_get_sz(key:key + item, item:“DisplayVersion”);
if(chromeVer)
{
chromePath = registry_get_sz(key:key + item, item:“InstallLocation”);

  set_kb_item(name:"GoogleChrome/Win/Ver", value:chromeVer);

  cpe = build_cpe(value:chromeVer, exp:"^([0-9.]+)", base:"cpe:/a:google:chrome:");
  if(isnull(cpe))
    cpe = "cpe:/a:google:chrome";

  # Used in gb_google_chrome_detect_portable_win.nasl to detect doubled detections
  set_kb_item(name:"GoogleChrome/Win/InstallLocations", value:tolower(chromePath));

  register_product(cpe: cpe, location: chromePath);
  log_message(data: build_detection_report(app: "Google Chrome",
                                           version: chromeVer,
                                           install: chromePath,
                                               cpe: cpe,
                                         concluded: chromeVer));
}

}
}

Because I have only been looking at NASL for one day, this is essentially where I get stuck. I am not sure how to examine if it is pulling multiple detections for Google Chrome and failing to identify the correct one. It’s also possible that because the registry key is in the wrong place, computers that do not have SMIME installed are not identifying Google Chrome at all. However, gb_google_chrome_detect_portable_win.nasl appears to use WMI to identify the version number which should be successful.

I am hoping for 2 things from this post. 1) Someone please fix this bug. 2) Please give me some more tips on investigating issues like this further.

Is there a way to identify what values are actually stored in “set_kb_item(name:“GoogleChrome/Win/Ver”, value:chromeVer)”?
Is there somewhere I can view the log_message?

log_message(data: build_detection_report(app: “Google Chrome”,
version: chromeVer,
install: chromePath,
cpe: cpe,
concluded: chromeVer));

-Ready to learn and be a contributing member.

1 Like
2

I’m new to this whole Open Source thing and realized I can fix MY plugin myself. Modified this line to read:

if(“Google Chrome” >< appName && “MIME” >!< appName)

Worked like a charm.

By the way, I’ve never seen the >< and >!< operators before. They are pretty slick.

1 Like
3

Hi and a very warm welcome to this community,

first of all: Thanks for pointing out such an issue. It’s always helpful to get some “3rd party” input, since we can’t always spot these happy little accidents when setting up and testing our scripts.

The >< operator is indeed a very helpful thing; it’s basically something like "is ‘string’ in variable" - where the variable can even be a huge blob of text. Makes it especially helpful for pattern detection.

Do note that it doesn’t work like == where you’d check if variable == "string", but the other way around, just like in the aforementioned if condition that you pointed out. Another thing to consider is that this operator is case sensitive, as opposed to =~ and !~ which are not case sensitive and also accept RegEx on the string that’s being checked.

Your fix is quite specific, though - which in your case isn’t actually a bad thing. Perhaps we can generalize it a bit more and do something like appName =~ "^Google Chrome", so we can be sure that the value has to begin with “Google Chrome”. But that is something that I will have to look into. So again, thanks!

Cheers,
Ad

3 Likes
4

For the records, an update should be already published in the feeds handling this in a better way.

Thanks again for the report.

2 Likes