- tor-dev - lists.torproject.org

Re: [tor-dev] [tor-commits] [tor/master] Clarify who learns about ContactInfo.
by Roger Dingledine 09 Oct '13

09 Oct '13

On Wed, Oct 09, 2013 at 01:45:26PM +0000, nickm(a)torproject.org wrote: > diff --git a/src/config/torrc.sample.in b/src/config/torrc.sample.in > index c667efc..78013c2 100644 > --- a/src/config/torrc.sample.in > +++ b/src/config/torrc.sample.in > @@ -120,9 +120,12 @@ > ## is per month) > #AccountingStart month 3 15:00 > > -## Contact info to be published in the directory, so we can contact you > -## if your relay is misconfigured or something else goes wrong. Google > -## indexes this, so spammers might also collect it. > +## Administrative contact information for this relay or bridge. This line > +## can be used to contact you if your relay or bridge is misconfigured or > +## something else goes wrong. Note that we archive and publish all > +## descriptors containing these lines and that Google indexes them, so > +## spammers might also collect them. You may want to obscure the fact that > +## it's an email address and/or generate a new address for this purpose. > #ContactInfo Random Person <nobody AT example dot com> > ## You might also include your PGP or GPG fingerprint if you have one: > #ContactInfo 0xFFFFFFFF Random Person <nobody AT example dot com> Hi Nick, Karsten, You've just changed the torrc.sample.in file, which will cause everybody who uses the deb and upgrades from Tor 0.2.4.17-rc to have to manually evaluate/adjust/replace their /etc/tor/torrc file. Are you sure you want to do this? It's not the end of the world here since the torrc.sample was last updated for Tor 0.2.4.3-alpha, so people upgrading from 0.2.3.x debs will already be affected. But I wonder if it's really worth hassling every deb user who will be upgrading from 0.2.4.x? In any case we should update the ## Last updated 12 September 2012 for Tor 0.2.4.3-alpha. line at the top of the file, so we can accurately predict who will be affected by changes like this in the future. --Roger

3 3

Attentive Otter: Analysis of xmpp-client
by Jurre van Bergen 09 Oct '13

09 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hoi, Below you can find the analysis of xmpp-client for the Attentive otter project, written by dgoulet, nickm, arlo, asn and myself. All the best, Jurre - -------- Intro xmpp-client is a simple XMPP client written in pure Go with OTRv2 support. It's a terminal program but doesn't have a GUI or a UI like GTK or ncurses. The software should be considered in an alpha state. *Is traffic send over Tor?* Yes, xmpp-client has support for sending all traffic over Tor, this includes connecting to onion's. When you connect to jabber.ccc.de or the riseup.net jabber service, you are automatically connected over Tor through their onion address (hidden service), if Tor is running. SRC lookups are not proxied. *Chat network(s) support* Only basic XMPP support, no extensions are implemented (XEP - http://xmpp.org/xmpp-protocols/xmpp-extensions/) *How trivial is extending XMPP-Client to different protocols?* This code base is only for XMPP and seems quite hardcoded for that. Section "Instant Messaging" - https://code.google.com/p/go-wiki/wiki/Projects#Networking * XMPP in Go - https://github.com/mattn/go-xmpp * IRC in Go - https://github.com/husio/go-irc * Various Go bindings - http://go-lang.cat-v.org/library-bindings *OTR* OTR support comes from the Go crypto package: https://code.google.com/p/go.crypto/ This library only has support for OTRv2 and not the latest OTRv3 specification. If we want to be resistant to several attacks[1] on the OTR protocol, we need to reimplement the OTR protocol and update it to the latest version or, we use Cgo, which binds into libotr. (Open questions: OTR by default?, ) [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.165.7945&rep=rep1&… *What languages are supported?* Currently, there is only support for English, extending the client with other languages is rather trivial like Farsi, French, Spanish and Arabic. *_Graphical interface_* A graphical interface needs to be implemented for the client. However, there is only a limited amount of graphical interfaces available, all are far from stable to use. The best bet for now is Go-GTKand extend it and let fixes go upstream. Another thing we could do is implement or extend an existing minimal implementation of a QT library. This means however, that we would need to maintain an extra "third party" UI library, which isn't Tor's core "business". * QT: https://github.com/visualfc/go-ui * GTK: http://mattn.github.io/go-gtk/ * Webkit: https://github.com/mattn/go-webkit *_Operating System Support_* *Windows* * MSI package support - http://golang.org/doc/install#windows *Mac OS X* * Package exists for Go - http://golang.org/doc/install#osx *Linux* Packaged in most distributions. *_Build & build automation_* *Cross-platform* Go compiles into a static binary. Next to that, Go has the possibility to build cross-platform binaries. *Deterministic builds* Some hacking needs to be involved and having a deterministic binary for Go might prove more difficult. I'm unsure whether this is going to be easily implemented (more research needed) *Browser extention* Of what I can understand with Xullauncher, we can start any type of applications shipped in the "TBB sandbox" in a specific path. With xmpp-client, it would require a Go version that is shipped with the TBB and every other library we use (i.e. crypto.otr). (Not 100% sure here...). A fat binary is an option here also (Go + otr + xmpp-client). *Control mechanism* A control mechanism needs to be implemented so xmpp-client can interact with Firefox in some way or the other. *_Hardening_* *Building with hardenend compiler flags* Hardening is possible by using gccgo, which is a frontend to the GCC gnu compiler. * http://golang.org/doc/install/gccgo *Sandboxing* * There is an existing AppArmor profile for xmpp-client for Ubuntu 11.04+ * There isn't a Seatbelt OSX sandbox profile. * There isn't a way to sandbox in windows. - -- Developer at https://www.useotrproject.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJSUu2kAAoJELc5KWfqgB0CnNAH/2ZpvUgB/enkgMZ7tH4q1cj7 w0S9N5bRD21JSYHpd9ZhvMOIHUOVOm8fothUvB1HVFwLhTMqsnqB5vtOPe117WYX WDp9rwicKz110r1dyEDcDhkGnI0OKJ5trDDalmmFaeFaP7gTwedee8lNRBdV+bPs tEqSGIxtNbY7WUpDZvTUBxkqZjAgWsag4K+fcn3ZA0m1vUmyWpyV+xYXCvjJH6fo oDVirvXpQibQxZWSLnRceq7otNXI1TdZL60KiipPJNDyfi5g5d3pToo3CU61wJgF 0KtvtzYnG5l476aJhd1hCdfO7Ni3NoZ1dheqPsRGcmNp/kICqbRYnc9MDqiCpEM= =e6xQ -----END PGP SIGNATURE-----

9 10

RESPONSE REQUESTED: scheduling Otter-related outreach, training, documentation &c. kickoff [due wednesday]
by Tom Lowenthal 09 Oct '13

09 Oct '13

People of Earth, heed my call! Based on feedback that Boisterous Otters has too much to do, and on the fact that current Boisterous meetings are using their full time on only half the topics, we're splitting Boisterous into two components. The first component is going to stick with the name Boisterous, and deals with the first two activities: the helpdesk, and l10n. If you're already working on these things, nothing is changing for you, and you may be able to stop reading this right here. The second component is picking up the name **Buoyant**, and will deal with the remaining activities: * written materials on general communications security * short videos multi-language training videos * outreach to Iranians and the Iranian diaspora * social-media, radio, and television outreach. * training, and train-the-trainer work If that sounds like your cup of tea, kettle of fish, or flagon of ale, then you should come help us get started by filling in this [Doodle][] **by Wednesday afternoon** so that I can plan a meeting at the end of this week or the beginning of next. Please fill out the Doodle if you're definitely coming, and plan to be part of the core effort. If you just want to show up to spectate or lend a hand, there's no RSVP needed. I plan to look at the Doodle around 1700-1900h Pacific tomorrow, and I'll use whatever it says then to try and pick the best time. I'll send the time out to tor-dev, bcc-ing everyone who's expressed an interest or answered the poll. That's 24 hours to give me your availability, but only about 16 hours between when I send out the time and the first possible meeting slot, so check your mail tomorrow evening Pacific. If you have any specific suggestions about venue, format, or other running *of the meeting*, and you plan to be there, please reply publicly or privately before I send out the scheduling meeting. If you have specific plans about how to git'er done, you can either email me, or bcc me on a tor-dev-bound email with an appropriately-ottery subject line. Do note, however, that other folks may not be able to read your suggestions if you send them less than 12 hours before the meeting. I'll try to read them anyway, but that's only out of the kindness of my heart. Questions on a postcard please, -Tom [Doodle]: http://doodle.com/pm5cfunbcwuyrwh6

1 0

Status report - Stream-RTT
by ra 09 Oct '13

09 Oct '13

Hi all! During the last weeks I have been very busy working on my GSoC project which is about reducing the RTT of preemptively built circuits. There is now a single script called "rttprober"[0] that depends on a patched[1] Tor client running a certain configuration[2]. The goal is to measure RTTs of Tor circuits. It takes a few parameters as input: an authenticated Stem Tor controller for communication with the Tor client, the number of circuits to probe, the number of probes to be taken for each circuit and the number of circuits that should be probed concurrently. It outputs a tar file containing lzo-compressed serialized data with detailed node information, all circuit- and stream-events involved and the circuit build time for further analysis. Since the RTT-measurements are run in parallel with very short locks it is important not to overload Tor nodes. Therefore a single node is not probed more than once at a time. A first analysis of some measurements taken supports the original assumption that a Frechét distribution fits both the circuit build times[3] and round trip times[4]. I will continue gathering and analyzing measurement data and will hopefully be able to draw some conclusions from that. Best, Robert [0] https://bitbucket.org/ra_/tor- rtt/src/1127f6936086664981fc55b4dbc82b1570714140/rttprober.py?at=master [1] https://bitbucket.org/ra_/tor- rtt/src/1127f6936086664981fc55b4dbc82b1570714140/patches?at=master [2] https://bitbucket.org/ra_/tor- rtt/src/1127f6936086664981fc55b4dbc82b1570714140/torrc?at=master [3] http://postimg.org/image/je8k5yydt/ [4] http://postimg.org/image/ktk90vxm7/

3 9

Tor Beta area
by Phill Whiteside 09 Oct '13

09 Oct '13

Hi good people, I do run a relay [1], but with my work as Team Leader for lubuntu quality / testing [2] with our small, but dedicated, team I cannot allocate the time to install and test your RC. Instead, I put at your disposal a VM (kvm) with a dedicated ipV4 address running ubuntu server 12.04 LTS. This can be changed to what ever is best used for testing. I can take snapshots, so if you crash & burn it, it does not take too long to re-install. It also can pull full logs out out of a broken VM using guestfish[3] If this would be of use for you on alpha / beta testing relay software, please do get in touch. Regards, Phill. 1. https://metrics.torproject.org/relay-search.html?search=176.31.156.199 2. https://wiki.ubuntu.com/Lubuntu/Testing 3. http://irclogs.ubuntu.com/2013/06/28/%23ubuntu-classroom.html#t16:01 -- https://wiki.ubuntu.com/phillw

1 0

Fwd: [rt.torproject.org #14731] Off by one buffer overflow in tor stable
by Pedro Ribeiro 09 Oct '13

09 Oct '13

---------- Forwarded message ---------- From: Colin Childs via RT <help(a)rt.torproject.org> Date: 7 October 2013 14:25 Subject: [rt.torproject.org #14731] Off by one buffer overflow in tor stable To: pedrib(a)gmail.com On Mon Oct 07 12:13:21 2013, pedrib(a)gmail.com wrote: > Hi, > > I think there is a small buffer overflow (off by one) in the current stable > version of tor. > The function in question is format_helper_exit_status, which returns a > formatted hex string. It is in common/util.c, starting at line 3270. > The function has a comment header that explains how it works. It > specifically says it returns a string that is not null terminated, but > instead terminates with a newline. > > The code checks periodically throughout the function whether it has written > more bytes than it should. If it does, it errors out and writes a null > character in the current character positions. This by itself can lead to a > buffer overflow, but I believe the checks ensure that it almost never > writes over the buffer size - except in one case. > > After it has finished everything, it then checks again if there are more > than 0 bytes left in the buffer. If there are, it writes two characters - a > newline and a null terminator (lines 3342 to 3347). > > The problem here is if the buffer only has one byte left, an off by one > overflow occurs. These usually are very hard to exploit, but can be a > security issue nonetheless. > > However given that I am not familiar with the tor codebase I might be > wrong? I also did a quick security audit on the rest of the tor code and > couldn't find anything else. I was inspire because of the recent events... > > Regards > Pedro Hello, Please send a copy of this email to our tor-dev mailing list at https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev. Thank you! -- Colin C. ------------------------------------------- Hi, Please find above a bug report with possible security implications. I was a bit weary of sending to a public list at first, but I doubt the bug above is exploitable. Regards Pedro

2 2

REMINDER: Boisterous Otter helpdesk/l10n meeting in 2h, at 1200 Pacific
by Tom Lowenthal 08 Oct '13

08 Oct '13

Hello all, This is your irregularly-scheduled reminder that we will be discussing the Helpdesk and translation in just a smidge over two hours (that's 1200h pacific) in #tor-dev on irc.oftc.net. Highlights will include hearing from Sherief, Lunar, and Phoul about their research into ways to provide support chat accessible through our website. We'll also make a preliminary incursion into the topic of organizing shifts at predictable times. How very exciting! Other developments: I'm going to slice and dice Boisterous into two separate components which we'll run in parallel, otherwise these discussions and whatnot are going to run forever each. In this track, we'll continue with helpdesk and l10n. The other track will focus on outreach, training, videos, and documentation. If you're mainly in it for the helpdesk/l10n, you have nothing further to do: your meetings are just shorter. If you're interested in outreach, training, videos, and documentation, (and I already know that Kelley, Karen, Runa, and Sherief might be), then look for the meeting-scheduling message to go out to tor-dev, probably today. If you drop me a line, then I'll try to do something clever to make sure that the message hits your inbox too. That's all from this reminder. Any questions, folks? -Tom

1 0

CPAProxy - a thin Objective-C wrapper around Tor
by Claudiu-Vlad Ursache 08 Oct '13

08 Oct '13

Hi everyone, For those of you interested in making Tor available on iOS, I've recently released CPAProxy, a thin Objective-C wrapper around Tor ( https://github.com/ursachec/CPAProxy) The goal of the project is to release a free open-source browser on the AppStore that uses this wrapper and Tor to anonymize requests. It works by starting an instance of the Tor client in a background thread of an iOS app's main process. CPAProxy connects a socket to the client's control port, send an authenticate message and asks for the bootstrap progress until it reaches 100%. When the bootstrapping is done, the app is notified that Tor's SOCKS proxy is ready to be used. From that point on, networking requests can be sent over the proxy using Apple's iOS networking classes. The github repository contains two packet traces from a test app using CPAProxy of what traffic for an HTTP request looks like when it's sent over Tor and when in plain. The repo also contains build scripts that ease the compilation of openssl, libevent and Tor for iOS without changing anything in the "normal" build process except for removing _NSGetEnviron() and ptrace() calls in src/common/compat.c, since they're are not available on the iPhone. Each of the libraries are statically linked into the application binary. Before continuing with the endeavor of releasing a browser, it would help to know if there are people who think that it's not a totally bad idea to release software that uses Tor on a closed platform and to get some feedback on what security considerations are of high importance. Some open questions I'm still looking answers for: - What webkit features have to be disabled in order to keep anonymity intact while displaying web content? - Apple's networking classes provide ephemeral in-memory URL Sessions ( NSURLSessionConfiguration<https://developer.apple.com/library/ios/documentation/cocoa/Conceptual/URLL…>). Can those be trusted or should equivalent classes be written from scratch? - CPAProxy sets up Tor's DataDir in a temporary directory of an app's sandbox where it's not accessible by other processes. Should that directory be protected in any other way? - What is a good way of analyzing packet captures from an app using CPAProxy and Tor to see if any information leaks? If there's anyone with opinions on the project, it would really help to hear them. On #tor-dev I'm ursachec. All best from Hamburg, Claudiu -- Claudiu-Vlad Ursache Homepage: cvursache.com Phone number: +49 152 554 08 409 Address: Lange Reihe 113, 20099 Hamburg

2 1

Re: [tor-dev] Project *Cute* - draft design and challenges
by SiNA Rabbani 08 Oct '13

08 Oct '13

Resending to tor-dev with correct email address. Sorry to those receiving 2 copies. On Oct 8, 2013 2:02 AM, "SiNA Rabbani" <sina(a)redteam.io> wrote: > Dear Team, > > I have started on a draft design document for Project cute. > Please let me have your kind comments and suggestions. > (https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Cute) > > All the best, > SiNA > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > "Cute" design and challenges - draft 0.1 > By: SiNA Rabbani - sina redteam io > > > *Overview* > > Project Cute is part of the Otter contract. This project is to provide > (in the parlance of our time) "point-click-publish" hidden services to > support > more effective documenting and analysis of information and evidence > documenting > of ongoing human rights violations and corresponding training and advocacy > Our > goal is to improve hidden services so that they're more awesome, and to > create > a packaged hidden-service blogging platform which is easy for users to run. > > *Objective* > > To make secure publishing available to activists who are not IT > professionals. > > *Activities* > > Tor offers Hidden Services, the ability to host web sites in the Tor > Network. > Deploying hidden services successfully requires the ability to configure a > server securely. Mistakes in setup can be used to unmask site admins and > the > location of the server. Automating this process will reduce user error. > We have to write "point-click-publish" plugins that work with existing > blogging > and micro-blogging software. > > *Expected results* > > The result will be a way to provide portals to submit text, pictures, and > video. > These sites will not have the ability to log information that can be used > to > track down citizen journalists or other users, and will be resistant to > distributed denial of service (DDoS) attacks. > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > *Introduction* > > This document describes the technical risks associated with running a > web-based > blog tool and exposing it over a hidden service (.onion address). Our goal > is to > create a packaged blogging platform that is easy to operate for the > non-technical user, while protecting the application from a set of known > attacks > that can reveal and compromise the network identity. > > Hidden-services make it possible for content providers and citizen > journalists to offer web-applications such as blogs and websites, hosted > completely behind a firewall (NAT Network) never revealing the public IP > of such > services. By design, Hidden Services are resilient to attacks such as > traffic > analysis and DDoS, therefore it becomes compelling for the adversary to > focus > on the application layer vulnerabilities. > > According to OWASP Top 10, Injection is the number one security risk for > web applications. "Injection flaws, such as SQL, OS, and LDAP injection > occur > when untrusted data is sent to an interpreter as part of a command or > query. > The attacker?s hostile data can trick the interpreter into executing > unintended commands or accessing data without proper authorization." [1] > > > Running a site such as WordPress involves a LAMP (Linux, Apache, Mysql, > PHP) > installation. This stack needs to be carefully configured and implemented > to > meet the desired privacy and security requirements. However, default > configuration files are not suitable for privacy and lead to the leakage of > identity. > > WordPress is the most popular blog platform on the Internet. We select > WordPress > due to it's popular and active core development. WordPress features a > plug-in > architecture and a template system, "Plugins can extend WordPress > to do almost anything you can imagine. In the directory you > can find, download, rate, and comment on all the best plugins the > WordPress community has to offer." http://wordpress.org/plugins/ > > Themes and plugins are mostly developed by programmers with little or no > security in mind. New code is easily added to the site without the need > for any > programming skills. This is recipe for disaster, a quick look at the > publicly > available plugin repository and security forums reveals many of the OWASP > top 10 > vulnerabilities such as XSS and injection vulnerabilities: > > http://packetstormsecurity.com/search/?q=wordpress > http://wordpress.org/plugins/ > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > *Adversary Model* > > We use the range of attacks available to the adversary adversary as the > base for > our Threat Model and proposed requirements. > > > *Adversary Goals* > > *Code Injection* > This is the most direct compromise that can take place; the > ability for > the adversary to execute code on the host machine is disastrous. > > *XSS the front-end, DoS the back-end* > The adversary can overwhelm the database backed or the web-server > of a > dynamically hosted application, denying access to the service. > > *Location/Identity information* > Applications that are not designed with privacy in mind tend to > reveal > information by default. For example, WordPress includes the name > of the > editor of a post inside the RSS feed: <dc:creator>John > Smith</dc:creator> > > *Adversary Capabilities - Positioning* > > The adversary can position themselves at a number of places to execute > their > attacks. > > *Local Network/ISP/Upstream Provider* > The attacker can hijack the DNS of the plugin repository or > perform a > man-in-the-middle attack and push malicious code into the blog. > > *Third party service providers* > It is common for a blog to email authentication information. > This information is at risk of social and legal attacks. > The repository of the blog's source code where themes and plugins > are > downloaded is a target for the adversary to insert malicious code. > > > *Adversary Capabilities - Attacks* > > The adversary can perform the following attacks in order to accomplish > varies > aspects of their goals. Most of these attacks are due to the dynamic and > Web 2.0 nature of blog platforms. > > *SQL Injection & XSS* > Dynamic sites take advantage of databases for content storage and > JavaSript for client-side presentation. Programming mistakes can > lead to > code injection on server or client side. > > *Inserting plugins or core updates* > Blog platforms have automatic update install features, WordPress > connects to a remote repositories to download updated code. > Adversary can perform a man-in-the-middle attack and insert > malicious > code. > > *Misbehaving plugins/features* > Some plugins depend on remote connections to provide a feature, > for e which can lead to leakage of identity. > > *Brute-force the admin password* > Weak passwords are vulnerable to brute-force attacks. > Blog engines do not provide protection against such attacks. > > *Remotely exploiting the LAMP stack* > A determined adversary has a very large attack surface to analyze > and discover 0-day vulnerabilities in Apache, PHP or Mysql > applications. > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > *Proposed requirement* > > *Dynamic to Static* > A simple yet effective way to protect dynamic websites is to save > a 100% > static copy, hosted with a lightweight and well configured http > server. > We propose Nginx which is a free, open-source, high-performance > HTTP server. We have the option of extending existing WordPress > plugins > such as "Really-Static" (HTTP://wordpress.or/plugins/really-static/) to > generate 100% static files. > > *Disable Comments and New User signup (POST REQUESTS)* > The ability to receive and store comments involves actions and > configurations that expose the installation to DoS and other web > attacks. > We propose to completely disable reader's backed interactions, > specifically disabling New User Registration and Comment features. > > *SOCKS Proxy support for WordPress* > WordPress has the ability to proxy its outgoing connections, > however the > current implementation only supports HTTP proxy. We propose to > submit a > patch to WordPress core, enabling SOCKS Proxy support: > > http://core.trac.wordpress.org/browser/tags/3.6.1/wp-includes/class-http.php > > *Update safety* > Tor Project or a partner such as WordPress.org should maintain the > latest > copy of the WordPress source-code over a .onion address. This will > allow > for the Core application updates to take place without ever > leaving the > Tor network and we achieve end-to-end encryption without relying > on the > traditional SSL/CA model. > > *OnionPress plugin* > Instead of hard-coding our modifications to control WordPress' > functionalities, we propose to develop a custom plugin. > The plugin will provide a new menu in the Administrative panel of > the > site. Providing options to interact with Hidden Service features. > (Note that Administrative features are going to be restricted from > the public and only available to localhost) > > *User Authentication/Permission Levels* > > a) Blog Administrator > This person is hosting the blog on a local computer and > has physical > access to the installation. There is only 1 of such role. > This > login will be restricted to localhost only. > > b) Blog editors/contributors > These are the active content publishers. Each person has > the ability > to remotely connect, login and publish content. Editors do > not have > any administrative permissions such as adding or deleting > users. > Each editor is assigned a dedicated key and .onion > hostname using > the HidServAuth and HiddenServiceAuthorizeClient features > in > stealth mode. > > "HiddenServiceAuthorizeClient auth-type > client-name,client-name,… > If configured, the hidden service is accessible for > authorized > clients only. The auth-type can either be 'basic' for a > general-purpose authorization protocol or 'stealth' for a > less > scalable protocol that also hides service activity from > unauthorized clients. Only clients that are listed here are > authorized to access the hidden service. Valid client names > are 1 to 19 characters long and only use characters in > A-Za-z0-9+-_ (no spaces). If this option is set, the hidden > service is not accessible for clients without authorization > any more. Generated authorization data can be found in the > hostname file. Clients need to put this authorization data > in their configuration file using HidServAuth." > > c) Readers (the world) > These are the site visitors, they will be able to send GET > requests > to the .onion address and receive HTML and multimedia > content. > No login or comment posting permissions granted. > > *Packaged System* > > We propose to design and develop a Debian based Live OS that can > be started as a Virtual Machine or to boot a personal computer. > This OS > will include Tor, LAMP stack and a running copy of WordPress. > > The LAMP installation will be hardened and configured to meet our > security desires. We require a secondary USB disk for persistent > storage. > Desired outcome is a point-and-click and maybe portable solution > that > can be launched from inside of Windows, Linux or Mac OSX. > > VirtualBox is a second candidate to host the VM. > http://wiki.qemu.org/Main_Page and/or https://www.virtualbox.org/ > > > *Edge Cache Nodes* > > In order to provide "blazing-fast" access to the published content > outside of the Tor network, we propose the deployment of caching > servers > operated by semi-trusted third party organizations or persons. > These are > similar to tor2web nodes:http://tor2web.or/ > > The content providers (bloggers) would select from a list of > available > edge servers and send a pgp signed zip file of the latest static > version > over Tor. Edge servers will reduce traffic from the Tor network, > also > provide a chance for content to reach the world in case of a DDoS > or > technical issues with the Tor network itself. > > Having cached copies available remotely make it possible for the > blogger > to get on-line, publish content and go back off-line, minimizing > the > amount of time and traffic spent on the Internet. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >

1 0

Attentive Otter: Analysis of libpurple
by Thijs Alkemade 07 Oct '13

07 Oct '13

Hello! Here is the analysis of libpurple/Pidgin as a candidate for the Attentive Otter project, written by DrWhax and me. Best regards, Thijs (xnyhps) ----- ## Intro Pidgin is an IM client written in C using a GTK+ UI. libpurple is the library used by Pidgin as an abstraction for the different network protocols Pidgin supports. libpurple comes with a number of plugins ("prpls") for the various chat networks it supports. Other UIs using libpurple include Adium (Cocoa), Finch (GNT) and Quail (Qt, in development). ## Release a secure, portable chat program ### Secure Number of security advisories published on https://pidgin.im/news/security/ since 2005-06-10: * libpurple: 6 * nss plugin: 1 * Pidgin: 3 * prpl-gg: 1 * prpl-irc: 2 * prpl-jabber: 7 * prpl-msn: 15 * prpl-mxit: 3 * prpl-oscar (AIM/ICQ): 6 * prpl-qq: (no longer supported) 1 * prpl-sametime: 1 * prpl-silc: 2 * prpl-yahoo: 3 My (xnyhps) personal experience is that the Pidgin developers take reported security issues very seriously and often come up with a fix quickly. However, it does sometimes take a while before they release and deploy that fix. I don't have enough experience with Pidgin (the GTK+ UI) to judge its code quality, but I think the quality of libpurple itself is decent. The quality of prpls varies a lot, generally the reverse-engineered protocols are in worse shape than those with open specifications. I think MSN is definitely the worst and auditing it would take more time than the servers will be online for (until March 2014). I think auditing jabber+irc should be doable and would be a good start: IRC is quite small (>5kloc), XMPP (28kloc) has clear specifications and by using UTF-8 and XML it removes a lot of possible buffer overflow and string manipulation vulnerabilities. DrWhax's personal experience is that Pidgin developers don't always take security issues seriously. In the summer of 2012 I spent a night digging with Jake into the source code and DLL's that they ship and we found out that in 2012, they were shipping vulnerable DLL's with the oldest exploit originating from 2006! It took quite some convincing that this is a serious matter and we had to convince(sigh) the Pidgin folks to update all the DLL's to the latest version. In February 2013, Pidgin finally released a security update which fixed 12 security bugs? I would say, if we would want to go forward with releasing a minimal Pidgin, we should only ship with IRC and XMPP support. ### Portable Pidgin provides official instructions on how to run Pidgin from an USB stick: https://developer.pidgin.im/wiki/Using%20Pidgin#RunningWindowsPidginFromaUS…. ## Sends all traffic over Tor libpurple has a proxy setting that will force all traffic to pass through Tor. This disables all SRV lookups, meaning many XMPP servers require manual configuration to work. UPnP (used for automatic port fowarding and external IP detection) can be disabled globally. ## Can be used with a wide variety of chat networks libpurple includes support for: * AIM * Bonjour * Gadu-Gadu * Google Talk * Groupwise * ICQ * IRC * MSN * MXit * MySpaceIM * SILC * SIMPLE * Sametime * XMPP * Yahoo! * Zephyr Though nearly everyone of these is a separate prpl, so would require its own auditing. ## Uses off-the-record encryption of conversations by default The Pidgin-OTR plugin can be configured to enable OTR by default. Including this plugin with Pidgin by default is underway. ## Has an easy-to-use graphical user interface localized into Farsi, French, Spanish, and Arabic. It has a graphical user interface which a large number of users might already be familiar with. From https://developer.pidgin.im/l10n/2.x.y/: * Farsi: 59.77% finished. * French: 98.95% finished. * Spanish: 99.31% finished. * Arabic: 78.02% finished. This breakdown includes all prpls, so might turn out differently when only including a subset of them. ## Cross-platform support Pidgin ships binaries for Windows and Linux. By packaging GTK+, it should be possible to package it to run on OSX too, though the UI would be quite confusing to many OSX users. Another option on OS X is Adium, though this increases the amount of code to be audited by a large factor. ## Integration with Tor libpurple supports plugins written in C, Tcl, Perl and C# (Mono). These can make changes to the preferences to automate configuring it for Tor. It is also possible to configure Pidgin using D-Bus, but for security reasons it is probably wiser to disable D-Bus support. So the options to control Tor are: * A C/Tcl/Perl/C# plugin that launches a Tor process and which sets up Pidgin's preferences accordingly. * Use Tor Launcher from the TBB to start both Tor and Pidgin. Configuring Pidgin could happen by: * Writing to the preference files before starting it. * Communicating the preference changes to a simple C/Tcl/Perl/C# plugin. * D-Bus. (Unlikely to work on Windows and difficult to secure) ## Pidgin 3.0 Pidgin 3.0.x will be released with OTR support by default, which is awesome, only one codebase has to be maintained in the various Linux distributions and Windows clients! Huzzay! Something i'm less happy with, is that the Pidgin developers started using Webkit for HTML rendering within the client. Webkit doesn't have a very good security history and opens up with another giant security hole. If we would want to release Pidgin inside of TIMBB, I would propose to work on Pidgin 3.0 and not the older 2.x releases.

1 0