Php nvt 2018 error

Mogimbo · February 1, 2019, 8:26am

Hi All,
I have 2 twin VMs.
ON 17 Jan I have done a scan on VM "A"and the result describes 2 vulnerabilities named

“PHP Multiple Vulnerabilities - Dec19 (Linux)” and
“PHP ‘CVE-2018-19935’ - ‘imap_mail’ Denial of Service Vulnerability (Linux)”

2 days ago I have updates my feed

scap
nvt
cert

and I have done a scan on VM “B” and magically vulnerabilities are not showed on this VM.
For double check I have done again a scan on VM “A” (with updated feeds) and vulnerabilities disappeared as well.

Checking on plugins, the nasl that do the check is gb_php_imap_mail_dos_vuln_lin.nasl saved in my path “/var/lib/openvas/plugins/2018/php”.
Launching this nasl with openvas_nasl it does nothing; putting some display(“Here”); in tyhe nasl to log something, I noticed that for example the variable port is not set.
Before the update it works, so my question is: anyone have noticed this?
Is there a problem in the new nasl updates?
Have I done some mistakes?
The command I used to launch manually the nasl is:

cd /var/lib/openvas/plugins/2018/php
sudo openvas-nasl -i /var/lib/openvas/plugins/ -t XXX.XXX.XXX.XXX -X -d -s gb_php_imap_mail_dos_vuln_lin.nasl

Check your path, maybe it could be different
Thank you
Giovanni

Mogimbo · February 1, 2019, 10:44am

UPDATE:
I found the way to launch correctly the NASL via CLI: i didn’t included gb_php_detect.nasl and
os_detection.nasl as specified in:
script_dependencies(“gb_php_detect.nasl”, “os_detection.nasl”);

sudo openvas-nasl -i /var/lib/openvas/plugins/ -t XXX.XXX.XXX.XXX -X -d -s gb_php_detect.nasl os_detection.nasl gb_php_imap_mail_dos_vuln_lin.nasl

So now via CLI it says I have to upgrade, but in Opevas Web Administration the vulnerability is not appeared.
Any suggestion?

cfi · February 1, 2019, 10:57am

Most “Linux” VTs which are checking for a Banner of a software (especially PHP) have a QoD of remote_banner_unreliable (See Overview on QoD values and types).

This means vulnerabilities of such VTs are not showing up by default in your reports. To show them you need to update your filter to show results for VTs having a QoD < 70 %.

Your seen difference is most likely caused by either different used filters or the manager not having build up its internal metadata database at the first scan which caused a fallback to a QoD of 75 %.

As both topics are not related to the Vulnerability Test at all i’m moving this to the GSE category for now.

Mogimbo · February 1, 2019, 11:08am

HI cfi and thank you for the answer.
I already checked my QoDs:
The min Task’s QoD is 70% and the vulnerabilities are 75%

PHP ‘CVE-2018-19935’ - ‘imap_mail’ Denial of Service Vulnerability (Linux) 75% (80/tcp)
PHP Multiple Vulnerabilities - Dec19 (Linux) 75% (80/tcp)

The remote_banner_unreliable is 30%, do this means it will not be checked?
By the way, in the previous scan, the vulnerabilities were present in the report; they disappear after my Feed status update.

Thank you
Giovanni

Mogimbo · February 1, 2019, 11:10am

UPDATE 2
After checking that NVT works via CLI, I have done a NVT rebuilt with the command:

openvasmd --rebuild --progress

and launched another scan.
I’ll wait the end

Giovanni

cfi · February 1, 2019, 11:13am

this indeed confirms my previous assumption:

Mogimbo · February 1, 2019, 12:58pm

UPDATE 3
Scan is finished and vulnerabilities are not present in the report.
I think the problem is not the database.
I try to set a lower QoD on the Task, but I don’t think this will be a solution/workaround

Giovanni

Mogimbo · February 1, 2019, 3:04pm

UPDATE4

I have create a new Task with min QoD = 29%
*I modified the nasl gb_php_mult_vuln_dec18_lin.nasl putting some “display()” like in the example:

if( version_in_range( version:vers, test_version:“5.0.0”, test_version2:“5.6.38” ) ) {
display(“trovato1”);
fix = “5.6.39”;
} else if( version_in_range( version:vers, test_version:“7.0.0”, test_version2:“7.0.32” ) ) {
display(“trovato2”);
fix = “7.0.33”;
} else if( version_in_range( version:vers, test_version:“7.1.0”, test_version2:“7.1.24” ) ) {
display(“trovato3”);
fix = “7.1.25”;
} else if( version_in_range( version:vers, test_version:“7.2.0”, test_version2:“7.2.12” ) ) {
display(“trovato4”);
fix = “7.2.13”;
}

And he prints in openvassd.dump 1 of the “trovato”, so it means he recognize the version and the vulnerability.
But in the vulnerabilities report, it’s still absent.
One thing I don’t understand is that the vulnerability has a QoD about 75, but in nasl I have seen

script_tag(name:"qod_type", value:"remote_banner_unreliable");

I also tried to modify in

script_tag(name:"qod_type", value:"remote_analysis");

But with no success…
Where I’m wrong?

Thank you
Giovanni
`

cfi · February 4, 2019, 7:34am

An explanation for this was given previously twice:

The previously used openvasmd --rebuild probably has corrected this.

An explanation for this was given previously as well:

If you want to understand the concept of the “QoD” please have a look at the previously posted resource here:

https://docs.greenbone.net/GSM-Manual/gos-4/en/glossary.html#quality-of-detection-qod

as well as the “Report Filtering.” picture in:

https://docs.greenbone.net/GSM-Manual/gos-4/en/vulnerabilitymanagement.html#reports-section

Mogimbo · February 4, 2019, 9:34am

Hi cfi and thank you for the answer:

this indeed confirms my previous assumption:

cfi:
or the manager not having build up its internal metadata database at the first scan which caused a fallback to a QoD of 75 %.
The previously used openvasmd --rebuild probably has corrected this.

I have done the rebuild, but the Vulnerability’s QoD is still 75%

An explanation for this was given previously as well:

cfi:
This means vulnerabilities of such VTs are not showing up by default in your reports. To show them you need to update your filter to show results for VTs having a QoD < 70 %.

I created a Task with min QoD=29% but the vulnerability still not appear in the report.
Now I have created a Task with QoD=10%, I’ll post the result after it finish.

Anyway, after the rebuild, nothing has changed for now.
But if the vulnearability still remain with a 75% QoD, should be it present in the report?
I have read the document u sent (thank you, they are very useful), but I still don’t understand why vulnerability are not visible in the report.
Should I miss something?

Thank you for your time.
Giovanni

Mogimbo · February 4, 2019, 10:42am

Hi.
the task with QoD=10% is finished and the vulnerability is not visible in the report
Here the screenshot about my task:
Scan

My new question is:
In the task report, I have the vulnerability “PHP Multiple Vulnerabilities - Dec19 (Linux)” with a QoD=75% but in NVT the same vulnerability has QoD=30%

IMG abount report

IMG about NVT

Which are the differences?

Thank you
Giovanni

bricks · February 4, 2019, 10:51am

It may be possible that the report details view applies a different min qod filter. You should try to add min_qod>=30 or similar to the powerfilter at your report details page.

Mogimbo · February 4, 2019, 11:01am

Hi bricks and thank you for the answer,
I modified the report QoD to 28% and now the vulnerability appears.
But this cause a lot of questions

Why in the previous report it showed the vulnerability? (I didn’t modified nothing)
As you can see in the screenshot, the “PHP Multiple Vulnerabilities - Dec19 (Linux)” has a 75% QoD, instead the other 30%. Is this an error?
the other vulnerability that has QoD=75% is “PHP ‘CVE-2018-19935’ - ‘imap_mail’ Denial of Service Vulnerability (Linux)”: this is the other vulnerability that has the same visibility problem

Thank you
giovanni

bricks · February 4, 2019, 11:08am

I suppose this report was created before

as @cfi already wrote. That means the min qod seems to be preserved for a report and isn’t updated afterwards. Because each report should never update its data surprisingly this behavior is intended.

Mogimbo · February 4, 2019, 11:19am

Hi bricks,

The behavior may seem surprising but have you any idea to solve this?
I tried openvasmd --rebuild as suggested but, surprisingly, it doesn’t resolve the problem…

Now I tried to update again the feed with:

sudo greenbone-scapdata-sync
sudo greenbone-nvt-sync
sudo greenbone-certdata-sync
sudo openvasmd --rebuild --progress

Now I’ll launch again a test and I hope this solve
Thank you
Giovanni

Ps.

I suppose this report was created before

No this screenshot is done 20 min ago, after @Cfi answer

bricks · February 4, 2019, 11:24am

As I said old reports wont change. Their data will not be updated if the corresponding scan is finished.

But you should get the correct QoD for new scans and therefore for new reports.

bricks · February 4, 2019, 11:27am

It may be possible that the scanner still uses the old data. There should be some command line switch to update its data too. Can’t remember the exact command currently.

Mogimbo · February 4, 2019, 11:28am

Hi bricks,
sorry for the misunderstanding: these are NEW scans.

It may be possible that the scanner still uses the old data. There should be some command line switch to update its data too. Can’t remember the exact command currently.

I’ll try to find.
thank you

Giovanni

Mogimbo · February 4, 2019, 1:21pm

Solved updating feed again…

bricks · February 4, 2019, 1:26pm

In OpenVAS/GVM 9 greenbone-nvt-sync sends a signal to openvas scanner to reload the nvts at the end (normally). This may have solved your issues.