> -----Original Message-----
> From: [email protected] [mailto:openvas-plugins-
> [email protected]] On Behalf Of Thomas Reinke
> Sent: Thursday, June 03, 2010 12:13 AM
> To: [email protected]
> Subject: Re: [Openvas-plugins] SSH multiple ports issue
>
> Chandrashekhar B wrote:
>
> > We removed the connection reuse in ssh_func.inc and directly went with
> > creating as many new sockets required and closing them as the job is
> > done, it seems to work fine, login works for both the ports and the
> > local checks work. But, another issue, all of the local checks report
> > the security issues as security_hole(0), not to the specific port. So,
> > even if there are multiple ports, the report is combined into general
> > category, not reported against the respective port.
> >
> > I propose to get rid of the shared socket implementation in ssh_func.inc
> > (performance is same with/without in our testing) and also update the
> > SSH based local checks to report against the respective SSH port than
> > against 0. Nowhere we are using shared socket approach in the Plugins.
> > Any issues with this approach? Any better suggestion?
>
> The issue I see that makes it a non-trivial excercise is breaking the
> assumption that there is only one set of KB information (host type,
> package lists, etc.) for a given host.
>
> If you are going to report against a specific SSH port, are you going
> to allow for two distinct sets of package information? (E.g. port
> 22 is the localhost, but port 2222 was forwarded to a different system).
Yes, this was the problem reported. I think when you are scanning a public
IP, it is a valid scenario.
> If so, you'll need to overhaul how gather-package-list.nasl records
> its package information to allow for this scenario (probably imbedding
> port info into the kb key), and update all pkg-lib-*.inc functions
> accordingly. You'll then further have the
> problem that when you record the "security_hole(0)" within the LSC
> itself, you won't know which port is relevant. And given that you
> don't know unless you have retrieved it first (which means modifying
> all the scripts), it also means that you probably have to change each
> and every call to every "isrpmvuln" type function call to specify
> which port you are checking. So you're doing a massive update to
> all scripts to change each and every function call, just so that you
> can update the security_hole(0) call at the bottom of the function.
Yes, we need to update gather-package-list and all the current local
security checks (10000+) which is a very tedious process.
>
> On that last part, you may be better off to leave the security_hole()
> call within the LSC as is, but focus on the security_note() call
> within the isPKGvuln() calls. Within those, you could bury all
> port specific handling. If you DID make any changes to the base
> LSC, I'd probably argue to simply delete the security_hole() call,
> leaving the reporting of the vulnerability to the actual isPKGvuln
> calls and be done with it.
Which also means modifying all the LSC's to call a different isPKGvuln()
which now includes a port and deleting security_hole() in LSC's.
Did I miss something?
>
> I may have been tunnel visioned with a solution here - if there's
> something cleaner that can be done, I'd love to see it.
Yes, a cleaner solution would be great which doesn't require updating all
the LSC's.
Chandra.
>
> Thomas
> _______________________________________________
> Openvas-plugins mailing list
> [email protected]
> http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins
_______________________________________________
Openvas-plugins mailing list
[email protected]
http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins
