develooper Front page | perl.perl5.porters | Postings from December 1999

Re: getspnam-support

Thread Previous | Thread Next
From:
John Macdonald
Date:
December 5, 1999 19:56
Subject:
Re: getspnam-support
Message ID:
199912060342.WAA24088@elegant.com
Tom Christiansen <tchrist@jhereg.perl.com> writes:
|| Ok, fine.  Let's assume that you have both getpwnam() and getspwnam()
|| available from a program.  If an attacker is going to tickle a Perl
|| program with a buffer-overrun exploit, he can trivially make *ANY PERL
|| PROGRAM* call getspwnam(), even those scripts that don't appear to use it.
|| In fact, although it isn't pretty, I have it on reasonable authority
|| that a buffer-overrunnable program can, given enough work, be made to
|| call anything in any shared library that you like to.

More likely than an attacker being able to take advantage of
this is the possibility of a bug in a program dumping the wrong
field and printing the actual password instead of '*'.

|| So, given that the BSD getpwnam behaviour makes no difference when it
|| comes to buffer overruns, could you please explain some *other* sort
|| of exploit to which we would now be vulnerable given the current set-up
|| but which under the painful separate calls, we would not be?  
|| 
|| Keep in mind, please, that if the status quo were altered, that you
|| wouldn't just be breaking existing code.  You'd be breaking existing code
|| which had been written to perform some sort of security-minded operation.
|| I'd say that this rather ups the ante of whether to break things.

And it could also be fixing some code that was *not* written to
perform some sort of security-minded operation but which was
given security-critical data anyhow and is a security leak
waiting to be noticed.

--
John Macdonald     jmm@jmm.pickering.elegant.com

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About