User:DCamp/Malware Security Review

From MozillaWiki
Jump to: navigation, search

Status

Feature tracking bug

Has a design review been completed?

Not formally.

When do you anticipate the feature landing

See "Schedule" below.

Overview

Firefox 3's phishing and malware protection is an evolution of Firefox 2's phishing protection.

The url-classifier stores a set of blacklisted fragments. A fragment is one URL fragment containing two or more domain components and some number of path components.

Fragment examples:

  • example.com/
  • www.example.com/foo/bar
  • www.mail.example.com/mail

A load will be blocked if its URL includes one of these fragments (for example, www.example.com/blah/blah/ will match an example.com/ blacklist).

The fragments are served by the safebrowsing server as truncated SHA256 hashes. In most cases we receive the 32bit prefix of the hash. In some cases (excessive collisions, popular sites) we will receive a longer version of the hash (currently a 128bit prefix).

During lookup, if a 32bit hash prefix match is found, we request the longer version of the hash from the safebrowsing server. The results of the lookup are cached for the lifetime of the original entry.

If an extended hash matches (whether the hash was originally sent as an extended hash, or later extended by a gethash request), we block the page.

Use Cases

Describe the primary use cases for the feature here.

Requirements

List functional and non-functional requirements for the feature here, with links back to any relevant product PRD. These requirements should be prioritized.

Schedule

  • Version 2.0 protocol landed in M7.
  • Version 2.1 protocol landing in beta3.

UI Design Documentation

The UI for Malware and Phishing pages in Firefox 3 is documented in Bug 380932. Briefly, it involves blocking the user's pageload, and presenting them with an error page in the content area. Unlike typical error pages, this one is coloured red and black, with strong cautionary text explaining that the page has been reported as an "Attack Site".

The expectation is that, while users may not be familiar with "malware" as a term, they are able to understand language like, "Attack sites try to install programs that steal private information, use your computer to attack others, or damage your system."

The page does not provide a workaround, though it mentions that this blocking was done based on the user's security preferences, giving them a direction, if they elect to disable the behaviour. It also provides a "Request a review" link, to give them some affirmative next step to take, if they are an owner/operator of the site in question.

Demo Site for Malware Protection

Design Impact

Security and Privacy

What security issues do you address in your project?

  • Malware and phishing URIs are blocked during docshell loads (browser tabs and iframes).
  • Malware and phishing URIs will be blocked in <object> loads (bug 394485)

Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?

If the database is corrupted or missing, the user will be at risk while the database is repopulated.

Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.

Most of this remains unchanged from the phishing protection in v2, with a few changes:

  • iframes are now checked.
  • Redirects are now blocked from blacklisted sites.
  • The phishing UI no longer shows the rendered version of the page underneath.
  • There are some privacy implications for the gethash request.
  • The check-every-time option is being removed.

Exported APIs

Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)

Exported to XPCOM:

Protocols:

  • The main updating protocol is at [1]

Does it interoperate with a web service? How will it do so?

There are two web services: the main update server from which truncated hashes are fetched, and the gethash server from which complete hashes are fetched after a match.

Explain the significant file formats, names, syntax, and semantics.

The hashes are stored in a sqlite3 database.

Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?

Hopefully!

Does it change any existing interfaces?

nsIUrlClassifierDBService and nsIUrlClassifierStreamUpdater were changed.

Web Compatibility

Does the feature had any impact on Web compatibility?

No.

Performance

How will the project contribute (positively or negatively) to "perceived performance"?

Lookup involves queries against a large sqlite database, which incurs disk penalties. This lookup occurs after the request is sent to the server, but before the response is read from the socket, so the performance impact is hidden a bit by network latency.

What are the performance goals of the project? How were they evaluated? What is the test or reference platform and baseline results?


Will it require large files/databases (for example, browsing history)?

urlclassifier3.sqlite.

Reliability

What failure modes or decision points are presented to the user?

(Not sure this is the right section for this, but) If the gethash server cannot be contacted, a partial hash match (most matches!) will not be properly blocked.

Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

We rely on sqlite for data file reliability. If the sqlite file is corrupted at startup, we remove it and repopulate it from the server.

l10n and a11y

are any strings being changed or added?

Yes (see UI section).

are all UI elements available through accessibility technologies?

The UI additions are interstitial xhtml pages.

Installation, Upgrade/Downgrade/Sidegrade, and platform requirements

Does it equally support all Tier-1 platforms?

Yes.

Does is have a hardware requirement (or increase minimum requirements)?

No, short of disk space for the DB.

Does it require changes to the installer?

No.

Does it impact updates?

No.

List the expected behavior of this feature/function when Firefox is upgraded to a newer minor release, downgraded by installation of an earlier revision, or re-installed (same version)

Upgrades between major versions use different classifier databases.

Upgrades between minor versions without schema changes will continue to use existing databases.

Upgrades between minor versions with schema changes will start the database from scratch, but this isn't expected to happen.

configuration

Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?

There are user-visible prefs for:

  • Blocking malware.
  • Blocking phishing.

There are non-user-visible prefs for:

  • Update server URL
  • gethash server URL

Are there build options for developers? [#ifdefs, ac_add_options, etc.]

There is an --enable-safe-browsing option.

What ranges for the tunable are appropriate? How are they determined?

"On".

What are its on-going maintenance requirements (e.g. Web links, perishable data files)

  • The google safebrowsing server.
  • its-an-attack.html and its-a-trap.html

Relationships to other projects - are there related projects in the community?

If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?

Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?

We are working closely with google's safebrowsing team.

Documentation

  • Do built-in Help pages need modified?
  • Documentation for developer.mozilla.org?

Other

any other implementation or design related documentation

Discussion & Implications

Caveats / What We've Tried Before

links to previous design documents, discussions, etc.

References

Retrieved from "https://wiki.mozilla.org/index.php?title=User:DCamp/Malware_Security_Review&oldid=80581"