Re: [Database-devel] questions...

Jeff Dell wrote:

> I found the problem I am having... It looks like I am getting a SIGSEGV
> error on line 802 of save_db.c when using nessuswx and not storing anything
> in the knowledgebase or vulnerability tables. It worked fine with the

That's strange.... it says:

     798   /* iterate through the KB */
     799   while ( key->next != NULL ) {
     800
     801     /* this is vulnerability data sent to the client */
     802     if ( strncmp( key->name, "SentData", 8 ) == 0 ) {
     803       int plugid       = 0;
     804       int risk         = 0;
     805       int execution_id = 0;

Maybe that SIGSEGV happens because key == NULL ? Can you change line 
799 to
	while ( key != NULL && key->next != NULL ) {

And see if still segfaults?

> standard nessus client. The tables userlist and usersession are still not
> being populated though.. I didn't find any code for this either.. Did I miss
> something or has it not been implemented yet? 

It has not been implemented yet.

> 
> One last question... There are a few tables in the perl script that are not
> created with nessusd. Have they just not been implemented yet? Or are they
> part of an old schema?
> 

Those are there in order to be able to generate more detailed reports. 
  Currently all the vulnerability information is taken from what 
Nessus provides in the KB, but there's certainly more vulnerability 
information in the plugins themselves.

Also the schema has been thought out in order to provide some way to 
maintain a list of older plugins/revisions. This yas _not_ yet been 
implemented.

If you take a look at the current code the pluginid is not extracted 
from the 'Plugin' table but, instead, is based on the Nessus 
script_id. Making it able to extract the current pluginid based on the 
'Plugin' table would be more complex but it would introduce a way to 
generate the _exact_ report that was generated, say, a year ago when a 
scan was run.

This covers the case of running a scan, storing the information in the 
database, updating the plugins and having the need to restore the 
report as it was before the plugins were updated. It also provides a 
way to be able to determine if new vulnerabilities are being detected 
because they are _new_ in the scanned host or because the plugin has 
been updated or a _new_ plugin is introduced (when updating). Consider 
the following (alternative) case:

0.- Update the Nessus plugins
1.- Scan host A, returns report with N vulnerabilities.
(time passes by....)
2.- Update the Nessus plugins
3.- Scan host A, returns a new report with M vulnerabilities.

Now, if N > M this can be because:

a) The host has changed and now is more vulnerable than it was before
b) The plugins have changed (bug fixes) and are now able to properly 
detect a vulnerability that _were_ present before and were known when 
it was first scanned.
c) There are new plugins that are now able to detect a vulnerability 
that _was_ present before but was unknown when it was first scanned.

A security team would act differently, presumably, in either case. a) 
might mean you have to determine what has changed in the host. b) 
means you have to schedule a patch fix for the host, c) means you have 
to schedule a (probably) more urgen patch fix for the host (because 
the vulnerability has been open for more time that it might be 
reasonable, for example)

There's currently no way to do this, but it's a very important feature 
for enterprise scans and that's why its designed in the schema.

Hopefully this rant (sorry :-) has explained why there might be 
significant differences between the documented/designed schema and the 
current implementation. It will take some time for the implementation 
to fill all the gaps, and more code will need to be developed to 
implement the design or the design will need to be change if it's 
determined that it's good in theory but not so in practice (cannot be 
implemented, leads to scans that are too heavy in the database, the 
SQL queries are way too complex, etc.)

Regards

Javi
_______________________________________________
Nessus-devel mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus-devel