History

Security And Privacy

This document describes some of the security/privacy related concepts in Hyperactive. The aim of this document is to provide some introduction and help for further in-depth security reviews. Please note that this is a work in progress.

Introduction

Hyperactive was originally developed in 2008 for Indymedia London ( http://london.indymedia.org ). As such it's core target are people who like to run websites in the spirit of Indymedia ( http://en.wikipedia.org/wiki/Independent_Media_Center ). Indymedia has always taken the privacy and security of its users very serious and produced a document describing those aims (see paragraph 4 of http://docs.indymedia.org/view/Global/PrinciplesOfUnity ).

In fact, as Hyperactive was developed from the start mainly for Indymedia use rather then becoming a general purpose CMS, privacy concerns were part of the development process from the first moment.

Other considerations were

  • to create a content management system based on modern and well maintained framework ( see below )
  • to allow users both open publishing without registration and user accounts, giving users a more active role in running a community based website
  • support multimedia in a way to avoid relying on external commercial services and encourage users to use Hyperactive to publish media rather then linking to commercial services such as Youtube

How Hyperactive is taking care of users' privacy

The first and very basic principle is to limit the access to privacy related data (especially IP addresses) from inside the CMS. Hyperactive itself does not connect IP addresses of users to pages or articles anywhere, and there is no mechanism to see the IP address of a contributor or visitor from inside the CMS.

In addition to this, it is recommended that Hyperactive be installed with an Apache2 mod_passenger setup and it is recommended to use Apache's mod_removeip ( https://code.autistici.org/trac/privacy/browser/trunk/libapache-mod-removeip/upstream/trunk/README ) as an additional layer of privacy. This will ensure that even in a case where somebody manages to compromise the CMS to change the code base, the application still has no access to the REMOTE_HOST environment variable. All Hyperactive installations we are currently aware of use this setup.

Therefore there are currently two mechanisms of protection against leaking a REMOTE_HOST IP:

1) Apache2 with mod_removeip prevents Apache from handing over the REMOTE_HOST to the web application
2) Overriding of whatever is handed over by Apache2 in Hyperactive ( see http://projects.escapegoat.org/projects/hyperactive/repository/entry/lib/path_tracker.rb )

User Accounts

Differently from some older Indymedia CMS ( e.g. MIR, Active, Sf-Active ), Hyperactive allows users to open user accounts to publish articles and media. This was a feature requested by many users for a long time, as it gives them the chance to edit/update/improve their articles later. This is purely optional and of course Hyperactive offers total open publishing without any login as all other Indymedia CMS do.

However, in addition to open publishing, even logged in users can choose freely under what username they publish, hence making it impossible for site visitors or normal registered users to see that an article is connected to a user account.

Group Accounts

Users can also create groups and add other users to it. If an article is tagged for a group, this will be obvious to the site visitors, still users can choose any username they want and to hide under what user account the article was published.

Statistics without compromising privacy

As Hyperactive is using the ruby on rails framework, it is uses the rail_stat module to gather some statistics ( such as page hits ). We have changed the default rail_stat code so that it gathers much less information than a standard rail_stat installation. Things like the user's IP address, screen resolution, browser minor versions, whether they've got Flash or Java installed, etc., are not retained. We also recommend that sysadmins using Hyperactive install mod_removeip in order to provide a double layer of security against IP address retention. There's no reason not to!

rail_stat will give you a rough impression of the traffic of your site, which is useful to identify peak times or upcoming resource problems. rail_stat by default also keeps rough statistics about what browsers hit your site ( as in "50% firefox / 10 % safari" ) which might be helpful to decide what technical features you might want to implement ( e.g. HTML5 video / flash / silverlight ). Again, rail_stat does not give you those details in connection with single users. Before designing our system, we consulted with some of the foremost security/anonymity experts in the United Kingdom about data retention, to find out about both the technical and legal implications of storing information about our users via logging/stats tracking.

Back to rail_stat. The actual hits are inserted into the database in /lib/path_tracker.rb . As you can see there, Hyperactive replaces most values which are either empty or bogus values. ( such as the platform variable, which is replaced by "GNU/Hurd" for any hit ) In earlier versions in the master branch, some other details (like browser version) were saved too but those have been removed as unnecessary.

The database schema is still the default rail_stat table scheme for compatibility reasons, however in the future we might anyway replace rail_stat by a different module or a custom approach.

As a summary, the only statistics saved in the database are:

  • path
  • total hits ( how often a path was called )
  • basic browser ( e.g. "firefox" or "internet explorer" )

All other values are empty or bogus. There is no mechanism to change those settings from within the CMS.

Media Metadata

Some media files store metadata about date/camera model etc which can leak information about the user who uploaded it. Hyperactive calls the external tool jhead ( code example ) to remove such data from the uploaded images:

see

An example from tumble.rb:

def delete_exif_data
     system("jhead -purejpg #{file.path}") if image? && file_content_type == "image/jpeg" 
end

A recent experimental patch also enables Hyperactive to remove some potentially private information from PDF files, as some PDF creation software saves the account user name inside the file, a fact many people are not aware of. This patch is based on the external pdftk tool ( http://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/ )

system("pdftk #{file.path} update_info #{File.expand_path(RAILS_ROOT)}/config/pdf-options.txt output #{file.path}_tmp >/dev/null 2>&1")

where all private information in the PDF header is overwritten with bogus values. ("John Doe")

Due to the diversity of metadata formats in media files, this layer of privacy is still work in progress, but aims to remove private information wherever possible.

IRC bot

Hyperactive includes an IRC bot to report publishing activity and media encoding to an IRC channel and supports encrypted connections via SSL, for implementation details see:

http://projects.escapegoat.org/projects/hyperactive/repository/entry/lib/workers/irc_worker.rb

The bot will not report any privacy related information to IRC and is an optional functionality and not mandatory to run Hyperactive.

Dependency on closed source plugins (e.g. adobe flash )

Hyperactive has offered video playback via Flash from the start and added support for HTML5 video since autumn 2010. Currently a Hyperactive website is fully usable without having flash installed, as the default view for videos falls back to use HTML5/theora if no flash plugin is available/installed in the browser. Download links for h264 and theora are provided by default if neither HTML5 nor flash is available.

see http://projects.escapegoat.org/projects/hyperactive/repository/entry/app/views/videos/_video.erb

Encoding integration/optimization for webm (vp8/vorbis) is currently under development.

Javascript

Currently Hyperactive uses the Prototype ( http://www.prototypejs.org ) javascript framework for most tasks. The upcoming Rails 3 version of Hyperactive has migrate to jquery (http://jquery.com ) and will be available in the near future. Some admin related tasks depend on javascript, however, it is possible to browse and use a Hyperactive installation with no-script enabled.

javascript can be found in http://projects.escapegoat.org/projects/hyperactive/repository/entry/public/javascripts/

Input validation

Hyperactive uses the white_list and sanitize_params plugins to validate/sanitize all untrusted user input. For details please
see the following files in the master branch:

Protection against spam

Hyperactive has two mechanisms to protect a site from spam:

  • captcha against spambots (an optional - password protected - mechanism to bypass a capture is provided to allow posts via https from a remote application is provided, e.g. chiffchaff - see below - makes use of this mechanism)
  • a regular expression based filter

SSL / HTTPS

Hyperactive works nicely with a HTTP/HTTPS as all pathes are relative to the URL. If an image or other media file would be requested from a non-https path when browsing the site on HTTPS it would be considered a bug. We are also currently also trying to add a patch which replaces absolute pathes to the site in articles/features by relative paths automatically to avoid that people leave the HTTPS connection involuntarily while browsing the site.

Open Source Development Model

We believe that the open source model is the best way to develop a secure application

To facilitate a quick fixing of bugs which limit usability, we run a bug tracking system at:
http://projects.escapegoat.org/projects/hyperactive/issues

For more general problems there is a forum at:
http://projects.escapegoat.org/projects/hyperactive/boards

Development community

Currently all indymedia sites which use Hyperactive share the same git repository at escapegoat.org (see also http://projects.escapegoat.org/projects/hyperactive/repository/browse/mods ), while having their own branches to keep local changes and customizations.

The main mailing list for hyperactive can be found at:

https://lists.aktivix.org/mailman/listinfo/escapegoat

Security announcements and major updates will be posted there, too.

If you think you have found a security related bug, please contact the security team at . You will find the team's public gpg key here

Our procedure is that the security team will then

  • acknowledge your report as soon as possible
  • inform known administrators of hyperactive confidentially by giving a security warning
  • fixing the bug as soon as possible in the master branch
  • issuing a public warning to advise people to update hyperactive

It has been good practice in the free software community for a long time to report security related bugs in a confidential way first before disclosing them to the public.

Code security / Ruby on Rails

Of course, the best privacy can be compromised by flaws in the code. One reason Ruby on Rails(RoR) was choosen as a framework for hyperactive was that RoR is a very well maintained and tested ( http://www.rorsecurity.info/security-audits/ ) framework used in many high profile websites. A huge community of developers takes care of reviewing and fixing bugs of RoR, making it much easier for us to keep the system secure.

External services

Hyperactive does not allow embedding media from third party websites, e.g videos from youtube or vimeo, images from flickr. This is necessary to avoid leaking visitors IP addresses to other services. RSS feeds from other websites ( e.g. the feeds you can add to your group page ) are pulled by a producer script and are cached, too, to avoid any IP leak of a visitor.

see: http://projects.escapegoat.org/projects/hyperactive/repository/entry/app/controllers/external_feeds_controller.rb

While many users complain vociferously about this missing functionality (we have been literally yelled at for not allowing YouTube embeds), we feel very strongly about the subject and are happy to yell back. We are currently working on an experimental project called "thug" which might enable people to import media from other websites in a secure way in the future.

London Indymedia also runs a service to allow people to send messages directly to the tumblewire via SMS from their mobile phones. London Indymedia does not use any commercial "Text to web" service for this, but instead runs an installation of chiffchaff on a remote server. chiffchaff does not store any userdata at all and is only taking the text message itself and forwards it to hyperactive. Hence the information from what phone a SMS came from is not stored anywhere on our servers and never hits the actual hyperactive installation at any time ( not even in RAM).

However, due to the fact that SMS are of course sent via a commercial GSM network and are unencrypted, mobile network providers might store some information about connections made from phones ( data retention) . London Indymedia therefore warns people of this and asks them to keep this in mind when they send SMS (see http://london.indymedia.org/pages/mobile-publish ), especially if poeple use phones connected to their real names via mobile contracts.

Code Review and ongoing work

A first security review ( focusing on input validation / XSS/ SQL injection ) has been performed in 2009/10 ( this part of the code has not changed much since then). With the upcoming update to Rails 3 and improvements to hyperactive, we are currently preparing a major code review by third parties to get feedback on how to improve code security and concepts.

No XSS/SQL injection related bugs were found since very early stages of development and currently (April 2010) no open security related bugs are currently known.

We welcome security reviews of the code, please attack it and let us know of any problems you find.

Good practice recommendations

There are limitations of what we can technically do to protect a user's privacy. In the end security/privacy will rely on both that a user knows what he/she does and administrators behaving responsibly ( especially sysadmins ). For the user's side, we encourage IMCs to include static advice pages into a hyperactive installation to give users some hints what they can do (e.g. , using SSL, tor network, anonymous VPN , usage of public computers, open wireless, etc).

Future plans

some ideas exist to include some security tests in the ( not yet finished ) installer. we also prepare to offer some default hyperactive installations which can be used for third party intrusion testing.

startx, April 2011

Also available in: HTML TXT