Front page | perl.perl5.porters |
Postings from December 1999
Re: getspnam-support
Thread Previous
|
Thread Next
From:
John Macdonald
Date:
December 4, 1999 09:57
Subject:
Re: getspnam-support
Message ID:
199912041753.MAA15906@elegant.com
Tom Christiansen <tchrist@jhereg.perl.com> writes:
|| >There's a small difference between being able to look at the memory contents
|| >(or crash dump) of a root program, and actually being able to make it do
|| >system calls which weren't in the original blueprints.
||
|| Well, yes--you're right. The difference is readability versus
|| writability. But being able to read things is still
|| rather powerful; see /dev/kmem. And you can't get coredumps
|| out of setuid program. If you can, your system has many
|| other problems.
||
|| >The former kind of attack is useless against a program which doesn't _have_
|| >any security-critical information in its memory, for the very simple
|| >reason that it doesn't need it in the first place.
||
|| >If I had no problem with having sensitive information in programs which
|| >have no business reading it, I'd not need a shadow password file.
||
|| Don't you mean that if you had no problem with having sensitive
|| information in *files* which have no business being readable, I'd not
|| need a shadow password file? And isn't this different?
There are similarities. A program that is designed to be careful about
security because it is deliberately getting the password string is like
the shadow file with carefully set non-readability. A program that is
expecting to get only the other, non-secure, account info is like the
general-read file.
Providing the password to all root programs means that any program that
*might* be run by root is in that first class and must be written with
security in mind, even if it doesn't actually need the password. If
the password is only provided by explicit request, then it is possible
to write programs of the second class that can be run by root. For
them there is no need to be especially carefully about leaking account
information because they don't have the security-critical portion.
Using getpw* instead of getspw* is all the security measure that the
second class of program needs to do. But if the getpw* call is always
turned into a getspw* call, the program is no longer carefully designed.
|| Seriously, this is the way BSD does it, and it really works out much
|| easier for the programmer this way. If you can convince their security
|| mavens that what you're afraid of does in fact constitute a clear
|| and present danger under the current set-up, then Perl should perhaps
|| begin to worry it, too. Possibly the easist way to do this would be to
|| take an existing program of theirs and show how it can be used to gain
|| unauthorized access.
||
|| Then again, if you do manage to get my password string, you're
|| still going to have an annoying problem:
||
|| DB<1> x getpwnam("tchrist")
|| 0 'tchrist'
|| 1 '$2a$06$XjEpnngzYwjg4vNOB1d5VuBi6zz.ux8u315PQFMKG/0gRfeKJo.vW'
|| 2 1000
|| 3 1000
|| 4 0
|| 5 ''
|| 6 'Tom Christiansen'
|| 7 '/home/tchrist'
|| 8 '/usr/local/bin/tcsh'
|| 9 0
||
|| Good luck. :-)
There exists at least one user for whom "getpw* can imply getspw*" is
not a significant security risk.
That's a start. Now all that's needed is to get every flavour of OS
to use an adequate password hash, and to get every user to choose a
long enough unguessable password to substitute "There exists at least
one user for whom" with "For all users".
Good luck. :-)
--
John Macdonald jmm@jmm.pickering.elegant.com
Thread Previous
|
Thread Next