Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: Updater Proposal
From: Marek Lukaszuk <m.lukaszuk () gmail com>
Date: Thu, 19 May 2011 11:01:32 +0200

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

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.

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.


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
Just an idea to think about.

Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

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