tor-dev

tor-dev@lists.torproject.org

3581 discussions

Re: [tor-dev] [tor-announce] Tor 0.2.2.35 is released (security patches)
by Fabio Pietrosanti (naif) 17 Dec '11

17 Dec '11

Should we think to have all tor-users that run a version minor than X, go automatically off-the-network? I mean, if we have let's say 10% of outdated users, it means that 10% of the network can be compromised with a single remote exploit. I mean, running a Tor node today it's a responsibility. If a node maintainer it not going to update within a possibly defined grace period, it should imho get kicked-out from the network. Has been this concept already considered somehow? I mean, at least if a node is not updated for example, it would never be able to achieve a certain "status" or functionalities. For example never become a Guard node or never became an Exit Node? -naif On 12/16/11 7:19 PM, Roger Dingledine wrote: > Tor 0.2.2.35 fixes a critical heap-overflow security issue in Tor's > buffers code. Absolutely everybody should upgrade. > > The bug relied on an incorrect calculation when making data continuous > in one of our IO buffers, if the first chunk of the buffer was > misaligned by just the wrong amount. The miscalculation would allow an > attacker to overflow a piece of heap-allocated memory. To mount this > attack, the attacker would need to either open a SOCKS connection to > Tor's SocksPort (usually restricted to localhost), or target a Tor > instance configured to make its connections through a SOCKS proxy > (which Tor does not do by default). > > Good security practice requires that all heap-overflow bugs should be > presumed to be exploitable until proven otherwise, so we are treating > this as a potential code execution attack. Please upgrade immediately! > This bug does not affect bufferevents-based builds of Tor. Special > thanks to "Vektor" for reporting this issue to us! > > Tor 0.2.2.35 also fixes several bugs in previous versions, including > crash bugs for unusual configurations, and a long-term bug that > would prevent Tor from starting on Windows machines with draconian > AV software. > > With this release, we remind everyone that 0.2.0.x has reached its > formal end-of-life. Those Tor versions have many known flaws, and > nobody should be using them. You should upgrade -- ideally to the > 0.2.2.x series. If you're using a Linux or BSD and its packages are > obsolete, stop using those packages and upgrade anyway. > > The Tor 0.2.1.x series is also approaching its end-of-life: it will no > longer receive support after some time in early 2012. > > https://www.torproject.org/download/download > > Note that the tarball and git tags are signed by Nick Mathewson (gpg > key 165733EA) this time around. > > Changes in version 0.2.2.35 - 2011-12-16 > o Major bugfixes: > - Fix a heap overflow bug that could occur when trying to pull > data into the first chunk of a buffer, when that chunk had > already had some data drained from it. Fixes CVE-2011-2778; > bugfix on 0.2.0.16-alpha. Reported by "Vektor". > - Initialize Libevent with the EVENT_BASE_FLAG_NOLOCK flag enabled, so > that it doesn't attempt to allocate a socketpair. This could cause > some problems on Windows systems with overzealous firewalls. Fix for > bug 4457; workaround for Libevent versions 2.0.1-alpha through > 2.0.15-stable. > - If we mark an OR connection for close based on a cell we process, > don't process any further cells on it. We already avoid further > reads on marked-for-close connections, but now we also discard the > cells we'd already read. Fixes bug 4299; bugfix on 0.2.0.10-alpha, > which was the first version where we might mark a connection for > close based on processing a cell on it. > - Correctly sanity-check that we don't underflow on a memory > allocation (and then assert) for hidden service introduction > point decryption. Bug discovered by Dan Rosenberg. Fixes bug 4410; > bugfix on 0.2.1.5-alpha. > - Fix a memory leak when we check whether a hidden service > descriptor has any usable introduction points left. Fixes bug > 4424. Bugfix on 0.2.2.25-alpha. > - Don't crash when we're running as a relay and don't have a GeoIP > file. Bugfix on 0.2.2.34; fixes bug 4340. This backports a fix > we've had in the 0.2.3.x branch already. > - When running as a client, do not print a misleading (and plain > wrong) log message that we're collecting "directory request" > statistics: clients don't collect statistics. Also don't create a > useless (because empty) stats file in the stats/ directory. Fixes > bug 4353; bugfix on 0.2.2.34. > > o Minor bugfixes: > - Detect failure to initialize Libevent. This fix provides better > detection for future instances of bug 4457. > - Avoid frequent calls to the fairly expensive cull_wedged_cpuworkers > function. This was eating up hideously large amounts of time on some > busy servers. Fixes bug 4518; bugfix on 0.0.9.8. > - Resolve an integer overflow bug in smartlist_ensure_capacity(). > Fixes bug 4230; bugfix on Tor 0.1.0.1-rc. Based on a patch by > Mansour Moufid. > - Don't warn about unused log_mutex in log.c when building with > --disable-threads using a recent GCC. Fixes bug 4437; bugfix on > 0.1.0.6-rc which introduced --disable-threads. > - When configuring, starting, or stopping an NT service, stop > immediately after the service configuration attempt has succeeded > or failed. Fixes bug 3963; bugfix on 0.2.0.7-alpha. > - When sending a NETINFO cell, include the original address > received for the other side, not its canonical address. Found > by "troll_un"; fixes bug 4349; bugfix on 0.2.0.10-alpha. > - Fix a typo in a hibernation-related log message. Fixes bug 4331; > bugfix on 0.2.2.23-alpha; found by "tmpname0901". > - Fix a memory leak in launch_direct_bridge_descriptor_fetch() that > occurred when a client tried to fetch a descriptor for a bridge > in ExcludeNodes. Fixes bug 4383; bugfix on 0.2.2.25-alpha. > - Backport fixes for a pair of compilation warnings on Windows. > Fixes bug 4521; bugfix on 0.2.2.28-beta and on 0.2.2.29-beta. > - If we had ever tried to call tor_addr_to_str on an address of > unknown type, we would have done a strdup on an uninitialized > buffer. Now we won't. Fixes bug 4529; bugfix on 0.2.1.3-alpha. > Reported by "troll_un". > - Correctly detect and handle transient lookup failures from > tor_addr_lookup. Fixes bug 4530; bugfix on 0.2.1.5-alpha. > Reported by "troll_un". > - Fix null-pointer access that could occur if TLS allocation failed. > Fixes bug 4531; bugfix on 0.2.0.20-rc. Found by "troll_un". > - Use tor_socket_t type for listener argument to accept(). Fixes bug > 4535; bugfix on 0.2.2.28-beta. Found by "troll_un". > > o Minor features: > - Add two new config options for directory authorities: > AuthDirFastGuarantee sets a bandwidth threshold for guaranteeing the > Fast flag, and AuthDirGuardBWGuarantee sets a bandwidth threshold > that is always sufficient to satisfy the bandwidth requirement for > the Guard flag. Now it will be easier for researchers to simulate > Tor networks with different values. Resolves ticket 4484. > - When Tor ignores a hidden service specified in its configuration, > include the hidden service's directory in the warning message. > Previously, we would only tell the user that some hidden service > was ignored. Bugfix on 0.0.6; fixes bug 4426. > - Update to the December 6 2011 Maxmind GeoLite Country database. > > o Packaging changes: > - Make it easier to automate expert package builds on Windows, > by removing an absolute path from makensis.exe command. > > > > > _______________________________________________ > tor-announce mailing list > tor-announce(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-announce

1 0

BridgeDB IPv6 Support (!)
by Aaron 17 Dec '11

17 Dec '11

code is here: https://gitweb.torproject.org/user/aagbsn/bridgedb.git/shortlog/refs/heads/… running code is here: https://tor.extc.org/ and here (ipv6): https://tor.extc.org/ipv6 None of the bridges at these addresses are valid, except by coincidence. Any feedback or questions are very welcome. Thanks! --Aaron

1 0

Draft Proposal for BridgeDB IPv6 Support
by Aaron 17 Dec '11

17 Dec '11

Attached is a draft document describing proposed changes to BridgeDB to accommodate the new or-address spec (186-multiple-orports.txt) and IPv6 bridges. I am especially interested in comments on sections tagged #XXX. Thanks! --Aaron

4 5

Tor on TV (hemm, on WDTV!)
by Fabio Pietrosanti (naif) 15 Dec '11

15 Dec '11

Hi all, i got a WDTV Live (http://support.wdc.com/product/install.asp?groupid=1003&lang=en) that's part of bigger family of consumer mediaplayer from Western Digital (http://support.wdc.com/product/install.asp?level1=10&lang=en). It seems it can run Tor without any major issue. There is a very nice hacked firmware community around WDTV users, that's a very cheap hardware (retail price 70-80EUR). What's about making a "promotional" campaign like for the Tor Cloud to have people running Tor Relay "right on their TV" ? I mean, the "hacked firmware" installation process of WDTV works that way: - Plug an USB Key formatted FAT32 with 3 files (boot, kernel, image) on WDTV - Poweron So it may be possible to make a campaign where users are invited to "run their tor relay" on their TV in 3 simple steps: - Get a USB Key - Load that files on it - Plug to your WDTV - Poweron your WDTV You are now helping poor sirian, iranian and chinese censored people. That way even the average fat guy sitting on his couch drinking beer and eating wing chicken can support freedom of speech. That kind of user can just "poweron" the WDTV and with his "remote control" after seeing his favorite telefilm on paytv, can just "zap" to see how his Tor Router is working: On TV! This could be defined as the "very lazy Tor user" who doesn't even want to use a computer, but just do TV zapping :P So, the idea could be to do a custom hacked firmware of WDTV and a WDTV Apps that you can "click" via remote control, seeing the statistics of your Tor Relay. # uname -a Linux WDTVLIVE 2.6.22.19-19-4 #28 PREEMPT Mon Mar 22 20:08:14 CST 2010 mips GNU/Linux # tor --version Jan 01 15:41:37.533 [notice] Tor v0.2.2.32 (git-877e17749725ab88). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux mips) Tor version 0.2.2.32 (git-877e17749725ab88). # free total used free shared buffers Mem: 199056 193664 5392 0 10832 Swap: 0 0 0 Total: 199056 193664 5392 # cat /proc/cpuinfo system type : Sigma Designs TangoX processor : 0 cpu model : MIPS 24K V7.12 FPU V0.0 Initial BogoMIPS : 332.59 wait instruction : yes microsecond timers : yes tlb_entries : 32 extra interrupt vector : yes hardware watchpoint : yes ASEs implemented : mips16 shadow register sets : 1 VCED exceptions : not available VCEI exceptions : not available System bus frequency : 333000000 Hz CPU frequency : 499500000 Hz DSP frequency : 333000000 Hz -naif

4 6

Two questions about dir-spec.txt
by Karsten Loesing 14 Dec '11

14 Dec '11

Hi Nick, as the subject says, two quick questions about dir-spec.txt: 1. The "s" lines of network status entries are specified as: "s" SP Flags NL Now, when a relay has no flags at all, which can happen in a vote or could happen in older consensus methods, that relay would have an "s" line just consisting of "s", not "s ". I think it makes sense to omit the SP, but should this be specified? If so, how? There are other lines where it's not specified whether a trailing SP is permitted or not. But I think I only encountered "s" lines without any list elements so far. (I ran into problems here a while ago, when I looked for lines starting with "s " to overwrite an sLine string variable. But there was no "s " line for some relays, so the program used the "s " line from the previous relay. Went unnoticed. Ugh.) 2. The "m" lines in votes are not in dir-spec.txt. I haven't looked at proposal 158 yet. Is that proposal up-to-date? Thanks, Karsten

2 1

Purpose Controller Bug
by Tarik Karaoglu 14 Dec '11

14 Dec '11

Hi, I am trying to create circuits for use of my controller application however I got the following warning after my unsuccessful attempt. Dec 14 02:43:35.239 [warn] circuit_launch_by_extend_info(): Bug: unexpected purpose 19 when cannibalizing a circ. If I don't specify any purpose, I am able to create general purpose circuits. Another problem is that, is there a way to tell Tor to use separate circuits for each flow if possible when Tor attaches streams to circuits? Currently I am trying to attach streams to circuits using my controller but I am facing Proxy timeout issues like below: Dec 14 02:45:35.690 [notice] Tried for 120 seconds to get a connection to [scrubbed]:40000. Giving up. (waiting for controller) Any help will be appreciated. Thanks, Tarik

1 0

How to try out the new shiny IPv6 bridge support
by Linus Nordberg 13 Dec '11

13 Dec '11

Hi, With great help from Jeroen Massars address independence patch posted to this list earlier this year, a first milestone of IPv6 support in tor was reached in the 0.2.3.9-alpha release. Clients can now connect to private bridges over IPv6 if configured for that. If you are at all interested in trying out the new IPv6 support, this short HOWTO is for you. Please note that this is new code. Be prepared to run into bugs, hunt them down, report them, help out solve them and earn eternal fame and glory. It's a pain, but someone's got to do it. As part of proposal 186 ("Multiple addresses for one OR or bridge"), the ORPort configuration option has changed and ORListenAddress will be deprecated. We can use this for adding an IPv6 address to a bridge already running on an IPv4 address. (Another option is to run a bridge listening _only_ to IPv6 but note that every relay need IPv4 too, in order to speak to other OR's in the Tor network.) In order to configure a bridge to listen to an IPv6 address, add an ORPort option with an IPv6 address within square brackets and a port number like this: ORPort [2001:DB8::42]:4711 In order to have your client connect to a bridge over IPv6, simply state the address of the bridge within square brackets and a port number in a Bridge line: Bridge [2001:DB8::42]:4711 Note that there's still no support for IPv6 in BridgeDB. There is no harm in specifying PublishServerDescriptor 1 but nothing good will come out of it. You will have to find other ways of getting your bridge addresses to your users. Note also that if you configure your client with two (or more) addresses belonging to the very same bridge, your client will pick one of them and try to use that. This behaviour is not perfect and will change in future versions of tor. This behaviour isn't even bug free and should not be counted on -- especially when an IPv6 address is preferred over an IPv4 address, in which case the IPv4 address in many cases is the one being used anyway. Short story: Don't configure your client with more than one address per bridge. Please let me know if there are any questions about this and if you run in to any trouble setting it up. Then, when you run into the bugs, please go to https://trac.torproject.org/ and fire away. Thanks, Linus

1 0

Uploading video over Orbot
by Nathan Freitas 11 Dec '11

11 Dec '11

Some progress to share on Tor-related efforts with our Secure Smart Cam project with WITNESS. (More here: https://guardianproject.info/apps/securecam/ ) I know that "uploading HD video over a mobile network on Tor" has long been one of these cringe-inducing requests from NGOs, but at least for short clips, it seems to be working fairly well, both to YouTube and to the self-hostabled Videobin.org software. SSCXfer is my reduction of the Vidiom.mobi (http://vidiom.mobi/) app to be a focused, clean secure video uploader for YouTube and the self-hostable videobin.org software. Vidiom is pretty fantastic, but is a bit too kitchen sink, and also included features like FTP and Facebook upload which I don't feel comfortable putting a "secure" stamp on. The YouTube upload code comes from the very interesting "YouTube Direct" project's Android client: http://code.google.com/p/ytd-android/ The basic user story for SSCXfer is: "Alice has sensitive video evidence of a human rights crime recorded on her smartphone and wants to upload it to YouTube, but is in a country where YouTube is often blocked, and always monitored." a more complex one is: "Bob is a trained human rights defender working in a restrictive region, using his smartphone to interview victims about their experiences, and he needs to safely offload the videos from his phone to a secure private site as soon as possible, without raising any flags in the internet monitor systems." In this case "secure" and "safe", mean it will 1) use HTTPS as available, 2) store any local data in SQLCipher, and 3) support upload over proxy servers, specifically Orbot's built-in SOCKS or HTTP proxy without requiring root. In addition, the uploader must support low-bw, high latency connections, and support resumeable uploads. Finally, since videobin.org can be self-hosted, it is possible that a server could be run by WITNESS or any organization on a Tor hidden service .onion address, or at least on their own, https site. At this point, I've implemented support for Orbot/Tor working by enabling HTTP proxying support in all the HTTP connection code, and it is working quite well for both uploads to YouTube and the default Videobin.org site instance. Resume and retry seem to work, but I have not done extensive testing. I think the most extreme test scenario is uploading over Tor over EDGE network, and then going up and down into the subway. We'll see how we do in that case. Best, Nathan

1 1

AES_ctr128_encrypt() on Windows
by Gisle Vanem 07 Dec '11

07 Dec '11

Seems that this function isn't available in OpenSSL 1.1.0. On Windows at least. The function is enclosed in a "#if 0" in OpenSSL's <aes.h> and util/libeay.num also has this: AES_ctr128_encrypt 3216 NOEXIST::FUNCTION: So should we make an exception for Windows in common/aes.c: --- Git-latest/src/common/aes.c Mon Dec 05 16:54:55 2011 +++ src/common/aes.c Wed Dec 07 18:42:37 2011 @@ -17,7 +17,7 @@ #include <openssl/aes.h> #include <openssl/evp.h> #include <openssl/engine.h> -#if OPENSSL_VERSION_NUMBER >= 0x10000000L +#if (OPENSSL_VERSION_NUMBER >= 0x10000000L) && !defined(MS_WINDOWS) /* See comments about which counter mode implementation to use below. */ #include <openssl/modes.h> #define USE_OPENSSL_CTR --gv

2 2

Reduce TBB/OSX from 32MB to 23MB
by Fabio Pietrosanti (naif) 06 Dec '11

06 Dec '11

Hi all, made the following tricks that you can find attached to reduce the size of TBB/OSX from 32MB to 23MB . With this tricks it's possible to send TBB/OSX via Gmail using Gettor. It goes from: 32M /tmp/TorBrowser-2.2.34-3-dev-osx-x86_64-en-US.zip to 23M /tmp/TorBrowser-7z-wrap2.2.34-3-dev-osx-x86_64-en-US.zip Probably it would require some better cleanup and integration, that's just a working poc. -naif

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev