Archives For Uncategorized

A fix for multiple vulnerabilities affecting all uTorrent, BitTorrent and uTorrent Web Windows users is now available for immediate download at the links below. We must stress that while this is a vulnerability that can be exploited to trigger unauthorized downloads to take place, BitTorrent Inc. is not aware of any incidents related to these vulnerabilities. As always, we highly encourage all of our customers to stay up to date. Android and Mac users are not affected by the reported vulnerabilities.

Download the latest builds:

uTorrent Stable
Bittorrent Stable
uTorrent Beta
uTorrent Web

The team began rolling out the update to beta uTorrent Windows users via the auto update mechanism on Feb 16, 2018. As of today, Feb 22, 2018, the rollout for beta users has concluded and the stable rollout has started. Included in the latest builds are fixes to the way uTorrent and uTorrent Web authenticate WebUI requests and generate session and authentication tokens. In addition to this, the updates clamp down on guest account access limits and enforce more checks on potentially malicious HTTP headers sent to the client.

Customers and developers of 3rd-party applications that rely on the default-open state of port 10000 should be aware that moving forward, clients will no longer be discoverable over port 10000. Pairing negotiation is now only allowed over a mutually agreed upon port. Customers can set this port manually by enabling WebUI functionality via Advanced->WebUI-> Enable Web UI and then specifying a port under the Connectivity section.


You can find the full changelog here:

uTorrent 3.5.3 For Windows (build 44358)

In our connected world, no one is safe from malware. All types of software are constantly under attack, making security a major issue for software developers everywhere, every day.

This week, the first ransomware on Mac was discovered in a release by the Transmission team. It’s understandable that this has made news, particularly given that this is the first direct malware attack to impact OS X users.

On behalf of our friends at Transmission, we would urge understanding and ask users to look at their body of work when judging them and not a single incident which they quickly and decisively handled.

By many accounts, this vulnerability for OS X has existed for some time. Every company, every website, is prone to vulnerabilities. There is no software vendor out there that has not done its fair share of firefighting. It is a credit to all the teams that can flag and address an issue quickly before it reaches consumers becomes widespread.

It was unfortunate that Transmission was the vector of this first attack, but kudos to the team for reacting quickly to release a fixed version that removes the malicious code. The issue was discovered on March 4th and addressed the next day. Having gone through a few of these fire drills myself, I understand what kind of effort it takes to react that quickly to an issue.  If you are reading this and you use Transmission, please download their latest version to remove the malware.

What is also important to note, and many news outlets have reported this correctly, is that the attack was not on the BitTorrent protocol nor on Transmission’s client. The attack does not affect other BitTorrent clients, nor does it affect the files you download via BitTorrent. This attack was directed at OS X itself via a packaged file within the installer tool used to download Transmission. Palo Alto Networks describes it here:

Attackers infected two installers of Transmission version 2.90 with KeRanger on the morning of March 4. When we identified the issue, the infected DMG files were still available for downloading from the Transmission site (hxxps://[.]dmg) Transmission is an open source project. It’s possible that Transmission’s official website was compromised and the files were replaced by re-compiled malicious versions, but we can’t confirm how this infection occurred.

As developers of software used by millions of people, we have to be ever vigilant.  All of us take security seriously and try very hard to thwart attacks of any variety.  So once again, hats off to the Transmission team for dealing with this threat quickly.

At BitTorrent, our team of engineers are managing a complex set of tasks across many versions of our growing products. Perhaps no team feels the squeeze now than the engineers working on Sync as it transitions to 2.0. Sync Engineer and frequent blog contributor Richard Brooks recognized the difficulty of tracking the progress of Sync across Windows, Mac, Linux, and FreeBSD:
Continue Reading…

Screen Shot 2013-04-23 at 8.06.24 PM

Brave inventors, intrepid tinkerers, awesome doers, and startups everywhere: we’ve got a job for you.

Over the course of the past few months, we’ve been busy in the Lab. We’ve been hard at work on a solution for personal file management; opening up an Alpha version of BitTorrent Sync. We’ve been looking at ways to streamline creative collaboration; using a simple file delivery service we call SoShare. We’ve been exploring search prioritization; helping artists find visibility via BitTorrent Surf. And we’ve been experimenting with the storytelling and monetization potential of BitTorrent publishing; via content releases with media innovators: authors like Tim Ferriss, studios like Cinedigm.

Our goal is to create a more sustainable distribution model for the Internet’s creators and fans.

We’re in this together.

And we want your help.

We’re opening up our innovation lab to new media startups. If you have a publicly available product in sound, film, live streaming, media sharing, or peer-to-peer technologies, we’ll work with you to accelerate your idea’s success. Continue Reading…

There are a couple of fairly nasty bugs in the LSP sample code from Microsoft in the function WSPSelect, and as far as I can tell, this one hasn’t been reported anywhere before. Since we’re working on an LSP here, I’ve had to fix this bug. 🙂

The bug affected iTunes and safari, which I have noticed some traffic about.

The actual bug is in the three clauses that copy the activations from the provider-socket fd_sets into the client-supplied fd_sets that contain client-visible socket objects

They look like this:
(note that ReadFds is internal, and contains provider sockets, readfds is the user’s parameter, and contains client facing socket descriptors)

And there are three copies of this code for the three fd_sets passed into select.

So what happens if we pass two fd_sets to this code with the same address? Note that in each clause (seperately), the client’s fd_set is zeroed!

So WSASelect(0, &my_sockets, &my_sockets, &my_sockets, NULL) will report the correct count, but only sockets that have exceptions will remain activated when we return to the caller! Moving the FD_ZERO macro expansions and the count captures all above these passes through the fd_sets will fix this bug.

The second one is less severe but still might be harmful; note that the return from the lower provider’s select is a count of activated sockets. This count is not the number of fd_set members that achieved activation, but the number of sockets, so if a socket is repeated for some reason in the incoming fd_set, it will only be counted once on input, but it will be represented twice in our internal array. Microsoft’s sample code will terminate early in this case (note that HandleCount– will be executed twice for one socket), with two activations of one socket, but leaving any remaining events uncopied, My suggestion is to also check whether the we’d be setting the same socket twice into the client’s fd_set, so we can skip double counting as the underlying provider apparently does.

In any case, you should definitely check the code you’re importing. Even OS authors make mistakes, as much as their frequent machismo might suggest otherwise.