openssh bugs - May 2018 - [Bug 2872] New: wall command shows error when logged in through non-root user.

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

            Bug ID: 2872
           Summary: wall command shows error when logged in through
                    non-root user.
           Product: Portable OpenSSH
           Version: 7.5p1
          Hardware: PPC
                OS: AIX
            Status: NEW
          Severity: security
          Priority: P5
         Component: Miscellaneous
          Assignee: unassigned-bugs at mindrot.org
          Reporter: mayasha9 at in.ibm.com

Hi

I have compiled and installed OpenSSH7.5 on AIX. I ran wall command
after logging through non-root via ssh and i found that wall command is
throwing error.

Recreation Steps:-
-----------------

1. SSH login through non-root user USER1 on different terminal.
2. SSH login through non-root user USER2 on different terminal.
3. run "wall test" on USER1 terminal. Following error message will
occurred.

wall: Cannot open "/dev/pts/X".  The file access permissions do not
allow the specified action..


I analysed further and i came to know that in file sshpty.c, mode has
been set to 600.

void
pty_setowner(struct passwd *pw, const char *tty)
{
.
.
.
        /* Determine the group to make the owner of the tty. */
        grp = getgrnam("tty");
        gid = (grp != NULL) ? grp->gr_gid : pw->pw_gid;
        mode = (grp != NULL) ? 0620 : 0600;

        /*
         * Change owner and mode of the tty as required.
.
.
.

Then I checked the older SSH builds and there I found that community
has changed modes in OpenSSH6.8_p1 and OpenSSH7.0_p1 respectively.
Please follow the commit link below -

https://github.com/openssh/openssh-portable/commit/6f941396b6835ad18018845f515b0c4fe20be21a#diff-49e4e431bffb87ccf87cea3ce20c82f3

https://github.com/openssh/openssh-portable/commit/a5883d4eccb94b16c355987f58f86a7dee17a0c2#diff-49e4e431bffb87ccf87cea3ce20c82f3

If I changed modes permission from 600 to 620 and run the same wall
command, then in such case it was not throwing any error message.

Therefore , i would like to know whether these mode changes are made
intentionally or it is possible to rectify it ?

Please let me know soon.

Thanks & Regards
Mayank Sharma

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

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net
          Component|Miscellaneous               |sshd

-- 
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=2872

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned-bugs at mindrot.org |dtucker at dtucker.net
             Status|NEW                         |ASSIGNED

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

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

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Mayank Sharma from comment #0)
[...]
> If I changed modes permission from 600 to 620 and run the same wall
> command, then in such case it was not throwing any error message.
That implies that /usr/sbin/wall is setgid?  If so wha are the
permissions on /usr/sbin/wall and the pts devices?

On my (admittedly obsolete) AIX 5.1 system wall is not setgid, although
it's possible I changed it some time in the past:

$ ls -l /usr/sbin/wall
-r-xr-xr-x   1 bin      bin           12720 Jan 15 2003  /usr/sbin/wall
$ ls -l /dev/pts/{0,100}
crw-------   1 dtucker  system       28,  0 Jun 01 13:41 /dev/pts/0
crw-rw-rw-   1 root     system       28,100 Jul 03 2003  /dev/pts/100
> Therefore , i would like to know whether these mode changes are made
> intentionally or it is possible to rectify it ?
Restricting the permissions was deliberate.  If there's a specific
group that's the equivalent of "tty" on AIX then we could
potentially
use that and end up with mode 0620 pty devices.

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

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |2852


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2852
[Bug 2852] Tracking bug for OpenSSH 7.8 release
-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

--- Comment #2 from Mayank Sharma <mayasha9 at in.ibm.com> ---
Hi Darren,

Thanks for your reply. I have checked the permissions for wall and pts
which I pasted below-

# ls -l /usr/sbin/wall
-r-xr-xr-x  1 bin  bin  13018 Apr 27 04:16 /usr/sbin/wall

# ls -l /dev/pts/
total 0
crw--w--w-    1 root     system       22,  0 Jun 01 02:04 0
crw--w--w-    1 root     system       22,  1 Jun 01 02:04 1
crw-rw-rw-    1 root     system       22, 10 May 07 02:26 10
crw-rw-rw-    1 root     system       22,100 May 07 02:26 100
.
.
.

Permissions are same as you mentioned in your mail.

-- 
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=2872

--- Comment #3 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Mayank Sharma from comment #2)
> Thanks for your reply. I have checked the permissions for wall and
> pts which I pasted below-
This doesn't make sense with what you said earlier: "I changed modes
permission from 600 to 620 and run the same wall command, then in such
case it was not throwing any error message."
> # ls -l /usr/sbin/wall
> -r-xr-xr-x  1 bin  bin  13018 Apr 27 04:16 /usr/sbin/wall
This doesn't have any special permissions.
> # ls -l /dev/pts/
> total 0
> crw--w--w-    1 root     system       22,  0 Jun 01 02:04 0
This would be mode 622 not 620 as you described earlier.

These ones have probably never been used and are presumably the default
permissions:
> crw-rw-rw-    1 root     system       22, 10 May 07 02:26 10
> crw-rw-rw-    1 root     system       22,100 May 07 02:26 100
-- 
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=2872

--- Comment #4 from Mayank Sharma <mayasha9 at in.ibm.com> ---
Hi Darren,

Let me clarify this further :

On my AIX machine, currently we have 3 terminals opened as seen below :
# who
root        pts/0       Jun 01 05:05     
root        pts/1       Jun 01 02:19     
root        pts/2       Jun 01 06:11     


Now when we try to open a new terminal then pts/3 should get allocated
and ssh will change the terminal permissions accordingly.


So before opening the terminal we have the below permissions :
: /dev/pts
# ls -l 3
crw-rw-rw-    1 root     system       19,  3 Jun 01 06:28 3

After SSH session is opened and terminal 3 is assigned then the
terminal permissions changes as shown below:
: /dev/pts
# ls -l 3
crw-------    1 mayank   staff        19,  3 Jun 01 06:30 3
# who
root        pts/0       Jun 01 05:05     
root        pts/1       Jun 01 02:19     
root        pts/2       Jun 01 06:11     
mayank      pts/3       Jun 01 06:30  <---- terminal 3 assigned to
non-root user


Here, what we see is that modes of terminal 3 has been changed to 600
(since we dont have tty group) as per the below code:

File: sshpty.c

void
pty_setowner(struct passwd *pw, const char *tty)
{
.
.
.
        /* Determine the group to make the owner of the tty. */
        grp = getgrnam("tty");
        gid = (grp != NULL) ? grp->gr_gid : pw->pw_gid;
        mode = (grp != NULL) ? 0620 : 0600;

        /*
         * Change owner and mode of the tty as required.
.
.
.

In this scenario, if we try to run wall command then it fails with the
error message as I mentioned in comment 1.


Now we tried to change the modes in pty_setowner function and replace
it with permissions as per openssh release before 6.8 version.
So, as per the commit
https://github.com/openssh/openssh-portable/commit/a5883d4eccb94b16c355987f58f86a7dee17a0c2#diff-49e4e431bffb87ccf87cea3ce20c82f3

We see in the case of 'else' part, the modes has been changed from
mode = S_IRUSR | S_IWUSR | S_IWGRP | S_IWOTH;
to
mode = (grp != NULL) ? 0622 : 0600;
The S_IWGRP and S_IWOTH permission is missing in the 'else' part.
Hence, we modified the code as :
void
pty_setowner(struct passwd *pw, const char *tty)
{
.
.
.
        /* Determine the group to make the owner of the tty. */
        grp = getgrnam("tty");
        gid = (grp != NULL) ? grp->gr_gid : pw->pw_gid;
/*      mode = (grp != NULL) ? 0620 : 0600; */
        mode = (grp != NULL) ? 0620 : 0620; 

        /*
         * Change owner and mode of the tty as required.
.
.
.
With this modification, we didnot see the issue with wall command. Can
you please let us know if our changes are valid ?

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

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

--- Comment #5 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Mayank Sharma from comment #4)
> With this modification, we didnot see the issue with wall command.
> Can you please let us know if our changes are valid ?
I don't understand how your change helped.  Unless the user in question
is in the "system" group, in which case it still won't work for
normal
users.

On modern systems I'd expect the wall binary to be setgid tty so it can
write to the terminal devices without having them writable by any
process, eg on Ubuntu:

$ ls -l `which wall`
-rwxr-sr-x 1 root tty 31512 Mar  7 08:31 /usr/bin/wall

-- 
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=2872

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org
             Blocks|2852                        |

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
untagging release target until we understand what is going on here.


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2852
[Bug 2852] Tracking bug for OpenSSH 7.8 release
-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

--- Comment #7 from Mayank Sharma <mayasha9 at in.ibm.com> ---
Hi Darren,

I checked the source code of wall command for setgid call, in the
latest AIX7.1 release and I found that wall is not invoking any setgid
call. 

# ls -l `which wall`
-r-xr-xr-x    1 bin      bin           13410 May 24 15:47
/usr/sbin/wall

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

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

--- Comment #8 from Mayank Sharma <mayasha9 at in.ibm.com> ---
Hi Darren,

Can you please share your views on this ?

Thanks

-- 
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=2872

--- Comment #9 from Darren Tucker <dtucker at dtucker.net> ---
I have two concerns:

 - I don't see how your change fixes it in the general case.  Given the
wall binary was not set[ug]id, how was your test user able to write to
a mode 620 $user:$group pty?  Given /dev/pts/3 in your example is has
user:group mayank:staff I suspect both sender and recipients were
members of "staff".

 - I don't see anything that sshd can currently do on AIX that does not
reintroduce the unsafe behaviour we're trying to prevent.  Rereading
the discussion around CVE-2015-6565 (and in particular
http://openwall.com/lists/oss-security/2017/01/31/13) it looks like
that specific attack was a race in the Linux kernel, but my concern is
that there's similar attacks on other platforms.

Is it feasible to add a "tty" group make /usr/bin/wall setgid tty?

-- 
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.