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
(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.
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.
(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
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 ?
(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
untagging release target until we understand what is going on here.
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
Hi Darren, Can you please share your views on this ? Thanks
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?