Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: [patch] The most minor issue ever: set noninteractive on -iL -
From: David Fifield <david () bamsoftware com>
Date: Sun, 8 Apr 2012 23:50:38 -0700

On Fri, Apr 06, 2012 at 11:00:40PM -0400, Patrick Donnelly wrote:
On Fri, Apr 6, 2012 at 8:41 PM, David Fifield <david () bamsoftware com> wrote:
On Fri, Apr 06, 2012 at 05:36:24PM -0700, David Fifield wrote:
On Tue, Apr 03, 2012 at 10:50:03PM -0400, Patrick Donnelly wrote:
On Tue, Apr 3, 2012 at 9:17 PM, David Fifield <david () bamsoftware com> wrote:
I tried this (getpgrp) but it didn't seem to change anything.

I just double-double checked and got it to work:

I'm using this patch (make sure to change both calls to getpid):

I think that was my mistake: I changed only one of them. It's working
for me; will you commit it?

Actually, I just tried this:

sudo ./nmap scanme.nmap.org

And I get runtime interaction, but then my terminal stops echoing after
Ctrl-C.

Okay, after some investigation, I've found the cause(s):

(a) Nmap uses an atexit handler to reset the terminal settings. In the
event of abnormal termination caused by SIGINT (or other signals),
this atexit handler is never called. This is the root of the problem
but there are other interesting interactions worth looking at...

So anyway, we've been up to now enjoying the shell cleaning up after
us. I think what we need is a signal handler for SIGINT, SIGQUIT, and
SIGTERM which clean up the terminal settings. Shall I write up a patch
for this?

Thanks for doing this research. I'd prefer not to do anything
complicated in a signal handler because there may be subtle security
risks. You may have seen for example,

http://lcamtuf.coredump.cx/signals.txt
https://www.owasp.org/index.php/Unsafe_function_call_from_a_signal_handler

The safe way to do a signal handler like this is to atomically set a
global flag and then check it assiduously in all of the program's loops.
That's likely to be a big intrusive change. Maybe there is a better way
to do it, like forking the main program, doing a wait(3) for it,
installing a signal handler that skips out of the wait, and restoring
terminal settings at the end. But I haven't thought about the
implications of doing that.

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 ]