Security traps
Many security experts said NO !!! They urge for restrictive systems as the way to
improve security. Well, Murphy said: "When something can go wrong, it will"
and this is exactly the case here, too.
A system is as secure as the weakest
link in it. And this is usually the person who work on it. If the system is not
flexible and easy to use enough, the users will always find a way to "increase"
the flexibility. And usually this lead to a security disaster !!!
Many corporate systems administrators, force their users to use passwords no less than 8
characters and force the users to change their password every month. They think:
- If the user use 8 characters even if they restrict themselves at uppercase/lowercase and
digits there will be 63^8 = 248155780267521 combinations. Changing password at every
month will require 92650754 password checking per second to be tried. This will not
work so we are safe.
In real life, users get frustrated after 2 or 3 changing so they will select something
very easy to remember and to type. Since the Q letter is the left/upper most letter on the keyboard
they will try qqqqqqqq. This usually not work, since the system require them to use at
least a different case or digit. Next move will be qqqqqqqq1 and it is OK.
Next month will be qqqqqqqq2 and so on. If the system won't allow repeating
the password in less than 12 months after they finish with qqqqqqqq0 the
aaaaaaaa1 will be the next one and so on. In 20 months the first qqqqqqqq1
will come in place. The "legends" say that almost 1/3 from users will do exactly like this.
And hackers know that. So, while
the sysadmin sleep happy believing he solved once for ever the password guessing attack
an malicious user know that there is 1/3 chances that one of the 20 passwords listed
above will work if he try to impersonate somebody else. The vulnerability of the system is
as mater of fact 1/60 and not 1/248155780267521 as the sysadmin believe. Even if we consider
right most letters too: P and R the rate will still be very high 1/120. The reason for this
is the human nature. People will always find out the "minimum resistance way". It is human biology,
the way human brain work, and maybe the reason we are so successfully as specie.
Definitely an sysadmin who frustrate his users is a huge threat to the system security.
In the Linux community many pointed the finger against LindowsOS who let the user work
from root account as his default choice. On the other side, RedHat 8.0 made a big
effort to remove many programs who require root access, moving them under the control of
consolehelper controlled by PAM access. The reason was (i assume) they read that as many
setuid root files you have as much trouble you get. So, if the user asking for kppp to
get on the internet type the root password, this is a legitimate user so he will not try to
pass some parameters to buffer overflow the kppp. Right? Well, not exactly. RH solved a possible problem introducing another one:
The dialog is well known so a virus writer will very easy reproduce it in his code. The user who added kppp icon on his task bar
(RH don't provide it by default) have this settings saved under ~/.kde/share/config/kickerrc.
This file point to ~/.kde/share/applnk-redhat/Kppp.desktop where kppp is specified as the executable.
Well, both these files are(obviously) owned by the current user. User who may receive an virus by e-mail.
This virus will have access to write and replace the Exec line so instead of starting kppp it will start the virus.
So when the user click onto kppp icon the virus will present him with well known root password entry dialog !!!
Guys, having kppp setuid root it is AWAY much safer. At least the virus writer have to
check if the version of kppp and his library is the one having the exploit. If no, it have to be able
to download a new exploit (if known) over the internet. And the systems who use older or newer
version of setuid kppp(than the exploit target) are invulnerable. But with RH approach
any version is vulnerable :-) Is this security? Even an advanced user may be fooled by this procedure.
OK, let's say that the virus writter is not skilled enough to be able to change KDE config files thus fooling more advanced users.
A script kiddie or something similar. But if the target is not a Linux professional but a simple home user,
even if the virus just wait 20 minutes, then ask (completlly uncalled) for root password, chances are the home user will provide it with
what he ask for.Let face the reallity. Into an environment where the users are asked for root password for any operation
that need some extra privileges, they will develop an "Pavlov like reflex" into typing it wherever they are asked for.
So do that, without questioning why this dialog was shown here right now.
Do Security and User Convenience goes hand in hand ?
My oppinion is that it depend on design. If the original system design employed from the begining
the decision to do so, it is possible. In Sys++ design, I will provide many examples where security, system flexibility
and user convenience go hand in hand. As mater of fact, the user convenience and system flexibility come as a "free gift"
resulting from a security oriented design. The core ideea is to keep in mind that security is FOR users and NOT AGAINST them.
About entering passwords
The RH 8 example highlight a big missunderstanding related to security. When and HOW a password
is to be asked for?
Typing a password must be considerated a very important (even official) event. Everybody owning a user
password can impersonate this user in front of the system. Therefore, the user should be very carefully
in providing the password.
Into a system who abuse the user asking again and again for the password the user will start to loose
the importance of the event. They will be very likely to provide it to a virus or Trojan horse,
without questioning why it was asked for the password in this moment. They will even chose the password as
trivial they can force the system to accept(and the human is pretty inventive compared with the computer).
A system asking for the password at every 10 minutes have the chances to be broken more easily
than the one who ask it once per session or by the screen saver.
Not just how often is the password asked is important, but HOW is the password asked.
If the user have 10 programs into the computer and each of them ask him with his own dialog,
the user will be very susceptible to type the password wherever it see a dialog box :-)
Using an unique dialog for password is a big step ahead (and here RH did it the right way).
But is not enough. If the dialog is into a shared library the virus can just call that function.
Even if it is a separate program, if the look is well known it can be imitated (including
curent theme of the system). There is ONLY one right solution: The dialog must be user customizable.
That is. When the user first log on, the system ask him to select the look and feel of the password dialog,
this include a dialog background image (selected from a a set at least of 10..20), selecting a
icon for each button and at least 2 or 3(from a set of at least 20..30) another icon with "decorative" purpose positioned onto the dialog at user defined positions.
What I mean is that every user should have his own dialog who request from him any important information:
= his password when required to confirm a very important and irreversible action(and not for trivial ones:-)
= the GPG passphrase for signing or decrypting his secret e-mails. and so on...
After customization, the system MUST explain to the user that:
THIS IS THE ONLY ONE DIALOG ALLOWED TO ASK HIM FOR PASSWORD OR PASSPHRASE
The user have to acknowledge his understandings about that, and will never provide
the password in any other dialog. More than that, the look and feel of the dialog MUST NOT be kept
into a file readable by the user. That is, this dialog should be a setuid program, with an uid of
his own (without the right of login). Also, the password asking program have to keep his own database
of "trustworthy" programs. That is, only a set of programs allowed at installation time to ask for passowrd
will be allowed to do so. Any other program asking for a password have to be reported to the system administrator
(into a corporate environment) or to the user. The user will also have the ability to ask the password program
to acquire as much information is possible about offender, and check them against a known list of mallware available on the Internet.
If not found, the user may ask to submit a report to the vendor or a support group. The same options may be available for any other
dialog asking for his password.
Advanced Unix programming techniques page
Sys++ Project Home page
Visit M.T.M. Home Page