security of shadowed passwords

security of shadowed passwords

Post by Christopher DeMar » Thu, 05 Mar 1998 04:00:00



After browsing the web and talking to other sys admins it's clear that
using shadowed passwords is definatly a security must. What I am
wondering is exactly how secure is the shadowed password file? Is there
anyway someone who is not root get the file off my computer (so they can
brute force it) or brute force it on my system?

Thanks for any info
Chris

 
 
 

security of shadowed passwords

Post by James Youngma » Fri, 06 Mar 1998 04:00:00


  Christopher> After browsing the web and talking to other sys admins
  Christopher> it's clear that using shadowed passwords is definatly a
  Christopher> security must. What I am wondering is exactly how
  Christopher> secure is the shadowed password file? Is there anyway
  Christopher> someone who is not root get the file off my computer
  Christopher> (so they can brute force it) or brute force it on my
  Christopher> system?

The shadowed password file is owned by root and mode 0600, so if they
*can* read it, you're 90% of the way to a complete and total security
failure anyway.

 
 
 

security of shadowed passwords

Post by Thomas H. Ptac » Fri, 06 Mar 1998 04:00:00



Quote:>The shadowed password file is owned by root and mode 0600, so if they
>*can* read it, you're 90% of the way to a complete and total security
>failure anyway.

Bad assumption. Take core dumps as an example of why.

--
-----------------------------------------------------------------------------
Thomas H. Ptacek                                        Secure Networks, Inc.
-----------------------------------------------------------------------------
http://www.enteract.com/~tqbf                         "mmm... sacrilicious"

 
 
 

security of shadowed passwords

Post by Christopher DeMar » Fri, 06 Mar 1998 04:00:00



> Well that depends on what kind of OS you run and what version... On
> almost every system I have seen there is always a way to get the
> shadowed file...

> phreak_accident

Right now I am concerened about the System V rel 4 run server that was
thrust upon me.
 
 
 

security of shadowed passwords

Post by Phreak Acciden » Sat, 07 Mar 1998 04:00:00



> After browsing the web and talking to other sys admins it's clear that
> using shadowed passwords is definatly a security must. What I am
> wondering is exactly how secure is the shadowed password file? Is there
> anyway someone who is not root get the file off my computer (so they can
> brute force it) or brute force it on my system?

> Thanks for any info
> Chris

Well that depends on what kind of OS you run and what version... On
almost every system I have seen there is always a way to get the
shadowed file...

phreak_accident

 
 
 

security of shadowed passwords

Post by Anders Thul » Sat, 07 Mar 1998 04:00:00




Quote:>wondering is exactly how secure is the shadowed password file? Is there
>anyway someone who is not root get the file off my computer (so they can
>brute force it) or brute force it on my system?

  Probably.

  Some FTP servers can be forced to core dump -- if that dump can be
retrieved, it usually contains parts of the shadow file.

--

Telia ProSoft AB, Teknikringen 6, S-583 30 Linkoping, Sweden

 
 
 

security of shadowed passwords

Post by Tom Hol » Sun, 08 Mar 1998 04:00:00




)Thulin) wrote in comp.security.unix

)


)>>wondering is exactly how secure is the shadowed password file? Is there
)>>anyway someone who is not root get the file off my computer (so they can
)>>brute force it) or brute force it on my system?
)>
)>  Probably.
)>
)>  Some FTP servers can be forced to core dump -- if that dump can be
)>retrieved, it usually contains parts of the shadow file.
)
)An ftpd should *never* have access to the shadow password file (in
)order to be able to access the shadow password file, it would have to
)be run suid-root) - btw, is anyone aware of any ftpds which actually
)access /etc/shadow?

All of them.  Don't you ever use ftp from your account?  It's not setuid,
it gets root privileges from inetd.
 -Tom

 
 
 

security of shadowed passwords

Post by Julie Hau » Wed, 11 Mar 1998 04:00:00





>>The shadowed password file is owned by root and mode 0600, so if they
>>*can* read it, you're 90% of the way to a complete and total security
>>failure anyway.

>Bad assumption. Take core dumps as an example of why.

Take a poorly implemented Unix system as an example of how.

The OS should =never= core dump a set-UID root program and should never
dump core for any executable with other than 0600 mode.  Even if it isn't
the /etc/shadow file, dumping core with world readable permissions has
the potential to grant read access to unauthorized users.  Take core dumps
of a word processor with your boss typing up a letter firing you as an
example of why ;-)
--
Julianne Frances Haugh                  
RS/6000 Security Development, C2 Tech Lead        "Resistance is futile!
Bldg 905/2F002, 512-823-8817 (Tie 793)                You will be evaluated!"

 
 
 

security of shadowed passwords

Post by Julie Hau » Wed, 11 Mar 1998 04:00:00




>An ftpd should *never* have access to the shadow password file (in
>order to be able to access the shadow password file, it would have to
>be run suid-root) - btw, is anyone aware of any ftpds which actually
>access /etc/shadow?

They all should -- it's needed so that a user can be authenticated to
the server.
--
Julianne Frances Haugh                  
RS/6000 Security Development, C2 Tech Lead        "Resistance is futile!
Bldg 905/2F002, 512-823-8817 (Tie 793)                You will be evaluated!"

 
 
 

security of shadowed passwords

Post by Thomas H. Ptac » Wed, 11 Mar 1998 04:00:00



Quote:>>Bad assumption. Take core dumps as an example of why.

>Take a poorly implemented Unix system as an example of how.

It was an example, not a taxonomy of all possible problems. Core dumps
are not the only problem that exists with shadowed password files.

Quote:>The OS should =never= core dump a set-UID root program and should never

I think "never" is too strong a word. People do debug programs
occasionally. Also, where is the determination of "this was a setuid
program" made? Is a program still "setuid" after it has discarded
privileges?

Quote:>dump core for any executable with other than 0600 mode.  Even if it isn't

Which doesn't mean much, since most SUID programs will drop creds early
on.

--
-----------------------------------------------------------------------------
Thomas H. Ptacek                                        Secure Networks, Inc.
-----------------------------------------------------------------------------
http://www.enteract.com/~tqbf                         "mmm... sacrilicious"

 
 
 

security of shadowed passwords

Post by Julie Haug » Wed, 11 Mar 1998 04:00:00




> >>Bad assumption. Take core dumps as an example of why.

> >Take a poorly implemented Unix system as an example of how.

> It was an example, not a taxonomy of all possible problems. Core dumps
> are not the only problem that exists with shadowed password files.

I'm not aware of too many others, beyond bugs in the various
implementations.

Quote:> >The OS should =never= core dump a set-UID root program and should never

> I think "never" is too strong a word. People do debug programs
> occasionally. Also, where is the determination of "this was a setuid
> program" made? Is a program still "setuid" after it has discarded
> privileges?

Oh, I definitely understand.  I'm more than familiar with the
problems of trying to debug a set-UID root program.  But since
the system cannot know what a program has done with its set-UID
status, it should treat =any= program which was ever set-UID
as "un-core-dump-able".

Quote:> >dump core for any executable with other than 0600 mode.  Even if it isn't

> Which doesn't mean much, since most SUID programs will drop creds early
> on.

And you've made my point above exactly.
--
Julianne Frances Haugh             Life is either a daring adventure
Mail: jfh AT bga.com                   or nothing at all.
                                            -- Helen Keller
 
 
 

security of shadowed passwords

Post by Tim Newsh » Thu, 12 Mar 1998 04:00:00


: >Bad assumption. Take core dumps as an example of why.
: Take a poorly implemented Unix system as an example of how.

Exactly.  As long as the system has bugs, you can't depend on
the shadow password file being private.  In other words  -- don't
DEPEND on the shadow password being private.  If you do, you WILL
get burned.

: Julianne Frances Haugh                  

                                         Tim N.

 
 
 

security of shadowed passwords

Post by Julie Hau » Thu, 12 Mar 1998 04:00:00




>: >Bad assumption. Take core dumps as an example of why.
>: Take a poorly implemented Unix system as an example of how.

>Exactly.  As long as the system has bugs, you can't depend on
>the shadow password file being private.  In other words  -- don't
>DEPEND on the shadow password being private.  If you do, you WILL
>get burned.

I tend to think you are grossly exagerating the risks.  Yes, systems
=do= have bugs.

Now, do you view that as saying "Shadow passwords don't provide real
protection, therefore let's not use password shadowing at all" and
risk having your system hacked in a day or two?  Or do you take the
position that password shadowing relies on overall system security
the same as every other aspect of a secure system?
--
Julianne Frances Haugh                  
RS/6000 Security Development, C2 Tech Lead        "Resistance is futile!
Bldg 905/2F002, 512-823-8817 (Tie 793)                You will be evaluated!"

 
 
 

security of shadowed passwords

Post by Thomas H. Ptac » Thu, 12 Mar 1998 04:00:00



Quote:>Now, do you view that as saying "Shadow passwords don't provide real
>protection, therefore let's not use password shadowing at all" and

I haven't seen anyone suggest that we get rid of shadowed passwords. I
could be wrong, but it seems obvious that there's nothing to be lost by
keeping crypted user passwords secret.

However, at the same time, it seems to me like there's nothing to be lost
by assuming shadowed passwords don't work. In many operating system
releases, they don't. Why not choose and change passwords with the
assumption that shadowing will fail? It's almost certainly a good
assumption, if we learn anything from history.

Quote:>Or do you take the
>position that password shadowing relies on overall system security
>the same as every other aspect of a secure system?

What a funny thing to say. No, of course shadowed passwords don't rely on
overall system security "the same as every other aspect of a secure
system". That's like saying "any enhanced privilege is equivalent to
root". To hell with least privilege, then! =)

Shadowed passwords rely on the security of the Unix filesystem (which is
what you're thinking of), the security of the process control mechanisms,
and the security of every userland process that at any point has enough
privilege to pull in crypted passwords. Probably more, but...

Small bugs in any of the above that aren't enough to give an attacker root
access (the ability to cause a once-privileged program to dump a readable
core, for instance) can be used to compromise the shadowed password system
without compromising root.

I perceive that you are taking the stance that "anything that compromises
the shadowed password system compromises root". Is this the case?

--
-----------------------------------------------------------------------------
Thomas H. Ptacek                                        Secure Networks, Inc.
-----------------------------------------------------------------------------
http://www.enteract.com/~tqbf                         "mmm... sacrilicious"

 
 
 

security of shadowed passwords

Post by Julie Haug » Fri, 13 Mar 1998 04:00:00




> >Now, do you view that as saying "Shadow passwords don't provide real
> >protection, therefore let's not use password shadowing at all" and

> I haven't seen anyone suggest that we get rid of shadowed passwords. I
> could be wrong, but it seems obvious that there's nothing to be lost by
> keeping crypted user passwords secret.

Good.

Quote:> However, at the same time, it seems to me like there's nothing to be lost
> by assuming shadowed passwords don't work. In many operating system
> releases, they don't. Why not choose and change passwords with the
> assumption that shadowing will fail? It's almost certainly a good
> assumption, if we learn anything from history.

And all of the implmentations of password shadowing I have direct
experience with (the Shadow Password Suite as the author and AIX
for the RS/6000 as a developer) =do= include password strength
mechanisms.

Quote:> >Or do you take the
> >position that password shadowing relies on overall system security
> >the same as every other aspect of a secure system?

> What a funny thing to say. No, of course shadowed passwords don't rely on
> overall system security "the same as every other aspect of a secure
> system". That's like saying "any enhanced privilege is equivalent to
> root". To hell with least privilege, then! =)

No, pretty much they do.  Even in least privilege systems (AIX has
"least privilege" as its underlying implementation, as does VAX/VMS
and many others) there are a small number of "golden key" privileges.

In AIX if you can get SET_PROC_DAC you can read or write any file
on the system.  From that point you can get root in one or two
steps.

The advantage of least privilege isn't that you can't figure out
ways to amplify one or two stolen privileges into =more= privileges
(generally there is some way to acquire more privileges once you've
figured out how to get one ...), rather that it is harder to get all
of the privileges (or the ones you happen to want) in such a system
than it is on a monolithic privileged system.

"Least privilege" challenges the attacker to figure out how to
use =that= privilege to exploit further flaws to get new privileges
or to use =that= privilege to do something specifically damaging.
It's like saying "Now that you have <X> privilege, what are you
going to do with it?".  If the answer is "I don't know.", least
privilege has prevented a further penetration.  If the answer is
"I'm going to take my FS_CONFIG privilege and put a filesystem on
a floppy disk and have a set-UID root shell and mount it and then
I'll run it and be root", least privilege has failed.  But at least
the attacker had to do some work (and have access to the floppy
drive).

Quote:> Shadowed passwords rely on the security of the Unix filesystem (which is
> what you're thinking of), the security of the process control mechanisms,
> and the security of every userland process that at any point has enough
> privilege to pull in crypted passwords. Probably more, but...

So far so good.

Quote:> Small bugs in any of the above that aren't enough to give an attacker root
> access (the ability to cause a once-privileged program to dump a readable
> core, for instance) can be used to compromise the shadowed password system
> without compromising root.

Just as small defects in other parts of the system (say the
ability of a networked user to get sendmail to execute an arbitrary
program) may not directly compromise root.

Quote:> I perceive that you are taking the stance that "anything that compromises
> the shadowed password system compromises root". Is this the case?

Directly compromise root?  No.  But I believe that small compromises
of system security can usually be parlayed into larger compromises.

I worked a defect in AIX a few years back where you could compromise
the queueing subsystem and within a few steps have a root compromise.
If you look at each compromise in isolation minor defects may not
look significant.  But taken as cumulative actions a minor defect
in ftpd which doesn't allow execution as root might give access to
a user's account who =can= su to root and from there root is
compromisable.

Secure systems critically rely on all of the other parts of secure
systems.  That was the point behind my mentioning ptrace() and
mknod() in our discussion of chroot().
--
Julianne Frances Haugh             Life is either a daring adventure
Mail: jfh AT bga.com                   or nothing at all.
                                            -- Helen Keller