[Pkg-shadow-devel] Bug#505071: Bug#505071: login tty mis-determination (see bug#332198)

[Paul Szabo]

Dear Nicolas (Nekral?),

> First of all, this issue was already discussed, and the main problem was
> that we were not able to reproduce it.

Yes, I am aware of bug #332198.

> Are you currently able to reproduce it?

Have not yet attempted to actively reproduce, have observed one
occurrence of "spontaneous" bad behaviour.

> That would help us a lot, since this would allow testing instrumentation
> of login to find the root cause.
> Would you agree testing some patches?

Yes, would be happy to test.

>> I found in my logs (I think first occurrence of such mis-behaviour):
>> 
>> Nov  8 05:50:09 rome in.telnetd[21060]: connect from psz at bari.maths.usyd.edu.au (129.78.69.145) 
>> Nov  8 05:50:12 rome login[21062]: (pam_unix) session opened for user root by (uid=0) 
>> Nov  8 05:50:12 rome login[21062]: can't stat(`/dev/smb/39'): errno 2  
>> Nov  8 05:50:12 rome login[21062]: unable to determine TTY name, got /dev/smb/39  
>> 
>> Surely that Samba device is wrong for a telnet session...
>
> You logged in with telnet, right?
> Do you know the version of telnet you are using?
> Do you know if telnet creates a utmp entry before calling login?

Yes, with telnet; version 0.17-34 (debian etch); surely it cannot
possibly create utmp (telnet runs on bari, telnetd on rome).

> What might be happening is that telnet do not create a utmp entry, and an
> old one from samba is reused (in checkutmp). This should be very rare also
> because the bug would occur only if the same pid is reused. 

Yes, I agree that this is a re-use of an old "unclosed" utmp entry.
(Samba is in the habit of leaving such unclosed entries.) My logs show
(much earlier than the above-quoted lines):

Nov  7 00:52:02 rome samba[21062]: Connect IPC_ for smbguest from p706f (p706f.pc.maths.usyd.edu.au, 129.78.223.215) 

and I did not notice other utmp uses for the same PID in between.

---

Seems to me that the picking of utent in checkutmp by PID (and type?)
only is naive, should pick by line (or id) also, in fact pick by the
is_my_tty checks.

---

File src/login.c has line 87
  extern struct utmp utent;
whereas file libmisc/utmp.c has line 48
  struct utmp utent;
without extern: is that correct?

---

Other comments. Am worried that relying on utmp correctness is a
security risk: conceptually because group utmp would become
root-equivalent, and practically because of shenanigans with utmp
writing e.g. bugs #329156 #330907.

In file libmisc/chowntty.c :
- line 51: should the call
    (stat (tty, &by_name))
  be changed to lstat? Avoid being fooled by symlinks.
- line 66: is the check
    (by_name.st_rdev != by_fd.st_rdev)
  sufficient: can it be fooled with symlinks or hardlinks?
- lines 122,123: should chown(tty,...) and chmod(tty,...) be changed to
  fchown(0,...) and fchmod(0,...)? Avoid being fooled by symlinks and
  races.

Seems to me that as things stand, writing a suitable utmp entry, would
trick login into chowning an arbitrary file. Should I attempt to write
an exploit/demo?

---

Cheers,

Paul Szabo   psz at maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia