r4 - 05 Dec 2007 - 21:57:36 - HeikkiToivonenYou are here: OSAF >  Projects Web  >  DevelopmentHome > SecurityFramework > SecurityThreats

Security Threats

This document started out as a rewrite of the Mozilla Security Reviewers' Guide (http://www.mozilla.org/projects/security/components/reviewguide.html), tailored for Chandler.

Resources to Protect

Knowing what resources we want to protect is the first step in determining how to secure Chandler.

  1. The integrity of the system that Chandler runs on.
    • The integrity of the operating system
    • The integrity of other applications
    • Data on the system or protected or accessible by the system
  2. Integrity of Chandler itself.
  3. Data stored by Chandler.
    • Repository
    • Local settings and preferences
    • Data sent over the network

Threats to protect against

The next step is specifying an effective security plan is specifying what kinds of threats we must secure Chandler against, to the best of our ability. It is important to realize that we cannot list all threats since they are too numerous and new threats can be discovered in the future that we do not know about.

  • Running arbitrary code
    • The worst-of-the-worst kind of breach. The attacker can do anything - read, modify and delete any data; access other machines the user can access; impersonate user; launch other attacks from the machine and so forth.
    • Some typical causes for this include buffer overflows, format string problems and accidentally executing code (or if the execution was intended, out of a sandboxed environment by accident).
  • File system access
    • There are basically two versions of file system access: unlimited, and limited to files and areas that Chandler itself uses. Further, the access may be limited to read, write or delete, or any combination of access. This breach can lead to other threats.
    • Some typical causes include race conditions.
  • Stealing privileges
    • When a user has logged into a system (email, instant message), some kind of credentials are stored by the application. During this time an attacker may be able to impersonate as user to read and send email, instant messages and so on without actually knowing the user name and login (or other credential) of the user.
    • Some typical causes include failing to prevent cross domain access (for example, email messages should not be able to have access to other email messages, instant messaging should not have access to email)
  • Information leakage
    • Sometimes information is divided into personally identifiable (name, email, ...) and other information, but in the end everything must be protected. Some information leakage may necessary for systems to function properly (for example, an IMAP email client will naturally tell the server that it supports IMAP). When applications require personally identifiable information to function, we must have user consent before sending the information out.
    • Some typical causes include not destroying temporary files.
  • Spoofing
    • Often UI spoofing where content has parts that look like actual application and tries to fool the user into using the fake controls to perform some tasks (for example, an email message might have fake buttons to send and receive emails whose function is controlled by the attacker). Note that sometimes it is extremely difficult to prevent this, and practice has shown that users may not notice this even when it is very obvious (for example, Unix user sees a fake Windows dialog box and thinks it came from the Unix operating system).
    • Some typical causes include UI design where there is no clear distinction between content and the application.
  • Denial of service
    • There are many levels in denial of service, and while we must protect against more or less permanent denial (for example after reading a bad email the user can no longer read any email), it is not as important to protect against threats that the user can simply avoid (for example, if a specific email message causes crash the solution is not to read it in the future).
    • Some typical causes include not checking input.

Limited protection threats

In an ideal world we could provide perfect security against everything. However, that is simply not possible for some threats. We can make things harder for attackers, though.

  • Physical access
    • If an attacker has physical access to a computer, they can run debuggers, install trojan software, and eventually bypass any security measures.
    • We can make it harder for attackers by using various methods like access control, encrypting data, and so on.
  • Downloaded and executed code
    • We can't do anything about external applications. If the user downloaded and installed trojan software, the attacker effectively has physical access, so we are back in that case.
    • Chandler extensions are a subset of downloaded and executed code that we can have some control over. We could limit what the extensions can do (basically run extensions in a sandbox), and inform the user best we can about the source of the extension before installing an extension, and letting the user decide (signed extensions, getting extension from trusted source). A point to notice is also the method of installation - some installers can do whatever they want, while some installers have limited capabilities.

Recommended Reading

  • Building Secure Software: How to Avoid Security Problems the Right Way by John Viega and Gary McGraw, ISBN 020172152X. Book site 1.
  • Writing Secure Code, 2nd Edition by Michael Howard and David LeBlanc, ISBN 0-7356-1722-8. Errata

  • Secure Programming Cookbook for C and C++ by John Viega and Matt Messier, ISBN 0-596-00394-3. Book site 1. Errata.
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r4 < r3 < r2 < r1 | More topic actions
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.