sobomax 1f19a8fc75 Fix bug in the readpassphrase(3) function, which can be exposed
by application closing its stdin (i.e. STDIN_FILENO) prior to
calling readpassphrase WITHOUT setting RPP_STDIN. What happens
then is that the readpassphrase would open /dev/tty, and since
file descriptors are reused, the call would return first unused
fd, which is 0 which is also STDIN_FILENO. Then due to the usage
of "input != STDIN_FILENO" in the code to do its logic, that
would result in noecho flags not set on that file descriptor,
which was original issue I've been trying to fix.

In addition to that, the readpassphrase() would leak file
descriptor on its way out, so fix that one as well.

This problem can be tested with:

 $ ssh-add - < /tmp/myprivate.key

The password will not be hidden as it should and ktrace will
show:

 53326 ssh-add  CALL  open(0x80142443c,0x100002<O_RDWR|O_CLOEXEC>,<unused>0x165f030)
 53326 ssh-add  NAMI  "/dev/tty"
 53326 ssh-add  RET   open 0
 53326 ssh-add  CALL  sigprocmask(SIG_SETMASK,0x802eb1324,0x7fffffffd5e0)
 53326 ssh-add  RET   sigprocmask 0
 53326 ssh-add  CALL  sigaction(SIGALRM,0x7fffffffd630,0x7fffffffd610)

Instead of:

 57690 ssh-add  CALL  open(0x80142443c,0x100002<O_RDWR|O_CLOEXEC>,<unused>0x165f030)
 57690 ssh-add  NAMI  "/dev/tty"
 57690 ssh-add  RET   open 4
 57690 ssh-add  CALL  ioctl(0x4,TIOCGETA,0x7fffffffd860)
 57690 ssh-add  RET   ioctl 0
 57690 ssh-add  CALL  ioctl(0x4,TIOCSETAF,0x7fffffffd680)
 57690 ssh-add  RET   ioctl 0
 57690 ssh-add  CALL  sigprocmask(SIG_SETMASK,0x802eb1324,0x7fffffffd620)
 57690 ssh-add  RET   sigprocmask 0
 57690 ssh-add  CALL  sigaction(SIGALRM,0x7fffffffd670,0x7fffffffd650)

For the case when the key is read from the file.

Technically this can also be workaround'ed at the application side
by not closing the STDIN_FILENO in the first place, but readpassphrase(3)
doesn't need to make any assumptions about that. Plus the file descriptor
leak confirms that this is an oversight, rather than a deliberate behaviour.

MFC after:	1 week
2016-01-24 22:20:13 +00:00
..
2011-11-26 16:49:25 +00:00
2012-08-11 12:07:24 +00:00
2011-10-01 12:19:48 +00:00
2011-10-01 12:19:48 +00:00
2015-09-20 20:21:49 +00:00
2013-08-18 13:25:18 +00:00
2015-09-20 20:21:49 +00:00
2015-09-20 20:21:49 +00:00
2012-04-26 19:21:58 +00:00
2011-05-25 14:13:53 +00:00
2015-09-20 20:21:49 +00:00
2015-02-15 21:11:07 +00:00
2015-09-14 18:44:13 +00:00
2015-09-14 18:44:13 +00:00
2015-04-26 10:29:43 +00:00
2011-12-20 22:56:13 +00:00
2015-12-20 11:55:39 +00:00
2015-04-26 10:56:06 +00:00
2015-04-26 10:52:37 +00:00
2015-04-26 10:52:37 +00:00
2015-04-26 10:52:37 +00:00
2015-04-26 10:52:37 +00:00
2015-04-26 10:52:37 +00:00
2015-04-26 10:52:37 +00:00
2015-04-26 10:52:37 +00:00
2015-04-26 10:52:37 +00:00
2015-04-26 10:52:37 +00:00
2012-03-26 15:18:14 +00:00
2011-02-04 16:40:50 +00:00
2015-09-20 20:21:49 +00:00
2013-04-23 13:03:03 +00:00
2012-12-12 15:27:33 +00:00
2015-02-17 16:01:00 +00:00
2015-09-20 20:21:49 +00:00
2015-09-20 20:21:49 +00:00
2015-09-20 20:21:49 +00:00
2015-09-20 20:21:49 +00:00
2015-09-20 20:21:49 +00:00
2015-09-20 20:21:49 +00:00