Mailing List Archive: Low Priority: Changing output to security

Low Priority: Changing output to security_notice in showmount.nasl (#10437)

Feb 19, 2005, 1:55 PM

Post #1 of 4 (773 views)

Hello All,

To follow previously discussed consistencies, could a couple
security_warning's in showmount.nasl (10437) be changed to
security_notice's?

Below is the code snippet containing the two I think needing
adjustment. Both only inform of an NFS server that does not export
files. A superfluous service should not cause a warning.

Thanks,

Jon

showmount.nasl:

else
{
report = string("You are running a superfluous NFS daemon.\n",
"You should consider removing it\n");
security_warning(port:2049, data:report, proto:proto);
exit(0);
}
}
else
{
report = string("You are running a superfluous NFS daemon.\n",
"You should consider removing it\n");
security_warning(port:2049, data:report, proto:proto);
}
}

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Re: Low Priority: Changing output to security_notice in showmount.nasl (#10437) [ In reply to ]

mikhail at nessus

Feb 20, 2005, 2:51 AM

Post #2 of 4 (752 views)

Permalink

On Sat, 2005-02-19 at 12:55 -0800, Jon Passki wrote:
> Below is the code snippet containing the two I think needing
> adjustment. Both only inform of an NFS server that does not export
> files. A superfluous service should not cause a warning.

Mmmhhhh... An unused service is a potential hole, isn't it? Removing it
hardens the system. I agree that a NFS server that exports directories
is more dangerous than one that does not export anything, but it is
useful (or at least should be used), so we cannot close it.

Maybe we should agree on a precise definition of what should be
security_note, warning and hole, and also the "risk level". This dead
horse has been beaten many times on the mailing lists, but it is not yet
clear.

IMHO:
- a note should be informative only. e.g. for a complete audit. You
might decide that some things should be closed because there are useless
or against your policy, but Nessus cannot chose.
- a warning should be a potential hole, a weakness. A superfluous
service might fit. Predictable IP IDs or accepting source routed packets
might fit too: there are not a hole by themselves, but might allow some
attacks in some precise situation (stealth scan...)
- a hole should be a real weakness (or a false positive alerts).
The border is fuzzy. For example, giving too much information (through
SNMP, or by displaying the web root of your server) might be a "warning"
or a "hole" (if the data is considered confidential?)

Said in another way, grep the "holes" from a report and give them to the
IT team ("patch that")

Re: Low Priority: Changing output to security_notice in showmount.nasl (#10437) [ In reply to ]

cykyc at yahoo

Feb 21, 2005, 9:42 AM

Post #3 of 4 (748 views)

Permalink

--- Michel Arboi <mikhail@nessus.org> wrote:

> On Sat, 2005-02-19 at 12:55 -0800, Jon Passki wrote:
> > Below is the code snippet containing the two I think needing
> > adjustment. Both only inform of an NFS server that does not
> export
> > files. A superfluous service should not cause a warning.
>
> Mmmhhhh... An unused service is a potential hole, isn't it?
> Removing it
> hardens the system. I agree that a NFS server that exports
> directories
> is more dangerous than one that does not export anything, but it
> is
> useful (or at least should be used), so we cannot close it.
>
> Maybe we should agree on a precise definition of what should be
> security_note, warning and hole, and also the "risk level". This
> dead
> horse has been beaten many times on the mailing lists, but it is
> not yet
> clear.
>
> IMHO:
> - a note should be informative only. e.g. for a complete audit.
> You
> might decide that some things should be closed because there are
> useless
> or against your policy, but Nessus cannot chose.

Agreed!

> - a warning should be a potential hole, a weakness. A superfluous
> service might fit. Predictable IP IDs or accepting source routed
> packets
> might fit too: there are not a hole by themselves, but might
> allow some
> attacks in some precise situation (stealth scan...)

Well this relates to another thread that's active on nessus@ on
what a vulnerability can produce and how to adequately describe
that. I consider predictable IP ID's in the same class as
recursive/indirect resource usage (proxy HTTP, recursive DNS, etc).
I'm able to use it against a different target, which I consider a
risk, too.

> - a hole should be a real weakness (or a false positive alerts).
> The border is fuzzy. For example, giving too much information
> (through
> SNMP, or by displaying the web root of your server) might be a
> "warning"
> or a "hole" (if the data is considered confidential?)

This really relates to the thread on nessus@list.nessus.org with
the subject "Nessus Risk Rating Discussion Part Deux". Check it
out!

> Said in another way, grep the "holes" from a report and give them
> to the
> IT team ("patch that")

Of course :-)

Jon

__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail

Re: Low Priority: Changing output to security_notice in showmount.nasl (#10437) [ In reply to ]

mikhail at nessus

Feb 27, 2005, 6:30 AM

Post #4 of 4 (760 views)

Permalink

On Mon Feb 21 2005 at 17:42, Jon Passki wrote:

> Well this relates to another thread that's active on nessus@ on
> what a vulnerability can produce and how to adequately describe
> that. I consider predictable IP ID's in the same class as
> recursive/indirect resource usage (proxy HTTP, recursive DNS, etc).
> I'm able to use it against a different target, which I consider a
> risk, too.

Recursive DNS does not fall in this class: it might be used to poison
_your_ cache.
Anyway, I see the point. The notion of danger against a third party
looks interesting.