pwdauthd pwdauth() - Source Wanted in order to fix security hole.

pwdauthd pwdauth() - Source Wanted in order to fix security hole.

Post by Robert Din » Tue, 16 Nov 1993 12:55:12



     A while back someone scarfed our password file, ran a cracker against it,
and compromised several hundred accounts.  Before we could get that cleaned up
they managed to hack root access and remove our device files.

     So, at that point I went to Sun's idea of C2 security, primarily for the
shadow password feature, only Sun's implementation sucks.

     Seems that anybody in the world can through RPC's access pwdauthd and use
it to "guess" at accounts.  This became apparent when the system slowed to a
crawl and the CPU time pwduathd used went through the roof.  So I blocked that
port in the router.

     The person then obtained a legitimate account and proceeded to run a
cracker that called pwdauth locally.  They put a small delay between calls so
that it didn't totally max out the CPU.  Even so they managed to compromise at
least 30 more accounts and bog the system so bad that legitimate users couldn't
get on.  That individual is tossed off, but who knows how many accounts they
have access to that I don't know about.

     What I want to do is create a pwdauthd and pwdauth system call that will
only work if the effective UID is root, otherwise return a no-match condition
even if the password is correct (so they won't know they're talking to a
modified daemon/system call).

     I don't know a lot about RPC's so I was hoping not to have to invent this
wheel from scratch, ie, I was hoping I could find source that I could modify.

 
 
 

pwdauthd pwdauth() - Source Wanted in order to fix security hole.

Post by William Unr » Wed, 17 Nov 1993 16:58:38



>     A while back someone scarfed our password file, ran a cracker against it,
>and compromised several hundred accounts.  Before we could get that cleaned up
>they managed to hack root access and remove our device files.

What king of passwords to you allow your people to use??? Nobody should
be able to compromise several hundreds of accounts by cracking their
passwords. Put a password checker onto your system (eg npasswd, esp with
cracklib added to it). You could also modify login to check(via
cracklib) whether the passwords of people already on the system are weak
or not when they next sign on.

 
 
 

pwdauthd pwdauth() - Source Wanted in order to fix security hole.

Post by Casper H.S. D » Wed, 17 Nov 1993 17:39:24



>     A while back someone scarfed our password file, ran a cracker against it,
>and compromised several hundred accounts.  Before we could get that cleaned up
>they managed to hack root access and remove our device files.

Yep, keep people of your system is the first step in keeping it secure.

Quote:>     So, at that point I went to Sun's idea of C2 security, primarily for the
>shadow password feature, only Sun's implementation sucks.

What I actually like of Sun's implementation is that it is transparent
to end user programs.

Quote:>     Seems that anybody in the world can through RPC's access pwdauthd and use
>it to "guess" at accounts.  This became apparent when the system slowed to a
>crawl and the CPU time pwduathd used went through the roof.  So I blocked that
>port in the router.

You can't block ``that port'' in the router.  Everytime your system boots
pwdauthd can get a different port.  You should use one of Sun's
patches that disallows remote access to the pwdauthd daemon.

Also, note that with NIS you'll need the pacth that will block access
to ypserv from other machines.  Or any root user on the internet can
still read your password file.

Quote:>     The person then obtained a legitimate account and proceeded to run a
>cracker that called pwdauth locally.  They put a small delay between calls so
>that it didn't totally max out the CPU.  Even so they managed to compromise at
>least 30 more accounts and bog the system so bad that legitimate users couldn't
>get on.  That individual is tossed off, but who knows how many accounts they
>have access to that I don't know about.

If he is able to crack accounts through pwdauthd, then your password
security stinks.  While on a normal Sun you can try up to 3000 different
guesses per second per processors, that number drops dramatically once
someone cracks through pwdauthd.  (10 per second if they're lucky).
With such a low guessing count, it should be impossible to guess
any password in a reasonable amount of time.

Best defense: run crack on the shadow password your self and beat your
cracker to it.  Or install a password program that will disallow
easy passwords.

Quote:>     What I want to do is create a pwdauthd and pwdauth system call that will
>only work if the effective UID is root, otherwise return a no-match condition
>even if the password is correct (so they won't know they're talking to a
>modified daemon/system call).

That will break programs like xlock and such and circumvents the entire idea
of deamon.  (I.e., you can do away with the daemon and code the stuff in the
crypt() library routine).

Casper

 
 
 

1. pwdauth() and rpc.pwdauthd for Solaris?

Ok, I've done my homework, read tons of FAQs, etc.  Here is the dilemma:

Perl, and many other programs that called the C lib function pwdauth()
unders SunOS 4.1.4 now no longer work.  I've determined that 1) rpc.pwdauth
does not come with Solaris 2) pwdauth is no longer a part of the
disintigrated libc equivalent under Solaris, and 3) crypt() no longer
transparently calls pwdauth() or its Solaris equivalent when resolving salts
that begin with '##' or '#$' as under SunOS.  In otherwords, all calls to
crypt() and pwdauth() to check for valid username and passwords now fail.

Better for security, sure.  But, this does NOT make for a smoot transition
from 4.1.4.  I was very dissappointed to discover that Sun doesn't even
offer any suggestions on "lowering" the level of security back "down" such
that these programs remain compatible to any degree at ALL.  Now I'm looking
at recoding a library that replaces pwdauth() with essentially the same
thing as pwdauth() before.  I am considering compiling up rpc.pwdauthd and
the pwdauth() C lib, but even so, I'll have to recompile Perl linking in the
new library and so on, and so on,...

Has anyone encountered similar challenges?  If so, I'd love to hear about
them.  I'd also love to suggest answers to others for FAQs across the net.
I have come up with nothing--even going through alt.2600.

Robert Muhlestein

2. DCOP error reinstalling KDE3.01

3. Security Hole Fix?

4. FAQ: SCO UNIX newsgroups and mailing lists

5. fix for HUGE SECURITY HOLE in syslog?

6. ntfs for linux 2.2.14-5 (Red Hat 6.2)

7. Tools to fix security holes

8. making PDFs with MVware question...

9. Security hole fix

10. runpipe v1.2 with security hole fix

11. X security hole- how to fix?

12. Fix for /bin/login security hole.

13. InfoMagic Mar95 wu.ftpd security hole fix.