Viewing file:     SECURITY.html (12.21 KB)      -rw-rw-rw-
Select action/file-type:
(+) | (+) | (+) | Code (+) | Session (+) | (+) | SDB (+) | (+) | (+) | (+) | (+) | (+) |

---

SqWebMail security

This document discloses security-oriented issues regarding the SqWebMail CGI application.

In this document:

• User IDs and Passwords
• Mailbox IDs
• Authentication
• Browser Security - History
• Browser Security - Caching
• Browser Security - HTML
• Browser Security - Referer: Tags
• Sending Mail
• Setuid Root

User IDs and Passwords

SqWebMail's security scheme requires a valid userid/password to access an account. The actual method for validating the userid and password is a black-box module that can be easily replaced. The example black-box implementation uses the PAM library, if available, or with the /etc/passwd, /etc/shadow and the crypt() function.

It is possible to configure SqWebMail to transmit the userid and password via secure HTTP. If secure HTTP is not available, the userid and password is transmitted over the network in the clear, which can be picked up by a sniffer.

Mailbox IDs

After a userid and password is authenticated, the authentication module returns a 'mailboxid'. The mailboxid is used as a handle for the mailbox. A mailboxid may not necessarily be the same as the userid, but the sample authentication modules make them the same.

Technically, the mailboxid that's generated by recent versions of sqwebmail are of the form "userid.method", where method represents the authentication module that was used.

A mailboxid is sent with every HTTP request, in the request itself. Note that the mailboxid is transmitted over the network in the clear. It is also possible to use secure HTTP for the every HTTP request, not just initial authentication, but this has not been tested.

Unless the mailboxid is the same as a userid, there aren't many security considerations in having the mailboxid broadcasted over the network. That's because the mailboxid in the HTTP request is usually validated based on a time-limited IP address (see "Authentication"). Note that there certain other potential ways - in addition to network traffic sniffing - for an unauthorized party to attempt to grab mailboxids. See "Browser Security - HTML", and "Browser Security - Referrer: Tags".

Authentication

Once the user ID and password are authenticated, authentication for subsequent HTTP requests is based on a combination of an IP address, plus a 128-bit random number that was generated during the login.

By default, SqWebMail permits access to the mailbox only from the same IP address as the one where the user ID and password was authenticated from. This can be selectively turned off at login time, in cases where the client is behind a load-balancing firewall that uses multiple IP addresses. In all cases, a 128-bit random number must be transmitted with every HTTP request, and it must match the number generated during the login, which is saved in the Maildir directory.

The Maildir directory must therefore have any group or world access rights disabled. Additionally, every page served by SqWebMail includes HTTP headers containing instructions to proxies and browsers that prohibit this page from being cached. There are some buggy web browsers out there - most of them originating in Redmond,WA - that ignore these caching directives, and they end up saving the 128-bit random number in the local cache. Unless access to the physical machine is secured, the local cache can be trawled to obtain the 128-bit authentication token.

However, access to the mailbox is allowed only for a maximum period of time after the initial authentication. Access is allowed only if the HTTP requests come within a different, shorter period of time. If no access requests have been made for a certain period of time, access will no longer be available even if it comes from the right IP address, with the right authentication token.

The IP address of the initial authentication, the dates and times involved, are all stored in files in the maildir directory, with group and world permissions turned off.

Browser Security - History

In certain situations a mailboxid is a part of the actual URL requested. A browser may maintain a history file of visited URLs.

SqWebMail uses a frame window in an attempt to keep the browser from recording visited URLs. This approach works for most popular web browsers that support frames - these browsers do not maintain history for individual frames. Note that frames are not required to access the full SqWebMail functionality.

Browser Security - Caching

SqWebMail sets the expiration header on every HTTP page it serves. Individual pages contain URLs and hidden fields with mailboxids. The expiration header should keep the web pages from being saved in the browser cache.

Browser Security - HTML

SqWebMail has the ability to display HTML E-mail, which leads to several complicated situations regarding embedded Javascript or Java applets that try to grab the mailboxid of the recipient (amongst other things). SqWebMail attempts to remove all forms of scripting from HTML E-mail as follows:

• The following HTML tags are removed: <SCRIPT>, </SCRIPT>, <APP>, </APP>, <APPLET>, </APPLET>, <SERVER>, </SERVER>, <OBJECT>, </OBJECT>, <HTML>, </HTML>, <HEAD>, </HEAD>, <BODY>, </BODY>, <META>, <TITLE>, </TITLE>, <FRAME>, </FRAME>, <LINK>, <IFRAME> and </IFRAME>.
• The following HTML attributes are stripped from every tag: ONLOAD=, ONMOUSEOVER=, and all ON*= attributes; BACKGROUND=, STYLE=, TARGET=, CODE=, CODETYPE=, and LANGUAGE= are removed; TARGET=_blank is added to all <A> tags.
• The HREF and SRC attributes are stripped, unless the URL starts with one of the following: http:, https:, ftp:, gopher:, wais:, or telnet, and cid:.
• The HREF and SRC attribute values are prefixed with a URL that will resolve to SqWebMail, and with an additional TARGET="_blank" attribute. A request to that resulting URL will result in a blank page with a 0-second refresh to the original URL. This method strips mailbox IDs from Referer: tags sent to external web site. If the HREF attribute starts with a cid:, it is replaced by an http: reference to SqWebMail that will return the specified MIME part.
• IMG tags are removed and replaced with an A tag, in order to keep the HTTP client from automatically loading any images from external web sites, upon opening a given message.
• Everything inside the STYLE tag is removed.

Browser Security - Referer: Tags

See the previous section regarding how SqWebMail attempts to remove mailbox IDs from Referer: tags.

Sending Mail

SqWebMail includes the ability to send mail. Issues regarding transmitting E-mail from the HTTP client to the server are obvious. SqWebMail runs a wrapper shell script in order to send the E-mail message. The wrapper shell script normally runs qmail-inject, sendmail, or something else, immediately. SqWebMail prepares a complete E-mail message.

SqWebMail depends on the mail server to read the headers for recipients and to strip out the Bcc: header. SqWebMail uses the black-box authentication module to set the contents of the From: header and provide the envelope return address.

The IP address of the HTTP client is not inserted into the headers, however the wrapper and the mail server are invoked under the userid of an authenticated user. The wrapper shell script can be modified to insert the IP address, if so desired. The wrapper shell script has access to the CGI REMOTE_ADDR environment variable.

SqWebMail daemon

sqwebmaild is the meat of the code. It's a daemon process that runs as root, and listens on a publicly-available UNIX domain socket. The tiny sqwebmail CGI binary is a stub that connects to the daemon, forwards the HTTP request, and passes along sqwebmaild output to the HTTP client.

sqwebmaild essentially receives a bunch of environment variables that comprise the HTTP request. Anyone on the system may connect to sqwebmaild's socket, and send it a bunch of environment variables, just like anyone can connect to the server and send any HTTP request to it. However, sqwebmaild places an upper limit on the size of the environment, and will only accept the environment variables which are used in HTTP request, discarding any environment variables that it does not recognize (PATH, LD_LIBRARY_PATH, etc...).

When virtual mailboxes are being used, it is possible to run sqwebmaild under the virtual userid, instead of root. Apart from the obvious changes, the --with-cacheowner option must be used so that the login cache is owned by the virtual userid also.

On some platforms this may not work without some additional tweaking. If authenticating with sqwebmail setuided to the virtual userid doesn't work:

• Verify that the password has been correctly set.
• Remove the source file authlib/changeuidgid.c. Replace everything in that file with the following three lines of code, exactly as shown:

  void authchangegroup() {}
  void authchangeuidgid() {}
  void authchangeusername() {}
      

• Recompile and reinstall.

sqwebmaild takes the following action when it receives an HTTP request via the local socket:

• Determine if the HTTP request is a request from a client that's already logged in. The other possibilities are the login request itself, or a couple of requests which are used to show the initial login screen. This is determined by the presence of the extra path in the HTTP request. This approach avoids the need to parse HTTP arguments. If the extra path containing the login ID is present, the login ID is extracted, SqWebMail changes to the account's Maildir directory, and drops root privileges. The CGI environment is read, and the request is authenticated (see Authentication, above).
  
  
• If it's a login screen, the appropriate forms are generated.
  
  
• If it's a login request, SqWebMail makes sure that the request format is NOT a multipart/formdata POST, which takes the most amount of code to interpret. Additionally, requests indicating more than 128 bytes of posted data are rejected prior to even parsing them. Barring all that, the userid/password is fetched from the request, and processed. The multipart/formdata check shouldn't be necessary given a 64 byte upper limit on unauthenticated requests, but it can't hurt.