Re: Updater Proposal

[David Fifield <david () bamsoftware com>]

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
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/