Re: New Years Day Release: Nmap 4.52

["Rob Nicholls" <robert () everythingeverything co uk>]

> the installer doesn't check if Zenmap might still be running

It doesn't check if nmap.exe is still running either.

IIRC you can also kill the process(es) using a plugin for NSIS,
(KillProcDLL plugin, used with the Processes NSIS plugin, there might be a
newer/better way of doing this now?) which could be useful if we want to
check that nmap.exe isn't still running in Windows (as I don't believe it
has a title).

But some people might not want it to kill the process, as you might be
installing nmap/zenmap into a different folder so you can run the two
versions in parallel. Or perhaps they've kicked off some scans at the
command line using a different version of nmap in a different location and
have decided to install the latest version using the setup file. Although
I suspect those users may stick with the zip file.

The link you've provided might be the better option, as it won't stop the
application and potentially lose results, in that example it'll only warn
the user and abort the installation. But at the same time, it'd stop user
from installing it until zenmap has been closed (on the plus side, the
only way to get zenmap on Windows is to use the setup file or compile it
yourself, as it doesn't come with the zip, so it's less likely that
someone would have multiple running copies scattered around).

Overall, it's probably more useful to have that check and let the user
decide whether to abort the install if zenmap (and possibly nmap too using
the Processes plugin) are still running. That would at least put the onus
on the user, and perhaps gently prompt them to close down applications
before installing the latest version.

I've also spotted that the Uninstaller section performs:

RMDir /r $PROGRAMFILES\Nmap

when I think (not tried it yet) it should really be using something more
like:

RMDir /r $INSTDIR\Nmap

Otherwise it could potentially remove the wrong folder if you've installed
Nmap to a non-default location (having said that, the Installer section
deletes the same folder, so it's probably not currently an issue). I
suspect it might be safer to replace it with code to recursively remove
specific subfolders (nselib, nselib-bin, scripts, zenmap) and then a
non-recursive delete of the $INSTDIR, just in case people have left
important information in the folder that they want to keep between
upgrades (and if the folder's empty I believe it should remove it).

If it is changed to delete $INSTDIR, we'd probably want to some additional
error checking, as mentioned:

http://nsis.sourceforge.net/Validating_$INSTDIR_before_uninstall

Seeing as the installer has:

SetOverwrite on

I'm pretty sure we can get away without deleting the $PROGRAMFILES\Nmap
folder as it should overwrite the necessary files, however, we should
probably change it to remove the $INSTDIR folder so it'll perform a clean
install in case old/deprecated NSE files in the scripts folder (for
example) are removed in later versions. If we do remove the folder,
there's presumably no point in deleting certain individual files first?
Again, an extra check for a blank registry key should be performed.

I might look into writing a patch later tonight that takes into account
all of the things mentioned above.


Rob



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