*sigh* Re: Security issues in publishing content of /etc ?

[Evaldo Gardenali <evaldo () gardenali biz>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fabio Miranda Hamburger wrote:
|>>You could use a brute force attack to get weak passwords. You may find
|>>software installed in the machine or other hosts information.
|>
|>Brute force means trying every possibilities?  Using a dictionnary
most possibly, what if
|>the password
|>have a scrict policy, like no more than 3 same kind of characters in a
suite and must
|>contain lower-
|>case, upper-case, numbers and punctuation.  This would definately slow
down the brute
|>force I guess.
|
|
| It is a matter of probability. You can try thousand of passwords in a
| week.  A strict policy helps alot though.
|

If the cracker knows the policy, he can create words to try based on
your policy

|
|>>Too few changes you get a readable shadow password file nowadays. You
cant
|>>do password cracking with /etc/passwd. The host IP or 'dns ip' is public
|>>avalible and It is not a risk by itself.
|>
|>There was a program called `crack` which I think would just encrypt
words in a dictionnary
|>using the
|>same hashing algorythm as the one seen in /etc/passwd and compare its
results with the
|>ones in that
|>file.  Isn't how it works?
|
|
| Shadow passwords are stored in /etc/shadow or /etc/master.passwd
|

Do people remember theres salt? :) you must encrypt all words again for
each salt value :)

|
|>>You can chroot a filesystem to prevent users to view systems files. A
|>>server can do the sharing and other just authenticate users.
|>
|>For a linux system, but here I'm thinking on devellopping a software
that will mimic the
|>inner working
|>of linux (in a very light way), and all files will be stored on every
computer who uses
|>the software
|>(containing the big /etc/passwd of all users).  Therefore, all files
are on the system,
|>with the user's
|>privilieges when he installed it.  A malicious user will be able to
read that sort of
|>/etc/passwd.
|
|
| The software you prented to do, should implement a level of security thus
| a user, with your mimic software installed on his machine, wont be able to
| access system information. I dont understand what kind of software you
| have in mind but a good idea would be to have a server and store all
| information in one point.
|
| It is risky to have account information store in client side. If you will
| implement virtual machines, the user can boot his OS and mount you mimic
| software.
|
| A user can find out the way you implement your virtual disk and code a
| data structure that reads info.
|
| If you dont monitor log information on each client, a user can code a
| brute force attack which could be very successful.
|
| If your mimic software share network resources with the client machine, a
| user may be able to install fake server or a sniffer from the host
| machine.
|

HELLO? do people remember there are ssh host keys on /etc? what about
cleartext PPP passwords? what about UUCP passwords? what about other
sensitive data?

showing /etc is BAD, as showing any user's full homedir is bad as well
remember there are ssh keys, x509 keys, gpg keys, passwords, cookies,
sensitive files, cleartext files with sensitive stuff, enough of user
details, privacy-related stuff, blah blah blah

my suggestion: back to the drawing board :)
Cya
Evaldo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBGUiR5121Y+8pAbIRAhpTAJ9a0DL7EVTLgtnRNFomixoMETXvsgCfTIkW
U0BlsoS8+MxQvEhwDa/ZAGI=
=Y4jB
-----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature