[Bug 363593] Re: login, newgrp leak /etc/shadow

2009-04-21 Thread Kees Cook
Thanks for investigating, I'll close this bug for now. ** Changed in: shadow (Ubuntu) Status: New => Invalid -- login, newgrp leak /etc/shadow https://bugs.launchpad.net/bugs/363593 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 363593] Re: login, newgrp leak /etc/shadow

2009-04-21 Thread Paul Szabo
I now got my test program reading /proc/self/mem to work, and it seems that neither getspnam() nor getspent() leave "garbage" in memory: no security risk. Cheers, Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney

Re: [Bug 363593] Re: login, newgrp leak /etc/shadow

2009-04-19 Thread Kees Cook
On Sun, Apr 19, 2009 at 12:57:26PM -, Paul Szabo wrote: > Since I do not know how getspent() or endspent() work, I now wonder > whether chunks of /etc/shadow (other than the line for right user) could > be found in process memory, before or after endspent(). Have so far > failed to read /proc/s

[Bug 363593] Re: login, newgrp leak /etc/shadow

2009-04-19 Thread Paul Szabo
Now testing Debian etch, 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. Sorry about the noise. Since I do not know how getspent() or endspent() work, I now wonder whether chu

[Bug 363593] Re: login, newgrp leak /etc/shadow

2009-04-18 Thread Paul Szabo
Hmm... maybe in fact there is no problem? Testing Debian, 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 Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics an