Re: Updater Proposal

[Marek Lukaszuk <m.lukaszuk () gmail com>]

On Wed, May 18, 2011 at 22:08, olli hauer <ohauer () gmx de> wrote:
> On 2011-05-17 05:58, David Fifield wrote:
> > On Sun, May 15, 2011 at 08:28:02PM -0400, Colin L. Rice wrote:
> > > Hello Everyone,
> > >
> > > I'm Colin on of the new GSOC students. As part of my task I want to
> > > implement a auto-updater for nmap. However before I write it I need to
> > > figure out how to implement it and how limited it is.
> > >
> > > So I have been researching this and would like to present a couple of
> > > options for discussion.
> > >
> > > We first have two choices
> > > 1) Write an updater which only touches the platform independant files
> > > such as the lua and NSE libraries as well as nmap-service-probes,
> > > nmap-services, nmap-os-db. This could be used not only to update old
> > > versions of nmap but also to update users to the latest scripts,
> > > services, and os probes without updating the entire nmap library and
> > > allowing new changes to be distributed quickly.
> > > 2) Write an updater which updates everything. This simplifies worrying
> > > about whether the scripts will work with the current version but you do
> > > have to make sure you are getting the correct binary.
> >
> > My gut impression is that updating everything will be easier, because
> > then we don't have to worry about what to do with mismatched binaries
> > and scripts. But it doesn't support one use case that people have asked
> > for, which is to get some updated scripts in between major Nmap
> > releases.
> >
> > > Once you have made those choices you have to decide how you wish to
> > > insure download integrity. There are again a couple of options.
> > > 1) Use a framework such as TUF which is set up to basically handle
> > > hostile attack gracefully and can deal with everything from compromised
> > > keys, hostile mirrors, and man in the middle attacks.
> > > https://www.updateframework.com/browser/specs/tuf-spec.txt
> >
> > I'm impressed with the thought that has gone into TUF. I learned about
> > some packaging attacks I wouldn't have thought of right away, like
> > feeding a client stale metadata to make them think they're up to date
> > when they're not.
> >
> > > 2) Use a simpler system which is wrapped around bsdiff or courgette
> > > where all that is maintained is that the patches are signed by the
> > > correct source, that the patches are newer than the current version, and
> > > that there has been no corruption during transmission.
> >
> > You have the right idea here. At the very least, we need to achieve
> > parity with what conscientious downloaders can already do by verifying
> > PHP signatures on releases. If an updater does verification
> > automatically, then perhaps we can even get a majority of users
> > verifying their updates.
> >
> > David Fifield
>
> If you are looking at bsdiff from Colin Percival, then maybe also look
> into the concept of the FreeBSD patch system. I think with some
> work you can rewrite the scripts to update the binaries and nse scripts.
>
> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-update-server/article.html
> http://www.freebsd.org/cgi/cvsweb.cgi/projects/freebsd-update-server/
>
> I suspect the *BSD users prefer the update by source system. To limit
> traffic it may be a good idea to provide a .tgz file without the mswin32
> sources which are not really usefull on this platforms

All the discussion so far, as I can see (sorry if I missed anything)
is about how to make sure that the whole update process is secure, but
I didn't see any discussion on the performance on the update servers
that this could have. Currently there is a lot of nmap users out there
and when they all start to run the version of nmap that will support
autoupdates/upgrades the amount of the traffic generated could be
significant. Maybe a thought of a different transport mechanism to
spread the load of the updates - torrent for example or something
similar.
Just an idea to think about.

Marek
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/