Firefox Sync/Weave 1.3b5 Client Security Review
Contents
Overview
The purpose of this review was to review the Firefox Sync/Weave 1.3b5 client. The review methodology included reviewing the extension source code as well as manual testing of the client. The results of the previous security review can be found on the following page.
Weave/Sync_Client_Security_Review
The server side sync and registration components were not covered by this particular review. However a separate review was conducted for those component.s A list of bugs filed against the server and client for the 1.3 push can be found in the following Bugzilla metabug
Test Configuration
Client
Extension
- 1.3b5 built following wiki instructions
- Weave/Building
- Weave 1.3b5 client
Browser
- Firefox 3.6.3 on Mac OS X (10.6.3)
- New profile with no other extensions installed
Sync Data
- Generated by visiting Wikipedia and clicking "Random article" multiple times
- Some of these pages were bookmarked
Server
The server was a virtual machine running in VMWare Fusion
Configuration
- Linux kubuntu 2.6.20-17-generic #2 SMP Wed Aug 20 16:47:34 UTC 2008 i686 GNU/Linux
- PHP 5.2.1
- Apache 2.2.3
- weaveserver-sync 1.3rc3
- weaveserver-registration 1.3rc3
- SSL was not enabled for a majority of the tests
- A self-signed cert was used eventually used to test the SSL features of the client
Test areas and results
File system access
By default the client logs data to the user's Firefox profile directory. Certain sync data can also be found in the profile folder. The extensions create 3 folders with the the below hiearchy
<profile>/weave/changes/
<profile>/weave/toFetch/
<profile>/weave/logs/
where <profile> is the profile directory of the current user
The changes and toFetch folders contain .json files for each of the Weave "engines"
- bookmarks.json
- forms.json
- passwords.json
- tabs.json
- clients.json
- history.json
- prefs.json
A json object resides in each file which contains a list of Weave IDs and UNIX timestamps e.g.
{"Pgt4__97By":1274474584}
Weave IDs are generated in util.js and consist of a string of characters that do no need URL escaping.
The logs folder contains a txt file with the activity log for Weave. These files can be viewed in the browser by visiting about:weave-logs / about:sync-logs depending on the version of Weave. Weave uses log4moz.js for logging functionality
Logging levels and options can be set through about:config under extensions.weave.log.*
An audit was performed on the codepaths that set and consumed this json data. The utility functions jsonSave and jsonLoad are defined in source/modules/util.js . These functions are then used in source/modules/trackers.js and source/modules/engines.js . The Weave IDs are generated by makeGUID in util.js and are sent to the server. IDs stored in toFetch are retrieved from the server, and changes IDs are IDs to update on the server. There did not appear to be a codepath using this stored files to upload malformed data to the server.
Extension Configuration/Preferences
Weave configuration and preferences are stored with other Firefox preferences in about:config. The preferences are prefixed by extensions.weave.
Most of the settings took on boolean values and were only skimmed. The majority of settings that took string and integer values were also not particularly interesting. These settings included URLs for the server and miscellaneous bookkeeping data such as sync IDs.
extensions.weave.client.name was the most interesting setting. This value is uploaded to the server and displayed on other clients when a remote wipe is performed. The extension displays the below message
Warning: Your local data will replace all Firefox data on these devices!
- devicename a
- devicename b
- etc
Testing involved replacing the client.name string with values that would not normally be included in the generated string such as > and :. However there was no deviation from the standard workflow. The extension displayed a properly encoded string.
Client-Server Communication
Network traffic was captured by setting up Wireshark on the server VM. SSL was not used during the wireshark captures. The VM network adapter was set to NAT. Host-only was not suitable due to need to test certain reCAPTCHA workflows. The client creates custom REST requests to communicate with the server. This includes setting the appropriate headers and body data. As a result, the part of the normal Firefox network stack is bypassed. This is important since Weave uses HTTP Basic Auth to log a user in. There is also a lack of CSRF mitigation on the serverside. An initial concern was that it was possible to CSRF Weave sync workflows to delete / modify user data. However since the network requests are constructed by Weave, the HTTP Auth data is never stored in the Firefox browser context. A request to the Weave server endpoint will popup a login dialog even if Weave has logged in.
The Weave username/password is needed to retrieve data from the server, but this alone does not allow access to the plaintext data. Each of the client-server workflows was enumerated and captured with Wireshark. This included account creation, password/passphrase reset, sync, client reset and login. The client passphrase was not observed being transmitted over the wire. Aside from the account creation and login workflows, no interesting data was transmitted in the clear. Username password were transmitted as plaintext, however the suggested Weave server setup is to use the best practice of SSL.
The client also sends sync ID and client name to the server. Other data that is sent/retrieved is the weave IDs and timestamps for data stored on the server. The public/private key are sent as base64 encoded blobs with the private key protected by the generated symmetric key.
Manipulating IDs and timestamps sent to the server results in failed GETs but nothing adverse happened on the client.
Cryptography
The Weave project relies on the passphrase being secret. Compromise of the passphrase would allow an attacker to decrypt the contents stored on the server. Retrieving the public/private key requires that the attacker has the victim's username/password.
The review of the cryptography was mainly a check for proper implementation of known good algorithms. Weave relies heavily on the NSS library from cryptographic functions. The procedure used to secure user data is documented on the Weave wiki
Background links
The glue code for the crypto bindings can be found in the crypto/ folder. This includes the code to check and load the appropriate NSS library. A subset of the NSS API is exposed to the extension, including functionality for SHA256, AES and RSA keypair generation.
The wrapper functions for the Weave client are located in modules/base_records/crypto.js . Weave generates a separate IV for each WBO in the initial encryption process. This also leads to a new IV being generated when an entry is updated. A HMAC is used to detect data tampering. The user's passphrase is stored in the Firefox password manager, but never transmitted over the wire.
The overall crypto implementations in crypto/WeaveCrypto.js appeared to be sound.
