From timb at nth-dimension.org.uk Mon Jun 18 19:42:26 2007 From: timb at nth-dimension.org.uk (Tim Brown) Date: Mon, 18 Jun 2007 18:42:26 +0100 Subject: [Openvas-plugins] New plugins Message-ID: <200706181842.27379.timb@nth-dimension.org.uk> Ok, so after hacking around with the web site a little and attempting a build on a clean VM image, my thoughts are turning to the plugins which are in urgent need of update to check for new vulnerabilties. Some thoughts from an initial perusal of the tree: Merging the local checks for each platform? This can be done, and in fact I think these checks could be built in an automated fashion, at least on Debian. What do people think? Web application checks appear to be tested rather arbitrarily, with some checks within application scripts, some in dangerous_cgi.nasl etc... It all seems a bit haphazard. Now applications is an interest of mine, and indeed I have a number of checks to add, but what are peoples thoughts about how to organise these checks? How about with directory traversals and file include flaws? Finally, to what level do people feel it is necessary to check flaws such as stack and heap overflows? Where possible just validate by version? Or some more in depth form of check? What happens if we can't get a version number back from the application? My ideal world would be 1 OSVDB entry, 1 script and validate to whatever level allows confirmation that the bug really exists, but let me know what you think. Tim -- Tim Brown From timb at nth-dimension.org.uk Mon Jun 18 20:36:19 2007 From: timb at nth-dimension.org.uk (Tim Brown) Date: Mon, 18 Jun 2007 19:36:19 +0100 Subject: [Openvas-plugins] New plugins In-Reply-To: <200706181842.27379.timb@nth-dimension.org.uk> References: <200706181842.27379.timb@nth-dimension.org.uk> Message-ID: <200706181936.20211.timb@nth-dimension.org.uk> On Monday 18 June 2007 18:42:26 Tim Brown wrote: > Ok, so after hacking around with the web site a little and attempting a > build on a clean VM image, my thoughts are turning to the plugins which are > in urgent need of update to check for new vulnerabilties. Some thoughts > from an initial perusal of the tree: > > Merging the local checks for each platform? This can be done, and in fact > I think these checks could be built in an automated fashion, at least on > Debian. What do people think? > > Web application checks appear to be tested rather arbitrarily, with some > checks within application scripts, some in dangerous_cgi.nasl etc... It > all seems a bit haphazard. Now applications is an interest of mine, and > indeed I have a number of checks to add, but what are peoples thoughts > about how to organise these checks? How about with directory traversals > and file include flaws? > > Finally, to what level do people feel it is necessary to check flaws such > as stack and heap overflows? Where possible just validate by version? Or > some more in depth form of check? What happens if we can't get a version > number back from the application? > > My ideal world would be 1 OSVDB entry, 1 script and validate to whatever > level allows confirmation that the bug really exists, but let me know what > you think. > > Tim Okay, talking to Debian Security folk: svn://svn.debian.org/svn/secure-testing/data/DSA/list Is a machine readable version of the DSA, so I'm going to hack up some perl to generate the scripts next :). Javier, is this useful to the current nessus package in Debian, I'm looking at my install and the latest DSA check is DSA-869. Tim -- Tim Brown From jan-oliver.wagner at intevation.de Tue Jun 19 00:05:34 2007 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 19 Jun 2007 00:05:34 +0200 Subject: [Openvas-plugins] [Openvas-discuss] New plugins In-Reply-To: <200706181842.27379.timb@nth-dimension.org.uk> References: <200706181842.27379.timb@nth-dimension.org.uk> Message-ID: <200706190005.42551.jan-oliver.wagner@intevation.de> On Monday 18 June 2007 19:42, Tim Brown wrote: > Merging the local checks for each platform? This can be done, and in fact > I think these checks could be built in an automated fashion, at least on > Debian. What do people think? I am all for automation. Of course it is to be seen as a automated preparatory work for the actual human being that checks and signs. Have you a special plan in mind how you want to combine the aggregation and automation for new issues? Perhaps monthly, yearly aggregation? > Web application checks appear to be tested rather arbitrarily, with some > checks within application scripts, some in dangerous_cgi.nasl etc... It > all seems a bit haphazard. Now applications is an interest of mine, and > indeed I have a number of checks to add, but what are peoples thoughts > about how to organise these checks? How about with directory traversals > and file include flaws? You are referring to the proposal of "Generic Plugins"? I have no odea yet how to organise. But at least it should be a family of its own, so we at a place the collects these types of tests. I guess over time some general functions will go into supporting ".inc"-files. > Finally, to what level do people feel it is necessary to check flaws such > as stack and heap overflows? Where possible just validate by version? Or > some more in depth form of check? What happens if we can't get a version > number back from the application? Maybe have two separate tests, one that is marked as "dangerous"? > My ideal world would be 1 OSVDB entry, 1 script and validate to whatever > level allows confirmation that the bug really exists, but let me know what > you think. BTW: I like the idea of a closer link to OSVDB in general. IIRC the current concept makes it difficult for a single plugin to act as non-dangerous and dangerous plugin at the same time? Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From oday at fas.harvard.edu Tue Jun 19 00:17:09 2007 From: oday at fas.harvard.edu (Oliver Day) Date: Mon, 18 Jun 2007 18:17:09 -0400 Subject: [Openvas-plugins] [Openvas-discuss] New plugins In-Reply-To: <200706181842.27379.timb@nth-dimension.org.uk> References: <200706181842.27379.timb@nth-dimension.org.uk> Message-ID: <46770465.502@fas.harvard.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/18/07 1:42 PM, Tim Brown wrote: > Ok, so after hacking around with the web site a little and > attempting a build on a clean VM image, my thoughts are turning to > the plugins which are in urgent need of update to check for new > vulnerabilties. Some thoughts from an initial perusal of the tree: > > > Merging the local checks for each platform? This can be done, and > in fact I think these checks could be built in an automated > fashion, at least on Debian. What do people think? > > Web application checks appear to be tested rather arbitrarily, with > some checks within application scripts, some in dangerous_cgi.nasl > etc... It all seems a bit haphazard. Now applications is an > interest of mine, and indeed I have a number of checks to add, but > what are peoples thoughts about how to organise these checks? How > about with directory traversals and file include flaws? > > Finally, to what level do people feel it is necessary to check > flaws such as stack and heap overflows? Where possible just > validate by version? Or some more in depth form of check? What > happens if we can't get a version number back from the application? > > > My ideal world would be 1 OSVDB entry, 1 script and validate to > whatever level allows confirmation that the bug really exists, but > let me know what you think. > > My ideal world would have a single plugins.xml file that contains all the checks. At the very least one file per (year, platform, etc). I was not successful in arguing for this change earlier however. I think the idea of single file checks is antiquated and the only reason we have held on to it is because Nessus does. I can't think of another vulnscanner which still keeps their plugins in individual file format. Oliver -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdwRk5Kv+lIJNcCARAhXTAJ4psjSZ6ypCkdaheaQ26QBCkUu2OgCgoXih Cv6E8/D3mMEcsfmo+tiVRLk= =T5B0 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20070618/fc5f0360/attachment.htm From jfs at computer.org Mon Jun 18 22:31:20 2007 From: jfs at computer.org (Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?=) Date: Mon, 18 Jun 2007 22:31:20 +0200 Subject: [Openvas-plugins] New plugins In-Reply-To: <200706181936.20211.timb@nth-dimension.org.uk> References: <200706181842.27379.timb@nth-dimension.org.uk> <200706181936.20211.timb@nth-dimension.org.uk> Message-ID: <20070618203120.GA4007@javifsp.no-ip.org> On Mon, Jun 18, 2007 at 07:36:19PM +0100, Tim Brown wrote: > > Okay, talking to Debian Security folk: > > svn://svn.debian.org/svn/secure-testing/data/DSA/list Actually, that is not the complete info, the full info is available at http://cvs.debian.org/webwml/english/security/?root=webwml That one includes both the package information data and the description of the DSAs themselves. That is what is used for website generation. > Is a machine readable version of the DSA, so I'm going to hack up some perl to > generate the scripts next :). There's already some scripts @ the CVS site to parse the DSA data ( > Javier, is this useful to the current nessus > package in Debian, I'm looking at my install and the latest DSA check is > DSA-869. That could be useful for the Nessus package, but the local security checks from Nessus (which are GPL) already include that information (and I provide them in the nessus-plugins package). Why regenerate them? Regards Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20070618/71f0fb7c/attachment.pgp From timb at nth-dimension.org.uk Wed Jun 20 22:14:45 2007 From: timb at nth-dimension.org.uk (Tim Brown) Date: Wed, 20 Jun 2007 21:14:45 +0100 Subject: [Openvas-plugins] New plugins In-Reply-To: <20070618203120.GA4007@javifsp.no-ip.org> References: <200706181842.27379.timb@nth-dimension.org.uk> <200706181936.20211.timb@nth-dimension.org.uk> <20070618203120.GA4007@javifsp.no-ip.org> Message-ID: <200706202114.45631.timb@nth-dimension.org.uk> On Monday 18 June 2007 21:31:20 Javier wrote: > On Mon, Jun 18, 2007 at 07:36:19PM +0100, Tim Brown wrote: > > Okay, talking to Debian Security folk: > > > > svn://svn.debian.org/svn/secure-testing/data/DSA/list > > Actually, that is not the complete info, the full info is available at > http://cvs.debian.org/webwml/english/security/?root=webwml This is more accurate, but less nice to parse and doesn't seem to give such good information about the vulnerability. > That one includes both the package information data and the description of > the DSAs themselves. That is what is used for website generation. > > > Is a machine readable version of the DSA, so I'm going to hack up some > > perl to generate the scripts next :). > > There's already some scripts @ the CVS site to parse the DSA data ( It's horrible python unless you mean DSA2nasl which appears to be proprietary :) > > Javier, is this useful to the current nessus > > package in Debian, I'm looking at my install and the latest DSA check is > > DSA-869. > > That could be useful for the Nessus package, but the local security checks > from Nessus (which are GPL) already include that information (and I provide > them in the nessus-plugins package). Why regenerate them? The Nessus local security checks in unstable don't seem up to date, as I say, the latest appears to be 869. Tim -- Tim Brown From timb at nth-dimension.org.uk Wed Jun 20 22:20:09 2007 From: timb at nth-dimension.org.uk (Tim Brown) Date: Wed, 20 Jun 2007 21:20:09 +0100 Subject: [Openvas-plugins] New plugins In-Reply-To: <20070618203120.GA4007@javifsp.no-ip.org> References: <200706181842.27379.timb@nth-dimension.org.uk> <200706181936.20211.timb@nth-dimension.org.uk> <20070618203120.GA4007@javifsp.no-ip.org> Message-ID: <200706202120.10239.timb@nth-dimension.org.uk> All, Attached is what I have so far for parsing the DSAs from the original URL I was provided with. Tim -- Tim Brown -------------- next part -------------- A non-text attachment was scrubbed... Name: DSA2txt.pl Type: application/x-perl Size: 811 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20070620/5314a3a5/DSA2txt.bin From jan-oliver.wagner at intevation.de Thu Jun 21 09:18:07 2007 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 21 Jun 2007 09:18:07 +0200 Subject: [Openvas-plugins] New plugins In-Reply-To: <200706202120.10239.timb@nth-dimension.org.uk> References: <200706181842.27379.timb@nth-dimension.org.uk> <20070618203120.GA4007@javifsp.no-ip.org> <200706202120.10239.timb@nth-dimension.org.uk> Message-ID: <200706210918.07979.jan-oliver.wagner@intevation.de> On Mittwoch, 20. Juni 2007, Tim Brown wrote: > Attached is what I have so far for parsing the DSAs from the original URL I > was provided with. I tried it. Looks promising. Have you already a conceptual design in mind on how the overall process of considering DSAs into OpenVAS plugins might look like? I'd love a graphical form of this :-). All the best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jfs at computer.org Thu Jun 21 11:07:00 2007 From: jfs at computer.org (Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?=) Date: Thu, 21 Jun 2007 11:07:00 +0200 Subject: [Openvas-plugins] New plugins In-Reply-To: <200706202114.45631.timb@nth-dimension.org.uk> References: <200706181842.27379.timb@nth-dimension.org.uk> <200706181936.20211.timb@nth-dimension.org.uk> <20070618203120.GA4007@javifsp.no-ip.org> <200706202114.45631.timb@nth-dimension.org.uk> Message-ID: <20070621090700.GB29894@javifsp.no-ip.org> On Wed, Jun 20, 2007 at 09:14:45PM +0100, Tim Brown wrote: > > There's already some scripts @ the CVS site to parse the DSA data ( > > It's horrible python unless you mean DSA2nasl which appears to be > proprietary :) I meant these: parse-advisory parse-advisory.pl parse-wml-oval.pl parse_wml.pm parse-wml-sql.pl The first two parse the advisories sent to the mailing lists, the last three parse the WML files in the CVS. > > > Javier, is this useful to the current nessus > > > package in Debian, I'm looking at my install and the latest DSA check is > > > DSA-869. > > > > That could be useful for the Nessus package, but the local security checks > > from Nessus (which are GPL) already include that information (and I provide > > them in the nessus-plugins package). Why regenerate them? > > The Nessus local security checks in unstable don't seem up to date, as I say, > the latest appears to be 869. That's just because I don't have updated them myself. Something easily solvable (given time). Regards Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20070621/074db29d/attachment.pgp