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 [EMAIL PROTECTED]
>> (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 [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
