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

Paul Szabo psz at maths.usyd.edu.au
Sun Nov 9 21:51:53 UTC 2008

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 ( 
>> 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, 

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

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?



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

More information about the Pkg-shadow-devel mailing list