Dear Nicolas,
> They should be fixed now.
Thanks, things seem OK now.
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.de
Dear Nicolas,
> It works when you use a tool which sets UTMP before it provides the shell.
> telnetd does not, but for example xterm does.
More to the point: login does not. To belabour the point: if you "come"
from login (e.g. via telnet), then login provides a utmp entry, but that
refers to the
On Mon, Apr 27, 2009 at 06:51:11AM +1000, p...@maths.usyd.edu.au wrote:
> Dear Nicolas,
>
> >> But mainly, "exec login" cannot possibly work in a PAM environment, but
> >> will fail/die and "lose" the user session; users should not be tricked
> >> into doing that. Presumably the user logged in wit
Dear Nicolas,
>> But mainly, "exec login" cannot possibly work in a PAM environment, but
>> will fail/die and "lose" the user session; users should not be tricked
>> into doing that. Presumably the user logged in with login (e.g. telnet,
>> may not apply for ssh or xterm); then login done a fork b
Hello,
On Wed, Apr 22, 2009 at 10:41:21AM +1000, p...@maths.usyd.edu.au wrote:
>
> Had a quick look at src/login.c and libmisc/utmp.c, and see the "plain"
> (not security) issues below. - The enspent() block should be moved up
> in newgrp.c also.
Thanks for checking this.
They should be fixed no
On Sat, Apr 25, 2009 at 09:57:41PM +1000, p...@maths.usyd.edu.au wrote:
> Dear Nicolas,
>
> Comments on (snippet of code comments, and your words):
>
> >> * but users must "exec login" which will use the existing utmp
> >> * entry (will not overwrite remote hostname). --marekm
> >
> > My
Dear Nicolas,
Comments on (snippet of code comments, and your words):
>> * but users must "exec login" which will use the existing utmp
>> * entry (will not overwrite remote hostname). --marekm
>
> My point would be: In case login is setuid, shall we require that it is
> called with
Dear Nicolas,
Had a quick look at src/login.c and libmisc/utmp.c, and see the "plain"
(not security) issues below. - The enspent() block should be moved up
in newgrp.c also.
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistic
Hello,
I've committed a new utmp handling for login.
I also hope it fixes other concerns raised in the thread.
I would appreciate if you could have a look:
http://svn.debian.org/viewsvn/pkg-shadow/upstream/trunk/
Thanks in advance,
--
Nekral
--
To UNSUBSCRIBE, email to debian-bugs-dist-req
I now got my /proc/self/mem-reading test program to work, and it
seems that neither getspnam() nor getspent() leave "garbage" in
memory: no security risk. - Am wondering if the call to endspent()
is needed, when apparently there is no setspent() anywhere; still,
it can do no harm (other than to con
Dear Nicolas,
> I've added the missing endutent / endutxent.
Thanks.
>> Seems to me that su.c needs endgrent() for when SU_WHEEL_ONLY (this is
>> not a security issue).
>>
>> In newgrp.c also, endpwent() needs to be moved to before the UID/GID
>> change (as was in login.c); I do not give patche
On Sun, Apr 19, 2009 at 10:53:50PM +1000, p...@maths.usyd.edu.au wrote:
>
> Now testing, seems that just before the endspent() etc calls, login has
> a file descriptor open on /etc/passwd but does not have one for
> /etc/shadow. Seems there is no security issue. (Is this weird behaviour
> in libc?
Hello,
On Sun, Apr 19, 2009 at 09:06:38AM +1000, p...@maths.usyd.edu.au wrote:
>
> Thanks. New patches (replacing my previous ones) below, including the
> move of endpwent(), and more verbose comments. The patch for login.c
> is essential. The patch for utmp.c is mostly "as you wish"; there is a
Dear Nicolas,
I wrote:
>> ... Do these [entspent] moves warrant a DSA?
> Maybe not. Testing, it seems that getspnam() does not leave an open file
> descriptor, but setspent() would. (I do not know what /bin/login does
> exactly.)
Now testing, seems that just before the endspent() etc calls, logi
Dear Nicolas,
> ... Do these [entspent] moves warrant a DSA?
Maybe not. Testing, it seems that getspnam() does not leave an open file
descriptor, but setspent() would. (I do not know what /bin/login does
exactly.)
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u
Dear Nicolas,
> I changed src/login.c
> in libmisc/utmp.c, I only sanitized ut_line.
Thanks. New patches (replacing my previous ones) below, including the
move of endpwent(), and more verbose comments. The patch for login.c
is essential. The patch for utmp.c is mostly "as you wish"; there is a
mi
Hello,
On Sat, Apr 18, 2009 at 04:28:57PM +1000, p...@maths.usyd.edu.au wrote:
>
> Is shadow used on non-Linux or non-PAM machines: do you need to worry
> about code within the likes of
> #ifndef USE_PAM
> ...
> #endif
> #ifdef __linux__
> #else
> ...
> #endif
> ?
shadow is used on non-PAM machi
Dear Nicolas,
Sorry but it occurs to me I was not clear enough in my previous message.
My question of "is shadow used on non-Linux or non-PAM machines" relates
to utmp handling: does it need to handle those cases also?
Thanks, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.
Dear Nicolas,
Is shadow used on non-Linux or non-PAM machines: do you need to worry
about code within the likes of
#ifndef USE_PAM
...
#endif
#ifdef __linux__
#else
...
#endif
?
If yes, I guess the final endpwent() group in login.c should be moved up
to before setup_uid_gid().
Thanks, Paul
Paul
reopen 505071
thanks
Hello,
On Fri, Apr 17, 2009 at 07:55:23AM +1000, p...@maths.usyd.edu.au wrote:
>
> Please see below. The patch of src/login.c is essential for security;
> I would prefer to use the libmisc/utmp.c patch also.
I changed src/login.c
in libmisc/utmp.c, I only sanitized ut_line
Dear Nicolas,
> ... If you want to change the utmp handling ...
Will think about that, and get back to you in a few days.
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
--
To UNS
>> Thus an attacker could:
>> - cause securetty checks to fail resulting in a DoS, or
>> - bypass or trick some checks in pam_time or pam_group.
> Please state more clearly ...
We have seen how utmp entries can be "fudged", left behind, with or
without access to group utmp.
Suppose a utmp entry
Dear Nicolas,
> Please state more clearly ...
> If I have to look again ... it is a waste of time.
That discussion is not fruitful.
> If you have ... patches, they are welcomed.
Please see below. The patch of src/login.c is essential for security;
I would prefer to use the libmisc/utmp.c patch
Hello,
On Thu, Apr 16, 2009 at 07:59:17PM +1000, p...@maths.usyd.edu.au wrote:
>
> > We believe that the bug you reported is fixed in ...
> > login_4.1.3-1_i386.deb ...
>
> The untrusted ut_line is now internally used for utmp only (so there
> should be no security issues there), but is passed t
Dear Nicolas,
> We believe that the bug you reported is fixed in ...
> login_4.1.3-1_i386.deb ...
The untrusted ut_line is now internally used for utmp only (so there
should be no security issues there), but is passed to PAM as PAM_TTY.
Thus an attacker could:
- cause securetty checks to fail re
25 matches
Mail list logo
