Possible False Positive on gmp package?

Vulnerability Tests
1

Hi! I would like to get some opinions/checking on what I encountered upon scanning an AWS Linux server. I already posted this on stackexchange.

We have an Amazon Linux server and we scan it using OpenVAS. It detected one high vulnerability which is Amazon Linux Local Check: alas-2016-754 .
Looking at the solution it says Run yum update php70 to update your system.
The vulnerable package detected is:
Vulnerable package: gmp
Installed version: gmp-6.0.0-11.16.amzn1
Fixed version: gmp-7.0.11-1.16.amzn1

At first we don’t have php installed. So what we did is install latest version of php. Upon running the suggested solution the result is “No packages marked for update”.
We also did yum update.

After doing another scan the package is still detected by OpenVAS.

We installed the latest gmp version which is php70-gmp7.0.33-1.32.amzn1.x86_64 but it still gets flagged by OpenVAS.
What could possibly be the problem behind this? or what other ways that we can verify that this is a false positive?

2

Hi and thanks for your report.

It seems this (and all other Amazon Linux LSCs) got created and submitted by a 3rdparty contributor some years ago.

When comparing the code of the problematic 2016/alas-2016-754.nasl with other PHP related LSCs created for Amazon Linux like e.g. the one in 2016/alas-2016-698.nasl it seems the Generator used by this contributor is / was buggy and created a wrong version checks like e.g.:

  if ((res = isrpmvuln(pkg:"gmp", rpm:"gmp~7.0.11~1.16.amzn1", rls:"AMAZON")) != NULL) {
    security_message(data:res);
    exit(0);
  }

which should have been generated like e.g.:

  if ((res = isrpmvuln(pkg:"php70-gmp", rpm:"php70-gmp~7.0.11~1.16.amzn1", rls:"AMAZON")) != NULL) {
    security_message(data:res);
    exit(0);
  }

The Amazon Linux LSCs affected by this bug got updated accordingly and should be shipped in the feed with one of the next feed updates (The Amazon Linux Local Check: alas-2016-754 VT should have version 2019-07-02T09:11:25+0000 which is the fixed version).

Please let us know if this is solving your seen issue.

1 Like
3

Including alas-2016-754, we’ve got the same result for alas-2016-753 and alas-2016-706. It’s the same issue here for this VT?

4

Sorry I got confused.
What step should I take now to fix this? update my NVT feeds?

5

Yes, or you wait for the automatic feed update to occur.

1 Like
6

Yes, indeed. Besides alas-2016-754 the other two alas-2016-753 and alas-2016-706 had the same problem and where updated as well.

While updating the mentioned VTs i had also noticed that the following MySQL related VTs had the same issue and updated them as well:

alas-2016-701.nasl
alas-2016-707.nasl
alas-2016-728.nasl
alas-2016-737.nasl
alas-2016-738.nasl
alas-2016-756.nasl

There might be even more VTs which could have the same issue, if you’re facing similar problems with other products please let us know.