linux-kernel - Re: [RFC] SIGKILL vs. SIGSEGV on late execve() failures

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130216022006.GB4503@ZenIV.linux.org.uk>
Date:	Sat, 16 Feb 2013 02:20:06 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Shentino <shentino@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] SIGKILL vs. SIGSEGV on late execve() failures

On Sat, Feb 16, 2013 at 01:50:24AM +0000, Al Viro wrote:
> On Fri, Feb 15, 2013 at 04:46:43PM -0800, Shentino wrote:
> > On Fri, Feb 15, 2013 at 4:38 PM, Shentino <shentino@...il.com> wrote:
> > > On Fri, Feb 15, 2013 at 4:04 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> > >> How would you manage to have it masked at that point?  setup_new_exec()
> > >> is inevitable after success of flush_old_exec() and it will do
> > >> flush_signal_handlers() for us.
> > >
> > > I wouldn't know for sure but I read somewhere that even if execve
> > > resets handled signals, it didn't also say that ignored signals were
> > > also reset.  (Source: execve man page.)
> > 
> > Also, apologies for the terminology mix-up.  By masked, I mean that
> > the signal was ignored as directed by userspace a-la signal(SIGSEGV,
> > SIG_IGN).
> > 
> > Plus I *think* that signal ignore masks are preserved across an exec.
> 
> You are correct.  OK, what it means is that we do need that force_sigsegv() -
> either there or in all places in ->load_binary() where we currently have
> send_sig_info(SIGSEGV).  I don't think that it's an urgent hole, but yes,
> it is a bug.  Nice catch.

Arrgh...  OK, I'm a blind idiot.  These places in binfmt_elf.c currently use
force_sig(), not send_sig_info().  Currently == since 2006 when somebody
noticed the problem.  Their counterparts in binfmt_elf_fdpic.c were *not*
noticed.  Anyway, that definitely means we want to do it in a single commit;
the only remaining question is whether we have any problems with somebody
ptracing such execve() and then poking the sucker with ptrace(); that _can_
happen with the current mainline for ELF binaries, so this is not something
new.  I'm low on coffee and about to crash, so I might be missing some
horrible problem with it, but in this case I'm fairly sure that such a problem
would be present in current mainline.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/