Re: [patch] The most minor issue ever: set noninteractive on -iL -

[David Fifield <david () bamsoftware com>]

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/