openssh bugs - Sep 2013 - [Bug 2155] New: sftp program has tty attributes setting problem

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

            Bug ID: 2155
           Summary: sftp program has tty attributes setting problem
           Product: Portable OpenSSH
           Version: 5.3p1
          Hardware: ix86
                OS: Linux
            Status: NEW
          Severity: critical
          Priority: P5
         Component: sftp
          Assignee: unassigned-bugs at mindrot.org
          Reporter: wzis at hotmail.com

the sftp program in RHEL 6.1/6.2/6.3/6.4 has a bug in tty settings.

The 5.3p1 sftp program used in RHEL 6.1/6.2/6.3/6.4, and Ubuntu 12.04
LTS has tty attributes setting problem.

Steps to Reproduce:
1. stty -echo
2. sftp user at server
3. key in pass as prompted.
4. cd /tmp
5. ls
6. bye
7. stty -a


Actual results:
The entered sftp sub-commands in step 4 to step 6 are visible, and the
OS command entered after sftp in step 7 is also visible.


Expected results:
Those inputs entered in step 4 to step 7 shouldn't be visible.
This is for security reason we want to hide the sftp subcommands when
presented in the menu for user to get files.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #1 from Darren Tucker <dtucker at zip.com.au> ---
I can't reproduce this on a fedora 18 box with openssh-5.3p1, built
with or without libedit ("libedit-3.0-7.20120601cvs").

My guess is that it's actually a bug in libedit.

have you reported this to ubuntu?  can you reproduce it with the
vanilla source from openssh.com?  with or without libedit?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

--- Comment #2 from wzis <wzis at hotmail.com> ---
I reported the issue to ubuntu, but they said I need to report it in
upstream.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

--- Comment #3 from Darren Tucker <dtucker at zip.com.au> ---
who from ubuntu said that?  is there an ubuntu or redhat bugreport?

IMO that attitude from a vendor is laziness on their part.  They're
shipping an old, modified version of openssh, so it's their
responsibility to investigate problems to a) make sure it's not due to
their changes, b) not already fixed and c) the problems are reported
against the right upstream.

In this case, I happen to have an ubuntu 12.04 VM, and I can't
reproduce the problem without libedit, but *can* reproduce it
--with-libedit (2.11-20080614-3ubuntu2) but not on Fedora (which has
libedit 3.0-7.20120601).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

--- Comment #4 from wzis <wzis at hotmail.com> ---
Agree with you: here is the bug reported to ubuntu:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1225327

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

--- Comment #5 from wzis <wzis at hotmail.com> ---
So, based on your test, it's libedit caused the problem for ssh/sftp.
This is the first time I reported bug to ubuntu, and found them not so
helpful.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

--- Comment #6 from wzis <wzis at hotmail.com> ---
I did a test on Fedora 19: found it also has a problem: the
sub-commands in sftp are still visible, but after exits from sftp, the
setting recovered. Could you try on the Fedora 18 you have, using the
Fedora's sftp?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

--- Comment #7 from Darren Tucker <dtucker at zip.com.au> ---
fedora 18's sftp does do it, but the one I built doesn't (although
it's
linked against a locally built libedit in /usr/local, which I had not
noticed):

$ stty -echo; /usr/bin/sftp -o preferredauthentications=password
localhost; stty sane
dtucker at localhost's password: 
Connected to localhost.
sftp> cd /tmp
sftp> exit

$ ldd /tmp/openssh-5.3p1/bin/sftp | grep libed
    libedit.so.0 => /usr/local/lib/libedit.so.0 (0xb7744000)

$ stty -echo; /tmp/openssh-5.3p1/bin/sftp -o
preferredauthentications=password localhost; stty sane
Connecting to localhost...
dtucker at localhost's password: 
sftp> sftp> Remote working directory: /tmp
sftp> 

$ rpm -q libedit
libedit-3.0-7.20120601cvs.fc18.i686

the local one is libedit-20100424-3.0

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

--- Comment #8 from Darren Tucker <dtucker at zip.com.au> ---
repeated the test with libedit-20130712-3.1 and it fails.  so:

20100424: works
20120601: fails
20130712: fails

I'd be taking a pretty close look at this change, which was just before
the 20120601 release:L

http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/tty.c?rev=1.42&content-type=text/x-cvsweb-markup&sortby=date

save and restore the tty settings on entry and exit respectively.
cleanup debugging printfs

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

robie.basak at ubuntu.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |robie.basak at ubuntu.com

--- Comment #9 from robie.basak at ubuntu.com ---
> IMO that attitude from a vendor is laziness on their part.  They're
> shipping an old, modified version of openssh, so it's their 
> responsibility to investigate problems to a) make sure it's not due to 
> their changes, b) not already fixed and c) the problems are reported 
> against the right upstream.
Hi. I triaged this bug in Ubuntu. I feel that I have been mispresented
here.

I appreciate that I shouldn't be sending bugs upstream without checking
them first, being reasonably confident that they affect the latest
upstream release and have not been introduced by the distribution.

I did NOT say that this bug was ready to be reported upstream. I
specifically said that the bug needed to be tested against the latest
upstream release without distribution patches, and only in that case
should the bug be reported upstream.

I said: "Could you please test the latest upstream release, and if this
still affects the upstream release without distribution patches, file a
bug in the upstream bug tracker to get upstream's opinion?"

In the case of this particular bug I wasn't even sure if this was
expected behaviour by design. I do not wish to diverge from upstream on
behaviour such as this. So if verified that this affected the latest
upstream release without distribution patches, I then wanted to check
with you if you considered this behaviour a bug at all.

I'm sorry that it didn't occur to me that you were depending on another
library for this functionality. As you can see from the bug, I didn't
get that far.

Rather than laziness, we are in a situation where far too many bugs are
reported, and there aren't enough bug triagers to keep up. So rather
than have bugs languish forever, I prefer to note in the bug what
actions need to be taken next to empower the reporter to do them to at
leave the option of making progress. Bugs affecting only one person
after over a year of release tend not to get looked at any other way.

Again, I did not intend to get you involved without a reporter having
done basic checks to ensure that your latest release was affected, and
I apologise for the noise.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

--- Comment #10 from wzis <wzis at hotmail.com> ---
It seems to me that the proper solution to make ssh/sftp work as on
other UNIX platforms is compile it without using the "--with-libedit":
the functions provided by libedit are not necessary to run ssh/sftp and
not that useful in use ssh/sftp also: the openssh is used on all other
UNIX platforms without the libedit, and I don't think those UNIX
vendors have received any meaningful number of complaints for not
having libedit. With libedit, openssh lost control to the tty settings
which caused end user not able to control whether they want to hide the
sftp sub-commands.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |minor

--- Comment #11 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to robie.basak from comment #9)
> I feel that I have been mispresented here.
I get that impression after having read the ubuntu bug, so my
apologies.

anyway, having looked at this some more I'm not convinced it's a bug,
or at least that that fact that it behaves that way without libedit is
anything more than an implementation detail.  Even in batch mode, sftp
makes a point of echoing the commands:

    if (!interactive) { /* Echo command */
            printf("sftp> %s", cmd);

I also tried disabling libedit ("sftp:edit off" in ~/.editrc) however
that didn't change the behaviour.

@wzis what exactly are you trying to do here?  ie what's the objective
of the exercise?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

--- Comment #12 from wzis <wzis at hotmail.com> ---
By right, a well behaved program should handle the echo only at the
necessary point: for example, to read password/passphrase, the echo
needs be turned off, but after that, echo should be recovered to what
user set. If the program wants to make sure a string be visible, it
should explicitly output it, not by turn on the echo when user wants to
turn it off. Only that way, both program can work properly and user's
requirement can be met.
We use that feature to give user a menu to download files, but not let
user see which files.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

--- Comment #13 from wzis <wzis at hotmail.com> ---
By the way, if the program outputs the command, our program can receive
the outputs and filters them out. So, that's still ok. But turn the
echo on is not what other program can revert it back, that's a bug.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |djm at mindrot.org
         Resolution|---                         |FIXED

--- Comment #14 from Damien Miller <djm at mindrot.org> ---
sftp now offers a way to selectively disable command echo in batch
mode. You can use this if you want no echo, but we have no plans to
change the default.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2155

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #15 from Damien Miller <djm at mindrot.org> ---
Close bugs fixed in openssh-8.1 release cycle

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.