Re: [Gnue-dev] Appserver/Common Issues

[Stanley A. Klein]

Jan -

First, let me say that security includes both authentication and access
control.  The access control consists of providing a "reference monitor"
that checks each instance (or certain instances) of attempted access
against the access rules and either allows or denies it.

Authentication is the peocess of determining that the user is authentic,
i.e., they are who they claim to be.  This is done by receiving information
(one, two, or three factors -- something the user knows, something the user
has, and/or something the user is) and comparing the received information
to a stored version of the information for the authentic user.  The
"something the user knows" is either a password or an encryption key.
(Passwords and encryption keys are really the same kind of thing, with
encryption keys generally being regarded as longer than passwords.)  The
"something the user has" is some kind of device, probably protected by
encrypted information.  The "something the user is" is essentially data
regarding a biometric characteristic of the user, such as a fingerprint or
eyeball pattern, generally stored in some encryption-protected format.

There are a wide variety of means for attacking authentication systems.
You identified the issue of capturing the authentication data, such as by a
sniffer for passwords sent in the clear.

One of the major vulnerabilities in authentication systems is the system
for determining, storing, and managinng the authentication data.  In an
encryption system this is known as the "key management" system.

One attack that we can only protect against by procedural means and
training is the "social engineering" attack.  This consists of tricking a
legitimate user into revealing a password to a malicious intruder.  For
example, the intruder might call on the phone and pose as a repair person,
clsiming that the user must supply a password to allow repairs to be
completed.  There are many approaches used in social engineering attacks,
and they often work with untrained and unsuspecting users.

Another classic kind of attack is password guessing.  The simplest version,
that often works because of poor password selection by users, is to try the
login name as the password.  A similar version is to try the default
password, if there is one.  Many users don't change the password from the
default.  A more complex version applies to  *nix systems where the
password file is visible to users, although the passwords are encrypted.
Generally, the encryption algorithm is a system function and the key is
known, but the encrypted passwords are difficult to break directly.  The
attack is to run various dictionaries (such as the spellcheck dictionary)
through the encryption algorithm and look for matches in the password file.
 This is the reason there are now system administration utilities that
check proposed passwords and reject them if they are found to be ordinary
dictionary words.

There is another potential vulnerability in organizations that have
numerous internal passwords, such as the passwords that might be used for
remote control devices or among the databases in a multi-tier model that
are not directly accessed by users.  That vulnerabilty is an attacker
discovering the pattern, if any, used by the organization in creating and
managing the passwords.  As with complex user passwords assigned by the
organization, if they are too hard to remember, users will write them on
sticky notes attached to the computers.  There are a number of ways an
intruder can attempt to obtain the password information.  If the
organization automates the password management process, that automation
system becomes an object of attack by the intruder.

However, the most serious potential attacks would be those that exploit
programming errors and other vulnerabiilties to bypass the authentication
system and gain access to the platform and database without logging in.
The most frequent kind of attack is based on buffer overflows, but there
may be other attacks that exploit bugs in Python or wxPython, programming
errors in GNUe, peculiar features of the database system, or other
exploitable conditions.  Imagine some kind of bug that allows the attacker
to provide an input that crashes appserver, not as a denial of service
attack, but with the aim of getting to a Python traceback and Python
prompt, or to a system prompt.  Then the attacker can gain a foothold for
further entry.  

Security-relevant operating system code tends to be fairly limited in
scope, very highly scrutinized, and rapidly fixed if there is an
exploitable bug.  That may not be true of security-relevant code in
applications and application infrastructure code that sits above the
operating system.

Let me give one more example.  I have been monitoring the Linux Loadable
Security Module discussion list since it started.  One time there was an
extensive discussion about a design issue that involved a potential
"time-of-check-to-time-of-use" vulnerability.  IIRC, this is a situation in
which a legitimate user attempts to access a file, the access is approved
by the reference monitor, and somehow because of event timing in the system
an unauthorized access is allowed to occur.  There was extensive discussion
of the issue.  I don't remember the outcome.  But a number of top security
experts spent time examining the issue and deciding what to do.  That is
the level of expertise that is being applied to Linux operating system
security and to operating system security in general.  I don't think the
same level of attention is being applied to database or application systems.

That's why I think that GNUe should base as much of its security as
possible on the operating system. 

I certainly agree that physical security is important (special rooms, etc.)
as well as security training for all personnel (so they know not to write
passwords on sticky notes and to become suspicious of anyone who asks for a
password on the phone).


Stan Klein



At 06:43 AM 11/21/2002 -0500, Jan Ischebeck <address@hidden> wrote:

>Stanley,
>
>I'll comment inline :)
>
>Am Donnerstag, 14. November 2002 19:20 schrieb Stanley A. Klein:
><snip>
>> >I. Security:
>> >
>> >Requirements
>> >1. user authentification (not only against a database)
>>
>> Authentication should best come from the operating system based on
>> pass-through functions.  Second best is authentication coming from the
>> database.  Authentication across a network can be done using systems
>> designed for that purpose that work with the operating system.
>
>IHMO the main job of the operating system is to provide a secure
environment, 
>authentification can be done by the operating system, but it doesn't have to.
>The security provided by authentification done just in the operating
system is 
>not necessarily more secure as when authentification is done by something 
>else.
>
>I think authentification consist of two steps:
>
>1. getting authentification information
>2. verify the authentification information
>
>The main security risks for 1. are:
>  a) authentification information is copied ( a keylogger logs the password
>      you've written)
>  b) fake authentification information is read in (use of water in a plastic 
>     bag to trick a finger print scanner)
>
>The main security risk for 2. are:
>  c) the communication is intercepted and a fake "user is authentificated" 
>     message is send back
>   
>  d) the authentification verifier itself gets modified.
>
>
>All steps should made be equaly high secure.
>
>>
>> Note that authentication only provides some confidence that the user is who
>> the user claims to be, or that the message comes from where it purports to
>> come from.  Can it be falsified or defeated?  Of course, if the attacker
>> wants to spend enough time and money.
>
><sssnippp>
>
>> Perhaps I don't understand the new appserver and 3-tier architecture well
>> enough to be able to comment on this.  I don't know what is meant by an
>> "authentication adapter," but refer to my remarks above on authentication.
>> For a while I seemed to get the impression that the new 3-tier appserver
>> interface would look more like the 2-tier interface than the old appserver
>> interface did.  Now, I think my impression may be incorrect.
>
>An authentification adapter in appserver do the second step of user 
>authentification: it verifies some user authentification information against 
>some kind of backend.
>
>>
>> From a security viewpoint, the difficulty with the old appserver (and the
>> reason I think access control may be a major challenge) is that the mapping
>> of data items from the user side of appserver to the database side seems to
>> be complex, implying that appserver has to do some of its own access
>> control.  Unless those access control functions can be pass-throughs from
>> the operating system or can be isolated in files that can be well protected
>> by the operating system, the appserver is likely to be much more vulnerable
>> to attack than the 2-tier approach.
>
>The difference between a 2-tier and a 3-tier approach in terms of security
is, 
>that some of the functions on the local/client side of a 2-tier are moved to 
>a more secure place in the middle.
>
>Appserver, as databases too, should run on a server in a special room, which 
>don't allow physical access to the hardware. It should do check the
integrity 
>of data provided by a client, and allow a more fine grained access 
>restriction system then a database. It could also be used to bind a client
to 
>a fix workflow.  By that it would make the data you have more secure than in 
>a 2-tier approach. 
>