[olug] Scripting

Mark A. Martin mmartin at amath.washington.edu
Sat Nov 18 14:20:58 UTC 2000

I'm not at all trying to dis Brian but there are a few security problems
in what he outlined that you should be aware of.  He indicated one of
them in his comments.  I'd like to point them out and suggest ways of
fixing them.

As Brian suggests in his comment, you need to come up with a scheme to
introduce randomness in your passwords.  As he implies, you should not
use the date to do this, as he does in his example.  The date is easily
guessed, which could lead to someone cracking your passwords.  (The
possibility of cracking is greatly magnified because you are generating
so many passswords.)  A better approach is to use the checksum of the
output from rapidly varying system information such as the output of ps,
which a cracker on the outside would not have access to and which a
local user would have trouble capturing at the same moment that you're
using it.  There is an example of this on pp 223-4 of the 2nd edition of
"Programming Perl" in the discussion of the srand function.  (Sorry, I
haven't able to afford the 3rd edition yet.)  The documentation for
srand in the perlfunc section of the HTML version of the perl manual
contains the same discussion.  The perl manual is probably on your
system under /usr/doc.  (The relevant page is located at
/usr/doc/perl-5.00503/manual/pod/perlfunc/srand.html on my system.)

You may want to use one number generated in this way to play the role of
$date_part in Brian's script and another number generated in this way
from a different source of system information as the seed for rand.  As
the documentation for srand says, only set the seed for rand once with
each invocation of the script.  Alternatively, as indicated in the
documentation for srand, probably the best way to insure that you're
introducing randomness is to use the Math::TrulyRandom module available
from CPAN.

Another security problem with Brian's example is that it doesn't set
permissions on the new password file and builds the new file in /tmp,
which is world writable.  Someone with an account on your system who
wanted to gain access to other accounts could possibly

i) get a copy of all or part of the new password file between the times
   the script begins building the file in /tmp and moves it to


ii) replace /tmp/newpasswd with their own version of the passwd file
    the new version is written and before it is moved

depending on the file creation mode mask of the parent shell running the
script.  Either one of these may take a few tries with a script but they
are fairly easily done.  It only takes retrieving a portion of the
password file to compromise your system.  To prevent this, you may want
to set permissions on /tmp/newpasswd so that only the user of the script
can read or write to the file or create the new password file in a
directory that other users on the system cannot access.  If /etc/passwd
is world readable, as it is on most systems, someone could also copy the
password file before it is shadowed.  So, you may want to make sure that
/etc/passwd is not world readable.  (Of course, this could cause
conniptions in other programs on your system that use /etc/passwd, if
there are any.)

I'm not a security expert but I play one on the OLUG list (sometimes and
probably to everyone's peril).  Since you're doing something as
sensitive as creating passwords, be very careful about security issues
when writing your script.

Mark A. Martin					Dept of Applied Mathematics
http://www.amath.washington.edu/~mmartin	University of Washington

To unsubscribe, e-mail: olug-unsubscribe at bstc.net
For additional commands, e-mail: olug-help at bstc.net

More information about the OLUG mailing list