Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: Updater Proposal
From: David Fifield <david () bamsoftware com>
Date: Mon, 16 May 2011 20:58:44 -0700

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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault