From timb at openvas.org Sat Feb 6 13:04:34 2010 From: timb at openvas.org (Tim Brown) Date: Sat, 6 Feb 2010 12:04:34 +0000 Subject: [Openvas-plugins] OpenVAS SSL cipher suite checks Message-ID: <201002061204.34275.timb@openvas.org> Can't remember who I was talking to about OpenVAS's SSL support and the limitations imposed by the use of GNU TLS, but porting the following to OpenVAS would make a fun little project: http://code.google.com/p/ssl-enum/ Essentially, different SSL libraries (Windows, GNU TLS, OpenSSL) support different cipher suites and thus you can't really rely on one library to check what a server supports. If anyone is interested in working on this, give me a shout and maybe we can get something going. Tim -- Tim Brown From bchandra at secpod.com Mon Feb 8 08:49:18 2010 From: bchandra at secpod.com (Chandrashekhar B) Date: Mon, 8 Feb 2010 13:19:18 +0530 Subject: [Openvas-plugins] OpenVAS SSL cipher suite checks In-Reply-To: <201002061204.34275.timb@openvas.org> References: <201002061204.34275.timb@openvas.org> Message-ID: Hello, > -----Original Message----- > From: openvas-plugins-bounces at wald.intevation.org > [mailto:openvas-plugins-bounces at wald.intevation.org] On > Behalf Of Tim Brown > Sent: Saturday, February 06, 2010 5:35 PM > To: openvas-plugins at wald.intevation.org > Subject: [Openvas-plugins] OpenVAS SSL cipher suite checks > > Can't remember who I was talking to about OpenVAS's SSL > support and the limitations imposed by the use of GNU TLS, > but porting the following to OpenVAS would make a fun little project: > > http://code.google.com/p/ssl-enum/ > > Essentially, different SSL libraries (Windows, GNU TLS, > OpenSSL) support different cipher suites and thus you can't > really rely on one library to check what a server supports. > If anyone is interested in working on this, give me a shout > and maybe we can get something going. Yes, we don't need to use any SSL library, if the idea is to check weak cipher's etc., It can be done using NASL by sending raw Client Hello messages. I think the text files provided here will be useful. Thanks, Chandra. From veerendragg at secpod.com Mon Feb 8 12:03:20 2010 From: veerendragg at secpod.com (Veerendra GG) Date: Mon, 08 Feb 2010 16:33:20 +0530 Subject: [Openvas-plugins] revcomp() function issue Message-ID: <4B6FEF78.4040505@secpod.com> Hi Thomas, revcomp() function in revisions-lib.inc is returning 1, when we pass "kernel~2.6.9~89.EL" and "kernel~2.6.9~89.0.20.EL" packages. But it should return -1 as required package is "kernel~2.6.9~89.0.20.EL" and installed is "kernel~2.6.9~89.EL" a = "kernel~2.6.9~89.EL"; b = "kernel~2.6.9~89.0.20.EL"; result = revcomp( a , b ); Any suggestion to resolve this issue? -- regards, Veerendra GG Security Research Analyst @ SecPod Phone : 91-9886535533 #L-16, 3rd Cross, 26th Main Road, 1st Phase, JP Nagar, Bangalore-78 Tel: 91-80-41214020 Fax: 91-80-41214020 http://www.secpod.com From reinke at securityspace.com Mon Feb 8 20:13:05 2010 From: reinke at securityspace.com (Thomas Reinke) Date: Mon, 08 Feb 2010 14:13:05 -0500 Subject: [Openvas-plugins] revcomp() function issue In-Reply-To: <4B6FEF78.4040505@secpod.com> References: <4B6FEF78.4040505@secpod.com> Message-ID: <4B706241.20901@securityspace.com> Ugh...well, revcomp is smart, but not that smart. The only solution I see here that will retain some sort of automation in terms of working for other packages that might run tin this is to strip the ".el?" suffixes off package names. If you do that, the comparison will work just fine. I'd probably go and change the "isrpmvuln" in pkg-lib-rpm.inc to detect cases where both packages being compared have a common suffix from the last "." onwards, and if they both are the same, strip them before sending the parms to revcomp(). That keeps revcomp() clean, and allows us to put any distro specific kludges into isrpmvuln, which prevents us from having to change existing code generators. If no-one objects to the solution, I can see to it that it gets done. Thomas Veerendra GG wrote: > Hi Thomas, > > revcomp() function in revisions-lib.inc is returning 1, when we pass > "kernel~2.6.9~89.EL" and "kernel~2.6.9~89.0.20.EL" packages. But it > should return -1 as required package is "kernel~2.6.9~89.0.20.EL" and > installed is "kernel~2.6.9~89.EL" > > a = "kernel~2.6.9~89.EL"; > b = "kernel~2.6.9~89.0.20.EL"; > result = revcomp( a , b ); > > Any suggestion to resolve this issue? > > From veerendragg at secpod.com Tue Feb 9 06:46:17 2010 From: veerendragg at secpod.com (Veerendra GG) Date: Tue, 09 Feb 2010 11:16:17 +0530 Subject: [Openvas-plugins] revcomp() function issue In-Reply-To: <4B706241.20901@securityspace.com> References: <4B6FEF78.4040505@secpod.com> <4B706241.20901@securityspace.com> Message-ID: <4B70F6A9.3000504@secpod.com> Hi Thomas, Specified solution should work. regards, Veerendra GG Security Research Analyst @ SecPod Phone : 91-9886535533 #L-16, 3rd Cross, 26th Main Road, 1st Phase, JP Nagar, Bangalore-78 Tel: 91-80-41214020 Fax: 91-80-41214020 http://www.secpod.com Thomas Reinke wrote: > Ugh...well, revcomp is smart, but not that smart. > > The only solution I see here that will retain some sort > of automation in terms of working for other packages that > might run tin this is to strip the ".el?" suffixes off package > names. If you do that, the comparison will work just fine. > > I'd probably go and change the "isrpmvuln" in pkg-lib-rpm.inc > to detect cases where both packages being compared have a common > suffix from the last "." onwards, and if they both are the same, > strip them before sending the parms to revcomp(). > > That keeps revcomp() clean, and allows us to put any distro > specific kludges into isrpmvuln, which prevents us from having to > change existing code generators. > > If no-one objects to the solution, I can see to it that it > gets done. > > Thomas > > Veerendra GG wrote: > >> Hi Thomas, >> >> revcomp() function in revisions-lib.inc is returning 1, when we pass >> "kernel~2.6.9~89.EL" and "kernel~2.6.9~89.0.20.EL" packages. But it >> should return -1 as required package is "kernel~2.6.9~89.0.20.EL" and >> installed is "kernel~2.6.9~89.EL" >> >> a = "kernel~2.6.9~89.EL"; >> b = "kernel~2.6.9~89.0.20.EL"; >> result = revcomp( a , b ); >> >> Any suggestion to resolve this issue? >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20100209/533ee058/attachment.html From goran.licina at lss.hr Tue Feb 9 15:37:30 2010 From: goran.licina at lss.hr (=?iso-8859-2?Q?Goran_Li=E8ina?=) Date: Tue, 9 Feb 2010 15:37:30 +0100 Subject: [Openvas-plugins] smb_enum_services.nasl References: <8A02A3DF683DEE42BE73187F4CA4444C163DD4@vlasta.lss-net.lss.hr> <20091127113016.GA7109@komma-nix.de> Message-ID: <8A02A3DF683DEE42BE73187F4CA4444C1C4EB0@vlasta.lss-net.lss.hr> > -----Original Message----- > From: openvas-plugins-bounces at wald.intevation.org [mailto:openvas- > plugins-bounces at wald.intevation.org] On Behalf Of Michael Meyer > Sent: Friday, November 27, 2009 12:30 PM > To: openvas-plugins at wald.intevation.org > Subject: Re: [Openvas-plugins] smb_enum_services.nasl > > Hello Goran, > > *** Goran Li?ina wrote: > > as you know we are working on last missing dep - > smb_enum_sevices.nasl. > > However we can't find appropriate literature and protocol definitions > for > > DCE/RPC over SMB and are a bit stuck on that. > > > > Can anybody point us to some materials that could help us? > > http://www.amazon.com/DCE-RPC-over-SMB-Internals/dp/1578701503 seems > to be the only useful source. > > http://ftp.us.debian.org/debian/pool/main/n/nessus-plugins/nessus- > plugins_2.2.10-6_i386.deb > contains an old version of smb_enum_services.nasl which seems to be > released under the GPL. AFAICS this will not work with OpenVAS but it > could be inspiring for you. Maybe take a look on it... > > HTH > > Micha > Hello, plugin is finally finished (in attachment). Please try it and commit if it's ok. Thanks! Goran -------------- next part -------------- A non-text attachment was scrubbed... Name: smb_enum_services.nasl Type: application/octet-stream Size: 22542 bytes Desc: smb_enum_services.nasl Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20100209/fa233e6d/smb_enum_services-0001.obj From michael.meyer at intevation.de Tue Feb 9 16:36:41 2010 From: michael.meyer at intevation.de (Michael Meyer) Date: Tue, 9 Feb 2010 16:36:41 +0100 Subject: [Openvas-plugins] smb_enum_services.nasl In-Reply-To: <8A02A3DF683DEE42BE73187F4CA4444C1C4EB0@vlasta.lss-net.lss.hr> References: <8A02A3DF683DEE42BE73187F4CA4444C163DD4@vlasta.lss-net.lss.hr> <20091127113016.GA7109@komma-nix.de> <8A02A3DF683DEE42BE73187F4CA4444C1C4EB0@vlasta.lss-net.lss.hr> Message-ID: <20100209153641.GA8103@komma-nix.de> Hello Goran, *** Goran Li?ina wrote: > plugin is finally finished (in attachment). > > Please try it and commit if it's ok. Looks very good. Initial tests were all successful. I'll commit it soon. Thank you very much. Micha -- Michael Meyer OpenPGP Key: 76E050B9 http://www.intevation.de Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From felix.wolfsteller at intevation.de Wed Feb 10 10:55:15 2010 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Wed, 10 Feb 2010 10:55:15 +0100 Subject: [Openvas-plugins] smb_enum_services.nasl In-Reply-To: <8A02A3DF683DEE42BE73187F4CA4444C1C4EB0@vlasta.lss-net.lss.hr> References: <8A02A3DF683DEE42BE73187F4CA4444C163DD4@vlasta.lss-net.lss.hr> <20091127113016.GA7109@komma-nix.de> <8A02A3DF683DEE42BE73187F4CA4444C1C4EB0@vlasta.lss-net.lss.hr> Message-ID: <201002101055.15812.felix.wolfsteller@intevation.de> Two cents about the wording from a non-native english speaker old: This plugin implements the SvcOpenSCManager() and SvcEnumServices() calls to obtain, using the MS-DCE/RPC protocol over SMB, the list of active and inactive services and drivers of the remote host. proposed: This plugin implements the SvcOpenSCManager() and SvcEnumServices() calls to obtain the list of active and inactive services and drivers of the remote host, using the MS-DCE/RPC protocol over SMB. old: Solution : To prevent the listing of the services for being obtained, you should either have tight login restrictions, so that only trusted users can access your host, and/or you should filter incoming traffic to this port. proposed: not sure, something with "the listing of the services for being obtained" sounds weird. Maybe: "To prevent access to the services and drivers list..." ? --felix -- Felix Wolfsteller | ++49 541 335083-783 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From goran.licina at lss.hr Wed Feb 10 11:02:40 2010 From: goran.licina at lss.hr (=?iso-8859-2?Q?Goran_Li=E8ina?=) Date: Wed, 10 Feb 2010 11:02:40 +0100 Subject: [Openvas-plugins] smb_enum_services.nasl References: <8A02A3DF683DEE42BE73187F4CA4444C163DD4@vlasta.lss-net.lss.hr><20091127113016.GA7109@komma-nix.de><8A02A3DF683DEE42BE73187F4CA4444C1C4EB0@vlasta.lss-net.lss.hr> <201002101055.15812.felix.wolfsteller@intevation.de> Message-ID: <8A02A3DF683DEE42BE73187F4CA4444C1C4EC1@vlasta.lss-net.lss.hr> Proposals accepted ;) Corrected plugin is in attachment. Thanks Felix! Regards, Goran > -----Original Message----- > From: openvas-plugins-bounces at wald.intevation.org [mailto:openvas- > plugins-bounces at wald.intevation.org] On Behalf Of Felix Wolfsteller > Sent: Wednesday, February 10, 2010 10:55 AM > To: openvas-plugins at wald.intevation.org > Subject: Re: [Openvas-plugins] smb_enum_services.nasl > > Two cents about the wording from a non-native english speaker > > old: > This plugin implements the SvcOpenSCManager() and > SvcEnumServices() calls to obtain, using the MS-DCE/RPC > protocol over SMB, the list of active and inactive services and > drivers > of the remote host. > proposed: > This plugin implements the SvcOpenSCManager() and SvcEnumServices() > calls to > obtain the list of active and inactive services and drivers of the > remote > host, using the MS-DCE/RPC protocol over SMB. > > old: > Solution : To prevent the listing of the services for being > obtained, you should either have tight login restrictions, > so that only trusted users can access your host, and/or you > should filter incoming traffic to this port. > proposed: > not sure, something with "the listing of the services for being > obtained" > sounds weird. Maybe: "To prevent access to the services and drivers > list..." ? > > --felix > > -- > Felix Wolfsteller | ++49 541 335083-783 | http://www.intevation.de/ > PGP Key: 39DE0100 > Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B > 18998 > Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > _______________________________________________ > Openvas-plugins mailing list > Openvas-plugins at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins -------------- next part -------------- A non-text attachment was scrubbed... Name: smb_enum_services.nasl Type: application/octet-stream Size: 22536 bytes Desc: smb_enum_services.nasl Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20100210/3304659b/smb_enum_services-0001.obj From jonas at andradas.es Wed Feb 10 11:32:18 2010 From: jonas at andradas.es (Jonas Andradas) Date: Wed, 10 Feb 2010 11:32:18 +0100 Subject: [Openvas-plugins] smb_enum_services.nasl In-Reply-To: <8A02A3DF683DEE42BE73187F4CA4444C1C4EC1@vlasta.lss-net.lss.hr> References: <8A02A3DF683DEE42BE73187F4CA4444C163DD4@vlasta.lss-net.lss.hr> <20091127113016.GA7109@komma-nix.de> <8A02A3DF683DEE42BE73187F4CA4444C1C4EB0@vlasta.lss-net.lss.hr> <201002101055.15812.felix.wolfsteller@intevation.de> <8A02A3DF683DEE42BE73187F4CA4444C1C4EC1@vlasta.lss-net.lss.hr> Message-ID: Hello, sometimes people prefer "indirect" or "reflexive" sentences. If this wans to be applied, my suggestion (over the last nasl attached in Goran's mail) would be: Current: Solution : To prevent access to the services and drivers list, you should either have tight login restrictions, so that only trusted users can access your host, and/or you should filter incoming traffic to this port. Proposed: Solution : To prevent access to the services and drivers list, you either tight login restrictions should be in place, so that only trusted users are able to access the host, and/or incoming traffic to this port should be filtered. Best regards, Jon?s Andradas. 2010/2/10 Goran Li?ina > Proposals accepted ;) > > Corrected plugin is in attachment. > > Thanks Felix! > > Regards, > > Goran > > > -----Original Message----- > > From: openvas-plugins-bounces at wald.intevation.org [mailto:openvas- > > plugins-bounces at wald.intevation.org] On Behalf Of Felix Wolfsteller > > Sent: Wednesday, February 10, 2010 10:55 AM > > To: openvas-plugins at wald.intevation.org > > Subject: Re: [Openvas-plugins] smb_enum_services.nasl > > > > Two cents about the wording from a non-native english speaker > > > > old: > > This plugin implements the SvcOpenSCManager() and > > SvcEnumServices() calls to obtain, using the MS-DCE/RPC > > protocol over SMB, the list of active and inactive services and > > drivers > > of the remote host. > > proposed: > > This plugin implements the SvcOpenSCManager() and SvcEnumServices() > > calls to > > obtain the list of active and inactive services and drivers of the > > remote > > host, using the MS-DCE/RPC protocol over SMB. > > > > old: > > Solution : To prevent the listing of the services for being > > obtained, you should either have tight login restrictions, > > so that only trusted users can access your host, and/or you > > should filter incoming traffic to this port. > > proposed: > > not sure, something with "the listing of the services for being > > obtained" > > sounds weird. Maybe: "To prevent access to the services and drivers > > list..." ? > > > > --felix > > > > -- > > Felix Wolfsteller | ++49 541 335083-783 | http://www.intevation.de/ > > PGP Key: 39DE0100 > > Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B > > 18998 > > Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > > _______________________________________________ > > Openvas-plugins mailing list > > Openvas-plugins at wald.intevation.org > > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins > > _______________________________________________ > Openvas-plugins mailing list > Openvas-plugins at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20100210/aedd6fd1/attachment.htm From matthew.mundell at intevation.de Wed Feb 10 11:47:55 2010 From: matthew.mundell at intevation.de (Matthew Mundell) Date: 10 Feb 2010 10:47:55 GMT Subject: [Openvas-plugins] smb_enum_services.nasl In-Reply-To: Message of Wed, 10 Feb 2010 10:55:15 +0100. <201002101055.15812.felix.wolfsteller@intevation.de> Message-ID: <20100210104754.E7A76DEB7D@mail.ukfsn.org> > Two cents about the wording from a non-native english speaker > > old: > This plugin implements the SvcOpenSCManager() and > SvcEnumServices() calls to obtain, using the MS-DCE/RPC > protocol over SMB, the list of active and inactive services and drivers > of the remote host. > proposed: > This plugin implements the SvcOpenSCManager() and SvcEnumServices() calls to > obtain the list of active and inactive services and drivers of the remote > host, using the MS-DCE/RPC protocol over SMB. Maybe even: This plugin implements the SvcOpenSCManager() and SvcEnumServices() calls. These calls obtain the list of active and inactive services and drivers of the remote host. Both calls use the MS-DCE/RPC protocol over SMB. > > old: > Solution : To prevent the listing of the services for being > obtained, you should either have tight login restrictions, > so that only trusted users can access your host, and/or you > should filter incoming traffic to this port. > proposed: > not sure, something with "the listing of the services for being obtained" > sounds weird. Maybe: "To prevent access to the services and drivers > list..." ? Was it supposed to be "services from being obtained"? -- Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From veerendragg at secpod.com Thu Feb 11 11:52:08 2010 From: veerendragg at secpod.com (Veerendra GG) Date: Thu, 11 Feb 2010 16:22:08 +0530 Subject: [Openvas-plugins] revcomp() function issue In-Reply-To: <4B706241.20901@securityspace.com> References: <4B6FEF78.4040505@secpod.com> <4B706241.20901@securityspace.com> Message-ID: <4B73E158.5000407@secpod.com> Hi Thomas, There's another issue I missed. Issue is in isrpmvuln() function in pkg-lib-rpm.inc. which is not able to handle specific condition. When I updated kernel packages in CentOS 4.8 it got updated and when I query for packages both old and new packages are coming. In this case isrpmvuln() function is reporting vulnerable even though patch is applied. Version Before Update : kernel-devel-2.6.9-89.EL Version After Update : kernel-devel-2.6.9-89.0.20.EL when I query the out put is, [root at localhost ~]# rpm -qa | grep -i kernel-devel kernel-devel-2.6.9-89.EL kernel-devel-2.6.9-89.0.20.EL Here it is listing both version of kernel-devel, hence creating problem. NOTE : similarly other kernel packages are coming. pkg = "kernel-devel" rpm = "kernel-devel-2.6.9-89.0.20.EL" pat = string("[\n;](", pkg, "~[^;]+);"); Problem is at line 39 i.e matches = eregmatch(pattern:pat, string:rpms); value of matches is, [ 0: 'kernel-devel~2.6.9~89.EL', 1: 'kernel-devel~2.6.9~89.EL' ] I think we need to enhance eregmatch, so that it returns all the packages and compare for all the matches. please let me know what you think regards, Veerendra GG Security Research Analyst @ SecPod Phone : 91-9886535533 #L-16, 3rd Cross, 26th Main Road, 1st Phase, JP Nagar, Bangalore-78 Tel: 91-80-41214020 Fax: 91-80-41214020 http://www.secpod.com Thomas Reinke wrote: > Ugh...well, revcomp is smart, but not that smart. > > The only solution I see here that will retain some sort > of automation in terms of working for other packages that > might run tin this is to strip the ".el?" suffixes off package > names. If you do that, the comparison will work just fine. > > I'd probably go and change the "isrpmvuln" in pkg-lib-rpm.inc > to detect cases where both packages being compared have a common > suffix from the last "." onwards, and if they both are the same, > strip them before sending the parms to revcomp(). > > That keeps revcomp() clean, and allows us to put any distro > specific kludges into isrpmvuln, which prevents us from having to > change existing code generators. > > If no-one objects to the solution, I can see to it that it > gets done. > > Thomas > > Veerendra GG wrote: > >> Hi Thomas, >> >> revcomp() function in revisions-lib.inc is returning 1, when we pass >> "kernel~2.6.9~89.EL" and "kernel~2.6.9~89.0.20.EL" packages. But it >> should return -1 as required package is "kernel~2.6.9~89.0.20.EL" and >> installed is "kernel~2.6.9~89.EL" >> >> a = "kernel~2.6.9~89.EL"; >> b = "kernel~2.6.9~89.0.20.EL"; >> result = revcomp( a , b ); >> >> Any suggestion to resolve this issue? >> >> >> > > > From lists at securityspace.com Sun Feb 14 05:31:41 2010 From: lists at securityspace.com (Thomas Reinke) Date: Sat, 13 Feb 2010 23:31:41 -0500 Subject: [Openvas-plugins] revcomp() function issue In-Reply-To: <4B73E158.5000407@secpod.com> References: <4B6FEF78.4040505@secpod.com> <4B706241.20901@securityspace.com> <4B73E158.5000407@secpod.com> Message-ID: <4B777CAD.9070906@securityspace.com> Hmm...I agree there's an issue, but I'm not sure if I agree with you on the details (but can be arm twisted on this - have not made up my mind). Having an up to date kernel installed on the system does not imply that the up to date kernel is the one running. What if a a new kernel was installed, but the system never rebooted? I don't know that this should be quietly ignored. I suppose we could go for the default "normal" case, and simply ignore generating a warning providing that the up to date (or later) kernel is available. How often I guess it boils down to whether or not we consider the lack of a reboot to be something to worry about from an audit perspective. If not, then likely a simple update to how we check for multiple versions of the same package being installed would be in order. Thomas Veerendra GG wrote: > Hi Thomas, > > There's another issue I missed. > > Issue is in isrpmvuln() function in pkg-lib-rpm.inc. which is not able > to handle specific condition. > > When I updated kernel packages in CentOS 4.8 it got updated and when I > query for packages both old and new packages are coming. In this case > isrpmvuln() function is reporting vulnerable even though patch is applied. > > Version Before Update : kernel-devel-2.6.9-89.EL > Version After Update : kernel-devel-2.6.9-89.0.20.EL > > when I query the out put is, > [root at localhost ~]# rpm -qa | grep -i kernel-devel > kernel-devel-2.6.9-89.EL > kernel-devel-2.6.9-89.0.20.EL > > Here it is listing both version of kernel-devel, hence creating problem. > NOTE : similarly other kernel packages are coming. > > pkg = "kernel-devel" > rpm = "kernel-devel-2.6.9-89.0.20.EL" > pat = string("[\n;](", pkg, "~[^;]+);"); > > Problem is at line 39 > i.e matches = eregmatch(pattern:pat, string:rpms); > > value of matches is, > [ 0: 'kernel-devel~2.6.9~89.EL', 1: 'kernel-devel~2.6.9~89.EL' ] > > I think we need to enhance eregmatch, so that it returns all the packages > and compare for all the matches. > > please let me know what you think > > regards, > Veerendra GG > > Security Research Analyst @ SecPod > Phone : 91-9886535533 > > #L-16, 3rd Cross, 26th Main Road, > 1st Phase, JP Nagar, Bangalore-78 > Tel: 91-80-41214020 > Fax: 91-80-41214020 > http://www.secpod.com > > > > Thomas Reinke wrote: >> Ugh...well, revcomp is smart, but not that smart. >> >> The only solution I see here that will retain some sort >> of automation in terms of working for other packages that >> might run tin this is to strip the ".el?" suffixes off package >> names. If you do that, the comparison will work just fine. >> >> I'd probably go and change the "isrpmvuln" in pkg-lib-rpm.inc >> to detect cases where both packages being compared have a common >> suffix from the last "." onwards, and if they both are the same, >> strip them before sending the parms to revcomp(). >> >> That keeps revcomp() clean, and allows us to put any distro >> specific kludges into isrpmvuln, which prevents us from having to >> change existing code generators. >> >> If no-one objects to the solution, I can see to it that it >> gets done. >> >> Thomas >> >> Veerendra GG wrote: >> >>> Hi Thomas, >>> >>> revcomp() function in revisions-lib.inc is returning 1, when we pass >>> "kernel~2.6.9~89.EL" and "kernel~2.6.9~89.0.20.EL" packages. But it >>> should return -1 as required package is "kernel~2.6.9~89.0.20.EL" and >>> installed is "kernel~2.6.9~89.EL" >>> >>> a = "kernel~2.6.9~89.EL"; >>> b = "kernel~2.6.9~89.0.20.EL"; >>> result = revcomp( a , b ); >>> >>> Any suggestion to resolve this issue? >>> >>> >>> >> >> > _______________________________________________ > Openvas-plugins mailing list > Openvas-plugins at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins > From veerendragg at secpod.com Mon Feb 15 14:19:37 2010 From: veerendragg at secpod.com (Veerendra GG) Date: Mon, 15 Feb 2010 18:49:37 +0530 Subject: [Openvas-plugins] revcomp() function issue In-Reply-To: <4B777CAD.9070906@securityspace.com> References: <4B6FEF78.4040505@secpod.com> <4B706241.20901@securityspace.com> <4B73E158.5000407@secpod.com> <4B777CAD.9070906@securityspace.com> Message-ID: <4B7949E9.3080600@secpod.com> HI Thomas, Please find inline comment. Thomas Reinke wrote: > Hmm...I agree there's an issue, but I'm not sure if I agree with you on > the details (but can be arm twisted on this - have not made up my mind). > > Having an up to date kernel installed on the system does not > imply that the up to date kernel is the one running. > What if a a new kernel was installed, but the system never > rebooted? I don't know that this should be quietly ignored. > > I suppose we could go for the default "normal" case, and > simply ignore generating a warning providing that the > up to date (or later) kernel is available. How often > I guess it boils down to whether or not we consider the > lack of a reboot to be something to worry about from an > audit perspective. If not, then likely a simple update to > how we check for multiple versions of the same package > being installed would be in order. As you mentioned above a simple update will do. > Thomas > > Thank you, Veerendra GG From veerendragg at secpod.com Tue Feb 23 15:22:37 2010 From: veerendragg at secpod.com (Veerendra GG) Date: Tue, 23 Feb 2010 19:52:37 +0530 Subject: [Openvas-plugins] revcomp() function issue In-Reply-To: <4B706241.20901@securityspace.com> References: <4B6FEF78.4040505@secpod.com> <4B706241.20901@securityspace.com> Message-ID: <4B83E4AD.70702@secpod.com> Hi Thomas, Modified "isrpmvuln()" function in pkg-lib-rpm.inc to handle below specified issue. Please review the changes. If the changes are fine and you are okay with the modifications, we'll commit. Thank you, Veerendra Thomas Reinke wrote: > Ugh...well, revcomp is smart, but not that smart. > > The only solution I see here that will retain some sort > of automation in terms of working for other packages that > might run tin this is to strip the ".el?" suffixes off package > names. If you do that, the comparison will work just fine. > > I'd probably go and change the "isrpmvuln" in pkg-lib-rpm.inc > to detect cases where both packages being compared have a common > suffix from the last "." onwards, and if they both are the same, > strip them before sending the parms to revcomp(). > > That keeps revcomp() clean, and allows us to put any distro > specific kludges into isrpmvuln, which prevents us from having to > change existing code generators. > > If no-one objects to the solution, I can see to it that it > gets done. > > Thomas > > Veerendra GG wrote: > >> Hi Thomas, >> >> revcomp() function in revisions-lib.inc is returning 1, when we pass >> "kernel~2.6.9~89.EL" and "kernel~2.6.9~89.0.20.EL" packages. But it >> should return -1 as required package is "kernel~2.6.9~89.0.20.EL" and >> installed is "kernel~2.6.9~89.EL" >> >> a = "kernel~2.6.9~89.EL"; >> b = "kernel~2.6.9~89.0.20.EL"; >> result = revcomp( a , b ); >> >> Any suggestion to resolve this issue? >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20100223/56e9243d/attachment.htm From dpopovic at lss.hr Fri Feb 26 20:18:27 2010 From: dpopovic at lss.hr (=?UTF-8?Q?Dra=C5=BEen_Popovi=C4=87?=) Date: Fri, 26 Feb 2010 20:18:27 +0100 Subject: [Openvas-plugins] MS-RPC for GSoC Message-ID: <1267211907.8439.7.camel@DFP-BUNTU> Hello everyone. :) I have an idea for GSoC, so I would like to hear your thoughts about it. I've spent a lot of hours programming remote checks in NASL, and I must admit that it was somewhat a painfull experience. I think that remote checks are very important in pentesting, as such NASL should provide a strong framework for their development. By a "strong framework" I mean, various network protocols support including packet building/dissecting ".inc"s. For example, my goal is to port all of Metasploits DCERPC/SMB based exploits to OpenVAS in a form of intrusive checks, also utilize the use of MSRPC in all kinds of enumeration (service, users, shares...). So far my every step in implementing MSRPC was severly slowed down due to inadequate/incomplete NASL implementation of underlying network protocols such as SMB and NetBT. Why MS-RPC (a Microsofts port of DCE-RPC)? Because it seems to be a vulnerability "surfboard". Just count the Metasploit SMB/DCERPC exploit modules, or even CANVASs. To sum it all up, my idea is to implement the MSRPC protocol in NASL, including packet crafting .inc, data types handling (Network Data Representation marshalling and unmarashalling), statefull operations (bind, request, fault) and ofcourse calls to Windows remote procedures extracted from SAMBA 4.0 .idls. The main design guidelines would be Pythons Impacket DCERPC implementation and a beautiful NMAPs NSE MSRPC implementation. Regards, D. -- Laboratory for Systems and Signals Department of Electronic Systems and Information Processing Faculty of Electrical Engineering and Computing University of Zagreb From kost at linux.hr Sat Feb 27 04:28:56 2010 From: kost at linux.hr (Vlatko Kosturjak) Date: Sat, 27 Feb 2010 04:28:56 +0100 Subject: [Openvas-plugins] MS-RPC for GSoC In-Reply-To: <1267211907.8439.7.camel@DFP-BUNTU> References: <1267211907.8439.7.camel@DFP-BUNTU> Message-ID: <4B889178.5090505@linux.hr> Dra?en Popovi? wrote: > Hello everyone. :) > > I have an idea for GSoC, so I would like to hear your thoughts about it. > I've spent a lot of hours programming remote checks in NASL, and I must > [...] > admit that it was somewhat a painfull experience. I think that remote > (Network Data Representation marshalling and unmarashalling), statefull > operations (bind, request, fault) and ofcourse calls to Windows remote > procedures extracted from SAMBA 4.0 .idls. The main design guidelines > would be Pythons Impacket DCERPC implementation and a beautiful NMAPs > NSE MSRPC implementation. Totally agree. OpenVAS was focusing too much on local checks recently. I would definitively vote for this as we need to improve remote checks in OpenVAS. Sooner the better... Kost From bchandra at secpod.com Sat Feb 27 11:51:18 2010 From: bchandra at secpod.com (Chandrashekhar B) Date: Sat, 27 Feb 2010 16:21:18 +0530 Subject: [Openvas-plugins] MS-RPC for GSoC In-Reply-To: <1267211907.8439.7.camel@DFP-BUNTU> References: <1267211907.8439.7.camel@DFP-BUNTU> Message-ID: Hello, > -----Original Message----- > From: openvas-plugins-bounces at wald.intevation.org > [mailto:openvas-plugins-bounces at wald.intevation.org] On > Behalf Of Dra?en Popovic > Sent: Saturday, February 27, 2010 12:48 AM > To: openvas-plugins at wald.intevation.org > Subject: [Openvas-plugins] MS-RPC for GSoC > > Hello everyone. :) > > I have an idea for GSoC, so I would like to hear your > thoughts about it. > I've spent a lot of hours programming remote checks in NASL, > and I must admit that it was somewhat a painfull experience. > I think that remote checks are very important in pentesting, > as such NASL should provide a strong framework for their > development. By a "strong framework" I mean, various network > protocols support including packet building/dissecting > ".inc"s. What others apart from DCERPC/SMB do you think are inadequate? It'll be useful information to list them all somewhere. > For example, my goal is to port all of Metasploits > DCERPC/SMB based exploits to OpenVAS in a form of intrusive > checks, also utilize the use of MSRPC in all kinds of > enumeration (service, users, shares...). So far my every step > in implementing MSRPC was severly slowed down due to > inadequate/incomplete NASL implementation of underlying > network protocols such as SMB and NetBT. Why MS-RPC (a > Microsofts port of DCE-RPC)? Because it seems to be a > vulnerability "surfboard". Just count the Metasploit > SMB/DCERPC exploit modules, or even CANVASs. To sum it all > up, my idea is to implement the MSRPC protocol in NASL, > including packet crafting .inc, data types handling (Network > Data Representation marshalling and unmarashalling), > statefull operations (bind, request, fault) and ofcourse > calls to Windows remote procedures extracted from SAMBA 4.0 > .idls. The main design guidelines would be Pythons Impacket > DCERPC implementation and a beautiful NMAPs NSE MSRPC implementation. Nice idea! I agree that the current facility available through smb_nt.inc is inadequate to write some of the SMB and RPC checks. We had discussed this during last DevCon and the idea that emerged was to integrate low level Samba functions into OpenVAS space. I still have to write CR for that. If you think it is possible to write .inc based on Impacket or MSRPC implementation of Nmap, it would be the way to go. Thanks, Chandra. From dpopovic at lss.hr Sat Feb 27 19:30:06 2010 From: dpopovic at lss.hr (=?UTF-8?Q?Dra=C5=BEen_Popovi=C4=87?=) Date: Sat, 27 Feb 2010 19:30:06 +0100 Subject: [Openvas-plugins] MS-RPC for GSoC In-Reply-To: References: <1267211907.8439.7.camel@DFP-BUNTU> Message-ID: <1267295406.2516.188.camel@DFP-BUNTU> On Sat, 2010-02-27 at 16:21 +0530, Chandrashekhar B wrote: > Hello, > Hi :) > What others apart from DCERPC/SMB do you think are inadequate? It'll be > useful information to list them all somewhere. Some of the protocols I dealt with: NFS and SUN-RPC, netbios is scattered all over the plugin repository (maybe a netbt.inc?). > Nice idea! I agree that the current facility available through smb_nt.inc is > inadequate to write some of the SMB and RPC checks. We had discussed this > during last DevCon and the idea that emerged was to integrate low level > Samba functions into OpenVAS space. I lack the experience to weight the pro and cons when it comes to integration into NASL vs implementation in NASL. I presume you don't want NASL to gain too much weight unnecesary, on the other hand reinventing the wheel is not always the best approach. My only ground in this matter is the approach that other scripting languages take. > If you think it is possible to write .inc based on Impacket or MSRPC > implementation of Nmap, it would be the way to go. I am aware of the fact that NASL lacks certain capabilities, such as OO paradigm, various high level data types. Sure that this kind of extensions to NASL would mean a great deal to NASL developers to make state of the art scripts. But lets do the best with what we've got, and if the time comes for NASL to evolve in such a way, c00l. Answer to your question...definitely! To that point, I wish to state that there is a need for introducing certain design guidelines, patterns for "inc" development. The purpose of which is, of course, better code quality and speed up of plugin production. Let me demonstrate my thoughts with a brief example: Consider the SMB protocol...First I would implement a smb-packet.inc. In this inc you could find "build_" and "dissect_" methods for easy SMB packet crafting (like in Perl::Net). This "-packet.inc"s would represent a ground for protocol operations implementation, also if making some exploit on that particular level the creation of vuln packet would be easy and nice. The next step is to implement the actual protocol in a "smb.inc". As said before, this inc would include("smb-packet.inc") and would heavily rely on that particular inc. Here you could find protocol specific methods which provide a adequate abstraction level for the programmer/user. This is just a rough outline. Also we should consider naming conventions, which data types to use etc.. I've looked how other languages do it, and sure they have an advantage (OOP), but I don't see why we can't make NASL even better. :) Your opinions? Thanks, Dra?en. -- Laboratory for Systems and Signals Department of Electronic Systems and Information Processing Faculty of Electrical Engineering and Computing University of Zagreb From timb at openvas.org Sun Feb 28 15:01:09 2010 From: timb at openvas.org (Tim Brown) Date: Sun, 28 Feb 2010 14:01:09 +0000 Subject: [Openvas-plugins] MS-RPC for GSoC In-Reply-To: References: <1267211907.8439.7.camel@DFP-BUNTU> <4B889178.5090505@linux.hr> Message-ID: <201002281401.21422.timb@openvas.org> On Monday 01 March 2010 11:05:08 Jonas Andradas wrote: > Hello, > > 2010/2/27 Vlatko Kosturjak > > > [...] > > > > Totally agree. OpenVAS was focusing too much on local checks recently. I > > would definitively vote for this as we need to improve remote checks in > > OpenVAS. > > > > Sooner the better... > > > > Kost > > At the company I work for, we do auditing services, among other things. > Currently we are using Nessus, and I am introducing OpenVAS gradually. All > progress at improving remote checks with no credentials (identifying > services, versions, remote vulnerabilities) would help in OpenVAS replacing > Nessus :) > > GSOC projects on this, I think could be very useful to the project. There's no reason why we can't add more bindings to OpenVAS for the Samba libraries (and others). This is what we agreed at DevCon 2. Fact is that whilst SSH/SMB code exists in NASL, it is a massive pain in the ass to keep maintaining it. I would support a GSoC project to work on Samba integration. Tim Tim -- Tim Brown -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20100228/8d951bf6/attachment.pgp