This could be good.. But this could be bad. Running on a system with out
the shadow password suite, then this would work very easily,
running on a machine with a shadow password suite, it would atleast
require the shadow file to be group writeable to the GID you run
the program as. Which in most cases, shadow passwords are never readable
to a regular users group, otherwise what is the point of the shadow suite?
I personally am using this to my advantage, and wouldn't call it a bug,
but figured I would let you all, who may not have thought about this know.
If a non-priv'd user were to download the ssh source to their directory,
compile it with something like:
./configure --prefix=PREFIX=/home/user/ssh --sysconfdir=/home/user/ssh/etc/
That will configure ssh to put the bins and sbins in ~/ssh, and to put all
files that would be in /etc/ into /home/user/ssh/etc/
You can then run make and make install, which will generate your
ssh_host_key and all related files.
The user would then need to edit the sshd_config, and change the port to
> 1024 (i chose 2222), make sure its "use login no", unless login is
suid.. If login is suid, (i don't see why it would be, and it shouldn't
be), then /etc/shadow wouldn't need to be readable. And then change the
runpid to a writable directory to the user "~/ssh/var/".
I chose to do RSA authentication, so I used ssh-keygen to create a key
on the box side, and then put my identity.pub from my client, into
~/.ssh/authorized_keys, run your newly compiled sshd ~/ssh-1.2.27/sshd,
and it should read the correct config files, and launch ssh as 'user' on
port 2222.
You can then ssh to it, with just your RSA password (if you used a
password).
The good: If SSH had a remote BO, the only thing compromised is anything
in the group that /etc/shadow was r+w by.
The Bad: The user is not put into wtmp/utmp files.. and if they defined
their own sys files, or modified it in the ssh source, to not do
syslogging, then you wouldn't see any information about it in
syslog either. Which of course would make tracking users a little
harder, unless you have something that records processes, which
is usually pretty processor intensive. Without the marks of the
utmp/wtmp you will of course not see them in a 'w' or a 'who',
and you will not gain control of your tty either:
<logging in with RSA>
/dev/ttyp2: Operation not permitted
[server]-[user] ~*
user 15859 0.1 0.4 2184 784 p2 S 16:21 0:00 -bash
crw-rw-rw- 1 root root 3, 2 Aug 4 16:21 /dev/ttyp2
You will also note the following error in log going along with the above
problems with allocating a tty:
Aug 4 16:21:42 server sshd[15857]: debug: Allocating pty.
Aug 4 16:21:42 server sshd[15857]: debug: Ignoring unsupported tty mode opcode 11 (0xb)
Aug 4 16:21:42 server sshd[15857]: debug: Forking shell.
Aug 4 16:21:42 server sshd[15857]: debug: Entering interactive session.
If a user tries to do this without /etc/shadow being readable to them, or
their group, you will notice in your debug log:
Aug 4 16:21:29 server sshd[15855]: debug: Can't find user's shadow - access denied.
(unless of course, they made it so it doesn't log to syslog)
Sorry for the length, just thought I'd pass it on, for those who hadn't
already thought of this.
Erik Parker
eparkerat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:55:11 PDT