previous  next  Title  Contents  Index                Last Update: 25 juin 2002

13. Securing Applications

Internet/Intranet

Introduction

Internet applications are those based on common Internet application level protocols such as HTTP, wais, gopher, telnet and ftp.

Security has traditionally been weak on the Internet, but that is changing. The Security market offers a wide choice of products that are evolving rapidly.
This section does not cover all aspects of Internet/Intranet security. A quick browse of the Mechanisms, Firewalls and possibly UNIX/NT chapters is recommended before reading here.

How can the risks be reduced?

The security issues can be discussed in two broad categories, client side and server side security. 

Client side security & browsers

Downloading from the Internet

Great care should be taken when downloading files from the Internet, to avoid downloading Trojan horses, sabotaged documents or programs and viruses:

Java

Sun Microsystems' Java has made a big impact since it's debut in late 1995. Java is a C/C++ like language which has multithreading, object orientation, networking and portability since is compiled into byte code. This byte code can be executed (interpreted) by any host that has a virtual Java machine. This ensures high portability but at the cost of performance (since interpreters are slow - but this should change as Java implementations in silicon and Just In Time - JIT compilers come into mainstream use).

Java is designed to run in two situations: standalone applications and "applets". Applets are small Java applications downloaded from a Web page to a browser and executed by the browser.

Java is resulting in spectacular WWW home pages and highly portable applications (although Microsoft is doing it's best to stop portability). It is considered by some to be the future trend for client / server computing.
Java V1.02 is supported by Navigator V2 (and later), IE3 and newer versions of Mosaic and PowerBrowser. V1.1 works on IE4, Navigator 4.04 with the Jan.1998 JVM fix or 4.05 or later.

Java has been designed to provide a secure an environment for foreign code execution:

Java applets have the following additional restrictions:

Certain threats are not addresses by the Java design:

The above is the theoretical standpoint. As Java comes into mainstream use, problems are appearing.

We conclude that Java in it's current form cannot easily be made secure. Significant redesign of the language, the bytecode format, and the runtime system appear to be necessary steps toward building a higher-assurance system.. Without a formal basis, statements about a systems security cannot be definitive.

The presence of flaws in Java does not imply that competing systems are more secure. We conjecture that if the same level of scrutiny had been applied to competing systems, the results would have been similar. Execution of remotely-loaded code is a relatively new phenomenon and more work is required to make it safe.

Now (July 2000, 4 years later) few other security issues have arisen (compared with Browser security bugs for example) and as JDK 1.1 is supported by most browsers, signed applets should start making their debut.

Conclusions:

Javascript

Javascript has nothing to do with Java, apart from a similar syntax. It is a client-side interpreted scripting language designed by Netscape.
It does not operate in a sandbox (as for example Java does), it can upload files, send mail, present dialog boxes with anything written on them and write to local files (albeit via a dialog box). Javascript has two security policies:

  1. The same origin policy is the default policy. It dates from Navigator 2.0. When loading a document from one origin, a script loaded from a different origin cannot get or set properties of the following in a window or frame. objects (image, layer, location, window, document).
  2. The signed script policy is new to Communicator 4.0, is based upon the new Java security model,  object signing. To make use of the new policy in JavaScript, use the new Java security classes and then sign your JavaScript scripts.

Security bugs pop up constantly, upgrade your browser to the newest version  every few months.

Note: JavaScript can do anything if delivered in a html file attached to email i.e. no dialog box prompt , it already has the rights as the user started it! e.g. it can email your file system from your PC .

Recommendations

Hot Java

Hot Java is a demonstration WWW browser from Sun Microsystems, built to show what the Java language can do. Since Hot Java is not supported and is purely for demonstration, it should not be used by normal users, especially since earlier versions contained several security holes (see [java1]). 

ActiveX in Browsers

ActiveX was designed allow PCs to execute programs from a web page. There is no security policy or concept, except that the originator of programs can be verified. ActiveX programs downloaded via a web browser can do what they want with your PC, i.e. format the hard disk, shut it down etc (see www.halcyon.com/mclain/ActiveX for some examples).

Netscape Navigator

Netscape is the principal WWW browser and interface to the Internet for most users, especially since it run across a wide variety of platforms from PCs to UNIX.

Microsoft Internet Explorer

Explorer 3.0 supports Java, SSL 2 & 3, software signing, PCT 1.0, Active X and ActiveXscript/VBScript.

Problems:

Executing Code on IE 4.0 and 4.01 (Jan.13'98)
Cracking Windows 95 Share
Passwords (Jan.9'98)
Teardrop 2 Attack (Jan.9'98)
IE Page redirect (Nov.19'97)
land Attack (Nov.17'97)
IE4 (Oct.11'97)
IE4 & DHTML (Oct.16'97)
IE4 & Java (Sep.12'97)
OOB Attack (May.9'97)
IE & Powerpoint (May.7'97)
Samba Can Grab Win95 Passwords (Mar.17 '97)
IE Hole with NTLM (Mar.15 '97)
IE & Netscape Hole Found (Mar.14 '97)
Run Local Commands With IE (Mar.7 '97)
Get IE To Launch Remote Apps (Mar.6 '97)
IE .LNK and .URL Problems (Mar.3 '97)
Potential Active Server Problem (Feb.20 '97)

Since Microsoft believes in security through obscurity (they don't publish algorithms, subject their programs to peer review or always inform users of security weaknesses), Explorer can't offer a high level of assurance. Since it is free and will be increasing integrated into the Microsoft Operating systems, it will be used by more and more users.

Servers: WWW (World Wide Web)

Reference Documentation

  1. Before installing a WWW server, read the following FAQ, which goes into considerable detail on server setup and writing cgi scripts www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html and www.cerf.net/~paulp/cgi-security or hoohoo.ncsa.uiuc.edu/cgi/security.html .
  2. HTML books: "Webmaster in a Nutshell" (O'Reilly), "Teach Yourself Web Publishing with HTML in 14 Days", ISBN 1-57521-014-2 another is "How to set up and maintain a World Wide Web Site: The Guide for Information Providers", Lincoln Stein (Addison-Wesley), ISBN 0-201-63389-2.
  3. An email list is devoted to WWW security:
    www-security-request@nsmx.rutgers.edu
    body= SUBSCRIBE www-security YOUR_ADDR

For information on secure versions of html, and transaction processing on the web:

http://home.netscape.com/info/SSL.html
http://www.commerce.net/information/standards/drafts/shttp.txt
http://www.w3.org/hypertext/WWW/Shen/ref/security_spec.html
http://www.w3c.org
http://www.fv.com
http://www.digicash.nl
http://www.cybercash.com
http://www.mcom.com
http://www.algroup.co.uk/Apache-SSL

For information on basic authentication, see:

http://www.w3.org/hypertext/WWW/AccessAuthorization/Basic.html

For server status codes see:

http://www.w3.org/hypertext/WWW/Protocols/HTTP/HTRESP.html
See also the Internet references in Appendix C.

Overview

The WWW scene is moving very fast and is increasingly complex with many vendor extensions, protocols, different client front ends etc. This section presents a very brief overview of a complex topic. Basically to provide a secure WWW service you need:

General

The HTTP protocol is stateless, the connections being initiated by the client and terminated by the server after sending a response. The HTTP/1.0 request provides for a from field that specifies the users email address, a referrer that specifies the resource from which the URI was obtained (i.e. your machine and domain) and a user-agent that specifies which browser is in use. Each of these fields is only passed supplied by the browser client if it is so configured.

Fail //*
Fail *//*
Fail /./*
Fail */./*

Authentication

Most servers allow password restricted access to certain files via a global configuration (access.conf) or per directory configuration file (e.g. .htaccess, .nsconfig). This is known as Basic Authentication. Access control based on IP address / host name is also available on most servers. Neither of these is foolproof (e.g. basic auth uses base64 encoding of username & password, that is trivial to invert, so it's just as bad a clear text password).
See access.conf (Apache/NCSA) or .nsconfig (Netscape).

Access Control

User-agent: *
Disallow: /

Privacy issues / cookies

Cookies were invented to maintain (user) state information for servers, as described above. The server cookie contains an item of information together with a valid domain name, lifetime, version and a flag indicating whether it should be transferred securely (i.e. via HTTP/SSL). The client cookie contains an item of information together with a valid domain name, version and path. Clients are supposed to be able to store a total of 300 cookies (20 cookies/server), with 4KB per cookie and 1.2MB of data.
Possible problems:

If you are worried about cookies, Navigator & Explorer may be configured to produce an alert if a server sends a request to set a cookie. In reality this is difficult to use since many sites make extensive use of cookies. Another alternative is to install a tool tomanage cookies.

Availability

If possible use a dedicated machine for WWW, to limit damage if the server is compromised.

Redundancy

By using identical WWW servers with separate IP addresses, but mapped to the same DNS domain, a redundant WWW service can be offered. The problem is then automatically synchronising documents across multiple servers. SSH and rdist can be used to achieve this. 

Internet Money

This brief section is included for the curious. One of the difficult hurdles to Internet Commerce is how to securely order and pay for goods/services.
The classical method is with SSL to encrypt the online ordering session and using credit cards for payment. However, new payment systems are evolving, for example:

Email

Many different (often incompatible) products are in use on many different platforms: MS-Mail, Teamlinks, VMSmail, X.400, Mail Exchanger, Internet (UNIX) mail and IBM Host mail for example. X.400 is often the backbone protocol within a large enterprise, with gateways to proprietary protocols. Lotus notes is probably the most common system today, but the author has no experience with it (so it's not mentioned here).

X.500 is a standardised directory service and it is finding acceptance, but slowly.  It's Internet directory implementation, LDAP is becoming commonplace.

Secure email

A unified secure mail system for the company should be considered as a an important issue, however few secure products exist outside the U.S. and even fewer inter-operate.
There is no common method for exchange of secure mail, yet. S/MIME (see below) does offer some hope for the future. The ideal secure email system might have the following properties:

The author knows of no system that satisfies all of the above issues. Other things to keep in mind on evaluating email systems are:

Some multi-platform products exist, which offer secure transmission and digital signatures.

PGP

PGP is a freeware and commercial email and file encryption utility. It is also discussed in the chapter "Security Mechanisms". 

PEM

PEM (Privacy Enhanced Mail) is a secure email standard proposed, but not yet adopted by the Internet Activities Board. PEM includes authentication and key management, using both public and shared key cryptosystems (the user chooses what cryptography is to be used).

S/MIME (May'98)

Secure MIME is the new (proposed) Internet standard for secure email exchange, developed by RSA. It is not yet an official standard, but several vendors (including Netscape) already support S/MIME. It is probably the best long term solution, since it is an open Internet standard.

Typically is not necessary to make any modifications for S/MIME on the server. For instance with MS Exchange, it integrates into the exchange client via the MAPI interface.

Some products are:

Open Soft (www.opensoft.com 1997) costs about $32/user, works with exchange and includes a keyserver. U.S. export restricted. Apparently works well with exchange.

Deming (www.deming.com) also offer an exchange compatible system for about $90/user. U.S. export restricted.

Advantages:

  1. It functions with both Eudora Pro 3.0 and Exchange (and can use the same certificates on the same machine).
  2. No changes are required to the exchange server.
  3. Certificates may either be self signed, or signed by a TTP such as (the default) VeriSign. It could be integrated with the Telecom TTP in the future.

Disadvantages:

  1. The user interface is not perfect, e.g. a user could easily unintentionally send an unencrypted email. The icons used to represent email don't seem to indicate if the received email was successfully decrypted and the signature checked. It is possible that these problems can be overcome by adding additional buttons to the toolbar, though this increases support costs.
  2. When a signed message is received from someone for whom no certificate currently exists, the certificate is automatically added to the certificate database. Before this certificate can be used, it must be manually trusted. This procedure is a bit confusing for normal users, it should be handled by a nice pop-up box when the signed email is received.
  3. The format of the certificates seems to be PKCS (.p7c) instead of plain X.509 (.crt). 

MailSecure:

MailSecure from Baltimore Technologies (http://www.baltimore.ie), is one of the few S/MIME Exchange plug-ins with military strength encryption. Baltimore have been active in cryptology for 20 years and provide references which inspire confidence in their ability to securely implement encryption algorithms. They have only recently ventured into the commercial market, with encryption products for Secure Web transactions, Java, Exchange and Windows.

Advantages:

  1. Strong encryption: symmetric key: DES, 3DES and RC2 40-128bit and public key 512-2048 bit. SHA-1 and MD5 signing algorithms are used.
  2. Fully integrated into Exchange (tested with both Exchange and POP3 servers).
  3. The passphase can be asked for:
    • each time or
    • at startup (and can also be deleted from memory after a specified period of time after startup).
  4. The S/MIME toolkit can be sold separately to developers, if desired.
  5. V1.1.2 tested with Exchange 4. Outlook should also work, but not yet tested.

Disadvantages (major issues are in bold font):

  1. Exchange 5 has problems with MailSecure.
  2. Messages are not compressed, in fact message size can almost double when encrypted.
  3. The restrictions on the password used to protect the certificates cannot be customised. The default setting may be two restrictive or too loose, depending on your needs. It should be the same as password restrictions on other systems you log into.
  4. Development seems slow: it has taken 6 months to leave beta to a stable product. No new features have been added in the last 9 months.
  5. It is not possible to automatically forward emails to an encrypted destination using the Inbox assistant (since the passphrase has to be entered each time)
  6. Intermittent Bug noted once or twice: The MailSecure properties in the compose window (File->Properties) hides the Exchange message properties, so that the message properties (such as priority, importance, whether a copy should be save to "Send Items") cannot be changed.
  7. Intermittent Bug: When a new email is composed, if you try to print it, it asks whether you wish to encrypt it! Make no sense.
  8. Bug: When writing an mail, I was interrupted and had to go out my office, I saved the mail activating both options sign, encrypt. The saved mail is not readable anymore (encrypted text as smime-attachment). (Presumably it encrypts the message with the receivers public key, rendering it unreadable to the original sender?). Workaround: don't encrypt emails temporarily stored, but not ready for sending.
  9. User interface features that would be useful:
    • Better certificate management:
      • It should be possible to delete certificates.
      • It should be possible to have several personal certificates and choose which certificate is used for signing.
      • Certificate cannot be imported/exported except during installation.
      • Only self signed and Baltimore signed certificates are supported at the moment.
      • It should be possible to assign several email addresses to one certificate, since a user might have several Email addresses (e.g. Internet, X.400, Exchange..).
    • Passphrase option that would ask for the passphrase and keep it in memory for a specified period of time (not just at startup).
    • If message sensitivity (see Message properties) is set to confidential, then it should be automatically encrypted.
    • Certificate directory service: When creating a new message, there should be some way of associating users from the address book with available certificate, aside from identical email addresses. Email addresses change all the time and aliases may also be used. A new certificate needed for each email address change. Apparently, the new V1.2 supports X.500 directories.
    • It would also be nice to "mark" certain users in the address as requiring encrypted email and as an option in addition the "sign/encrypt" prompt could be set only to come when email is sent to these users
    • Eudora, Lotus Mail are not supported, but may be in the future.

Recommendations:

HKEY_CURRENT_USER/SOFTWARE/Baltimore-Technologies/BMail/RAEmail

to the email address of the UniMS Certificate request processor.

Email servers & systems

Microsoft Exchange V4

Exchange is an Email based groupware product from Microsoft, with a server software that works on NT 3.51 or later. It integrates MS-Mail, X.400, Internet mail (SMTP) as standard and has add-on modules for Novell, cc:Mail and IBM PROFS systems. X.500 directory services are not yet fully supported, but a proprietary directory service is included. Windows 95 and NT4 is delivered with an exchange client that allows rich text formatting, group scheduling, assigning message priorities and working offline or online.

From the security standpoint Exchange V4 offers:

  1. Secure data exchange:
  2. Verification/non-repudiation: A user can ask for confirmation that an email has been received and/or read by the recipient. If the recipient has advanced security (i.e. with digital signatures), then the user can be reasonably sure that the correct recipient has actually read the information.
  3. Key management:
  4. Identification & authentication:
  5. Access Control:
  6. Auditing/Logging: Events are logged to the NT Security log. Auditing of changes to directory objects and services can be enabled. Automated alerts and monitors.
  7. Availability:

Problems:

Future features promised in Exchange 5.0:

Recommendations:

MS-Mail

Microsoft mail is a collection of modules:
1. Client (MS-mail on Windows).
2. Mailbox server (called a PostOffice).
3. Mail address directory server.
4. Mail delivery process (External).
5. Gateway to X.400 backbone.

Open Issues

UNIX mail (SMTP, MIME, sendmail, MMDF)

The modules involved are
1. Client mail program (allows user to read/send mail), e.g. Mailtool, CDE dtmail, mailx, Zmail, /bin/mail...
2. Local delivery program, e.g. sendmail.
3. Local receiver program, e.g. sendmail, popper
4. Mailbox server, e.g. NFS server.
5. Domain gateway (forwards mail to/from local domain to other domains).
6. Internet Gateway (firewall to Internet).
7. X.400 Gateway (or other enterprise backbone protocol). 

Sendmail

Sendmail is a complex and historically, very buggy program. See the list of CERT advisories in the Appendix for examples of sendmail problems. Most Vendors have slightly modified sendmail, but few use the latest V8 sendmail, which has even more features but is supposed to be more secure[4].

==> Don't use sendmail for transmission of confidential email, unless used together with a tool such as PGP.

MMDF (Multi-channel Memo Distribution Facility)

Here is an extract from some of the MMDF documentation:

MMDF is a mail transport system that supports a variety of user interfaces and delivery mechanisms. The design was not encumbered with the need to be compatible with existing mail systems, and as a result MMDF has a unified family of mail handling programs.
MMDF's design allows it to grow from a single-host system to a large mail relay without degradation of mail system performance, and to degrade gracefully as the load becomes huge. The demands of a high volume mail relay have led to many of MMDF's innovative design choices.
Unlike some other systems, MMDF has separate processes for mail submission and delivery. Recent changes to the delivery software to permit intelligent retry strategies based on the retry history for each dead host will be explained. The effect of the new domain server mechanism on address validation will be discussed.
The separation of mail into channels is key to MMDF's ability to handle large amounts of mail. Each channel represents a different class of delivery and each channel has its own queue. This isolates problems and allows one to provide different ´´levels of service'' to different channels.

The MMDF system was originally developed at the University of Delaware and has since seen significant development work at the Ballistic Research Laboratory and University College London.

The MMDFII software is available under license, free of charge (with the possible exception of a tape copy fee), for internal use only as follows: to U.S. Government agencies through the Ballistic Research Labs, to CSNET sites through the CSNET Coordination and Information Center at BBN, and to others through Prof. David Farber at the University of Delaware, Electrical Engineering and Computer Science Department. Commercial concerns interested
in MMDF for other than internal use should contact Prof. Farber.

It doesn't seem to have advanced since 1994, the current version is V2.4.3 and is called MMDFIIb. See also http://www.cs.okstate.edu/~vasoll/mmdf 

Office Automation 

MS-Office (Winword/ Excel/ PowerPoint)

Microsoft® Word is a target of a prank macro which distributes itself through documents created in Word 6.0 for Windows® 3.1, Word 6.0.1 for the Macintosh®, Word 6.0 for Windows NT(TM) and Word for Windows 95. The prank macro does not affect earlier versions of Word for Windows or Word for the Macintosh. After you open a document containing the macro, documents you save will contain copies of the macro. Once installed, the macro only lets you save documents as templates. The macro does not otherwise affect the contents of the document.

WordPerfect

WordPerfect is not as susceptible to macro viral attacks as Winword, since macros are stored in a separate file and not the document file. 

Windows Help Files

Windows help files can call DLLs. Therefore do not open help files from untrusted sources. If they must be viewed, then do so as an unprivileged user. 

Postscript

Postscript has become the standard language for printing documents, originating in the Macintosh world. However, Postscript is an interpreted language which can (from level 2.0 onwards) allow direct access to the filesystem, meaning postscripts files can be used to read or write other files!

Ghostscript

Ghostscript is a public domain postscript interpreter developed by the Free Software Foundation (GNU). Ghostview is a postscript file viewer which uses the Ghostscript interpreter engine. Ghostscript can be started with the option -dSAFER to disallow file writing, from version 3.22 beta. The Aladdin version has this fix, however the GNU version does not (yet, Sep.1995). Since Ghostscript can be called from a variety of front ends, it is not always possible to change the command line. So:

% SAFER not { ( %END SAFER) .skipeof } if
......
% %END SAFER 

Host Emulators (vt100, vtxx0, 3270)

Passwords can be programmed as keyboard macros into certain emulators. If this feature is used, the emulator initialisation file (where the macro is written) should not be readable by other users. This is especially a problem when home directories are located on a server. 

Teemtalk

Teemtalk provides 3270 (for IBM mainframe access) and VT340 (for VAX access) emulation to allow direct use of a variety of Host applications. Both emulations include a facility for file transfer. Teemtalk uses "Winsock" communications protocol, passing via a 3174 gateway for 3270 emulation and accessing VMS systems directly via sockets.

Emulators are needed for access to host based data. From a security standpoint this means that:

  1. Users must enter username and passwords to access mainframe Hosts. These passwords traverse the network in clear text due to the use of the Telnet protocol (degrades host security).
  2. No trust is required between the Hosts and PCs (improves Host security).
  3. Since users have multiple accounts and passwords, they may use the same password everywhere, write it down or use easy to guess passwords (degrades security).

Login names/passwords which traverse the network unencrypted could be "seen" by either an employee running "sniffer" software on the network or by an external hacker "listening" to inter-building leased lines (see network section). This is due to a weakness in the Telnet protocol. Although proprietary security extensions to this protocol exist, none have been (so far) widely adapted.

 

X Windows

Introduction

The X Windows System is a very flexible, standardised, but often insecure Graphical User Interface (GUI) available on UNIX machines, PCs, NT and even VAX. X Windows, developed at MIT (and in the public domain) has a client / server based architecture. The first widely adopted version of X Windows was Version 11, Release 3. This is known as X11R4. The current version is X11R6. The term X11 is often used interchangeably with the X Windows System. X11 from MIT is often referred to as Vanilla X, to distinguish it from it's numerous commercial equivalents.

The X client is the program or application and the X server is the software which controls the screen and it's windows. This (somewhat confusing) naming convention often means that the X Server runs on the user's local machine and the client runs on a server! The X server and X client communicate via the X Protocol. The X protocol can be running on a local machine only (where client & server are local), or it can be running across a network (where client & server are separated as above). An X Terminal is a screen, keyboard and mouse with controlling X server software which make the X terminal available to X clients.

Many clients can be running on one server. These clients can originate from machines anywhere on the network. The inter-client communication and the access control (which clients are allowed start on which server) must be controlled. If one client is able to send information to another, capture information meant for another or spoof information to another client, security may be compromised.
Typical inter-client communication includes:

Rogue clients could attempt to delete/modify or replace such communications. 

General recommendations

xhost

Each X server maintains a list of hosts which may access it: i.e. clients from these hosts may use the X server to display/manipulate windows. The xhost command is used to manage the host access control list (ACL) for all future connections. Existing connections are not affected. Some examples are:
 

xhost + Allow connections from ANY host (not recommended!). The ACL still exists, but has no effect
xhost +host1 Add host1 in the local domain to the ACL.
xhost +host1.mydomain Add host1 in the (DNS) domain mydomain to the ACL.
xhost -host1 Remove host1 from the ACL.
xhost display the current ACL.
xhost - Restrict access to current ACL. If xhost + was not used beforehand, this has no effect. If xhost + was executed beforehand, the ACL before the xhost + command is restored. IMPORTANT: xhost - does not mean that no host has access!

If a user tries to connect to the server (called SERVER_NAME in this example) from an unauthorised host, the following error message is issued:

Xlib: connection to "SERVER_NAME:0.0" refused by server.
Xlib: Client is not authorised to connect to server.

The xhost mechanism is purely host based i.e. if a host is granted access, all users on that host are granted access. In a workstation environment of one user per host, this not such a problem, however a multiuser server, if granted access to a workstation, opens up a considerable security risk.

xauth

With Token based authentication, a token (in this case a random number) is attributed to a user's X11 session. Any client which wish to connect to the X11 server must furnish this token. Since this token is normally only available to the user who own the X session, this token provides a user based access control mechanism. The token is called a magic cookie in X11 terms. For a user logged onto just one machine, the additional security is transparent.
The magic cookie is stored in the .Xauthority of the user's home directory. The program xauth is used for adding/reading/deleting the cookie. To list cookies, use xauth list and to show auth status, try xauth info. Typing xauth alone gives a prompt, at which one can type ? or help to get a list of commands.

Cookie creation:
There is not a standard mechanism for creating the cookie! Sun's OpenWindows and XDM (see below) automatically generate a magic cookie on startup, but other X11 systems may require manual cookie generation. There a few different possibilities, if $HOST contains the name of the local screen, the following could be used in xinit:

  1. Using the korn shell random number generator:

  2. xauth add ${HOST}:0.´ksh -c 'echo $(( $RANDOM*RANDOM*2 ))'´
  3. Using the clock:

xauth add ${HOST}:0.´date +"%y%m%d%H%M%S"´

Also add the random number the UNIX PC name in addition to the TCP/IP name above:

xauth add ${HOST}/unix:0 . RAND_NUM

Cookie distribution:
If a user wants to start clients from a remote host, how can he grant access to his local display? Two possibilities come to mind:

  1. Both the remote and local host mount the same home directory for this user, therefore the user accesses the same .Xauthority file from both hosts and access control is automatic. (CHECK THIS!)
  2. Home directories are not shared. In this case the .Xauthority file on the remote machine needs to be synchronised. If a .rhosts file exists, the following can be used.

auth extract - $DISPLAY | rsh REM_HOST xauth merge -

Note: use SSH, nor rsh - the above is just an example.
Or, if the X11R5 contrib client xrsh is available, a remote client can be directly started:

xrsh -auth xauth REM_HOST xload

Recommendations:

 

Read the following article which explains SUN-DES-1 authentication and the topics covered above, but in more detail:

Inside Solaris: Reviewing your X Window security, Boris Loza
http://www.elementkjournals.com/sun/0104/sun0141.htm

 

Sun OpenWindows

Common Desktop Environment (CDE)

The is a new standard Window Manager for UNIX desktops, supported by the major vendors. It is basically Motif with HP's OpenView looks and Sun's OpenLook Tooltalk engine and desktop utilities. The underlying windowing system is X11R5 or R6. 

X Display Manager (XDM)

XDM is a GUI login system which allows login to different X servers.

DisplayManager*authorize: true

XDM will automatically create the magic cookie when started and copy the cookie into .Xauthority.

TBD: authentication for xdm type login (-broadcast, -query, -indirect). Query method recommended. 

Xterm

The best known X client is probably the standard terminal emulation, xterm. This tool has some strengths & weaknesses in the security area. First, the following option should be set in the resource file:

xterm*allowSendEvents: False

This ensures that artificial events (i.e. those not generated by either mouse or keyboard) are ignored. This helps prevent spoofing.

Now the keyboard is shared among all running X clients by the X server. If an X client is reading in critical information (e.g. a password), it wants to be sure that no other X client can read the keystrokes. To take full control of the keyboard (no other client can receive input), xterm provides the "Secure Keyboard" option, attainable from the menu (CTRL + left mouse button). This option must be turned off to work again in other windows. For this reason, it is not very practical.

Patches:

Workflow Managers

Staffware V5

General

Staffware is a Workflow manager which allows complex administrative routines to be automated.

Outstanding issues:
* Interaction with Oracle
* Connection to OLTP details, RPC communication between Staffware servers
* Transaction integrity? 

Accountability

User identification / authorisation
Audit Trail

A detailed audit trail is available of Staffware operations.

Access Control

Object Reuse
N/A

Secure Data Exchange

Communication with Oracle:
Staffware stores it's data in Oracle tables and communicates with Oracle via SQL.

Staffware multi-node configuration:
Staffware servers can communicate with each other as peers to co-ordinate workflows between servers.

Peer Entity authentication
Integrity

Integrity of data transfer is guaranteed by TCP/IP and the RPC or email transports.

Confidentiality

Passwords are transmitted over the network in clear form.

Non Repudiation of origin/receipt

Digital signatures are not supported. 

Availability

Backups
Redundancy

none available? 

Developing Secure Applications

General Guidelines

UNIX Application development

See also [unix1] and the UNIX chapter.

New: See also http://www.sunworld.com/swol-08-1998/swol-08-security.html?080198a (I've not yet compared it with the above, but it comes from a good source..) Local copy.

Development languages

Use a security conscious language such as Java (or Ada) rather than C. Likewise use tainted perl rather than perl. Most actual security weaknesses in programs are due to a) bad design (e.g. sending passwords in clear text) or b) bad programming (e.g. string/stack/array overflows, wild pointers, race conditions)

Java Recommendations:
C++:
C Recommendations:
Perl Recommendations:

Note: This should match name@domain where name and domain can have letters, words, underscore, a dot or hyphen as characters.

This example removes all characters except 0-9:

$value =~ tr/0-9//cd;

The following code thoroughly cleans out shell characters, but might clean too many characters in some situations (e.g. user text with commas and question marks):

$value =~ s/'\"|*?~<>^()[]{}$\n\r";,//g;

CGI programming

Follow all the rules in the previous section, in addition:

Client/Server Communication

RPC
Sun RPC: See 18.6.6.2. Sun's RPC (also called ONC RPC) allows asynchronous and synchronous calls. Most current applications use this RPC as standard. However it provides no security options (they must be implemented at the application level).

Consider using Secure RPC rather than "normal" Sun RPC where possible. (e.g. Secure NFS). RPC is difficult to filter on firewalls.

NT RPC: The bits of DCE RPC that MS uses. Use extensively by NT services.

Sockets
Sockets is the current defacto standard for client-server applications. Unfortunately, the Socket protocol (originating in BSD UNIX) is a communication method with no inherent secure communication support. Application must implement security themselves.

Using non-standard socket numbers: This makes attacks on socket based servers more difficult. However this is "security through obscurity" and it is desirable to co-ordinate the socket numbers allocated to programs. In the author's opinion, the security gained is not worth the hassle of managing non standard numbers.

ActiveX Programming

 

ASP (Active Server Pages) Programming

The paper "Best practices for input validation with Active Server Pages", by Jerry Connolly explains how to do checking of input. http://heap.nologin.net/aspsec.html

 

Tools for code checking

References

Changes to this document

----------------2001 ----------
05.jan'01 Applications (update notes on ActiveX)
----------------2000 ----------
31.Dec'00 Applications (cgi-programming: add Xato ref.)
15.Dec'00 Applications (code checking tools)
26.Oct'00 Update: Java security links. New: Tools for code checking
15.Feb'01 Perl & Win2k programming references, Private Keys Exposed in Java 1.1
23.Feb'01 Remote Java probing tool
10.May'01 ASP (Active Server Pages) Programming
25.Jun'02 Add reference "Secure Coding" by David Wong.

[java1] 1996 IEEE Symposium on Security and Privacy, "Java Security: From HotJava to Netscape and Beyond", Princeton University
[2] Two students from Berkeley University found this one. Nov. 1995.
[3] The security token can be create en masse for a group of users via the SIMPORT.EXE command line utility.
[4] Solaris 2.5 is V8 based.
[5] The first virus written in WordBasic circulated on the Internet in Aug.1995. In Feb'97, the University of Hamburg reported 205 (mostly Winword) macro viruses. VisualBasic scripts made things even worse in 2000.
[activeX] "Results of the Security in ActiveX Workshop" www.CERT.org or the Local Copy

previous  next  Title  Contents  Index     IT Security Cookbook, 25 juin, 2002