Hello,
> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On > Behalf Of Dražen Popovic > Sent: Sunday, February 28, 2010 12:00 AM > To: [email protected] > Subject: Re: [Openvas-plugins] MS-RPC for GSoC > > 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. The reason is documented here, http://www.openvas.org/openvas-devcon2-minutes.html#external_libs > > > 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? Take a look at the discussion minutes and let us know what you think. Either way (Implementing in NASL or external library), I suggest you prepare a CR (http://www.openvas.org/openvas-crs.html) for the same and that's the path for everyone to review the changes and take it for implementation. Thanks, Chandra. _______________________________________________ Openvas-plugins mailing list [email protected] http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins
