Hacker News new | past | comments | ask | show | jobs | submit login
UTorrent.com compromised, malware added to installer (bittorrent.com)
100 points by emilw on Sept 14, 2011 | hide | past | favorite | 37 comments



As far as I remember, uTorrent has an internal auto-update functionality that interrogates the server for a new version. I wonder how well that is secured and if owning utorrent.com is enough to distribute a malicious update to all users unfortunate enough to start the application while owned.

I'm very wary about auto-updates that pull executables (as opposed to merely data) in this way. It's one thing for Chrome to do it, I assume Google does it in a way that's safe. But freeware/shareware projects? Not so much. Hell, who's to say the authors don't lose interest in two years and let the domain expire. I had one freeware or open-source app that didn't even have the courtesy of asking, it just pulled fresh binaries and restarted -- ouch. (At least you could disable this feature in the preference.)


For example, VLC (and, IIRC, Firefox) uses asymetric crypto to sign the update messages and the binaries. And the private keys are in none of the VideoLAN servers, but in other secret locations.

So, if the server is hacked, or a DNS is spoofed, you cannot make auto-update pull broken/malware binaries.

The problem is that, if your update process is buggy in some release, you loose those users forever...


Just since you mentioned Chrome's updating mechanism, it is a fascinating approach that they took: http://www.chromium.org/developers/design-documents/software...


Yes, but it's very difficult to setup outside Google.


courgette is just a binary diff algorithm -- there's nothing fancy to it (they use some really neat tricks, though), and apparently (I haven't verified) the source is in the chromium tree.

validating your updates via asymmetric crypto can be mildly expensive (http://www.verisign.com/code-signing/content-signing-certifi... lists Windows Authenticode certificates at $400/yr) but is within the realm of a small company.

setting up a Google-scale CDN and writing a reliable push update framework? that's the hard part.


To validate updates using asymmetric crypto you don't need to buy a special key at all. You can generate the keypair yourself... The only thing you need is some crypto lib to check a RSA or DSA signature on the downloaded data using a public key embedded in the software.


> $400/yr

That's VeriSign for you. Thawed sells the very same certificates for $200, and Comodo runs a coupon deal for Tucows members that gets you the cert for $99 (though the actual process is a bit too contrived compared to Thawte's).


startssl.com has code signing certificates for 60$, valid for 2 years.


yeah, I didn't go out of my way to find the cheapest price there. I just searched for "authenticode certificate" and that was the first result.


If I recall correctly, Google is facing a patent lawsuit over the Courgette technology. I don't remember if the complainant was a patent troll or not.


Whatever the outcome would be, that is enough to stop people from using this piece of open source software to provide safer updates.


As stated above, courgette doesn't provide safer updates, just smaller ones. It's just a really smart executable binary diff. Signing the update is an orthogonal issue.


I was talking about downloading their update code from their repositories and setting it up. That's not easy and you can see the discussions about this on their forum.


you can either use Courgette or bsdiff or some other binary diff algorithm for compressing code updates, or punt and choose to fully replace all of your code every time you rev.

update verification is a < 100-line block of code using system cryptographic libraries on Windows.

for Chrome-style background updating, the solution is as simple as:

1) running a thread in the background to ping an API to check when updates are available, 2) downloading them via HTTP when they arrive, and 3) having a program which gets run at update-required-exit, which verifies and applies the patch to your main executable.

yes, writing update machinery for your software is some work. no, it's not insurmountable, and will certainly get easier as the Mac App Store and Windows Store gain traction because they allow you to piggyback on the update machinery of the platform.


from what I've gleaned from being a uTorrent user, it interrogates the server for a .torrent file and then downloads that torrent from a tracker they run. presumably, anyone who owns the host of the .torrent, or anyone who owns the tracker, could own the update download -- though I'm not sure whether they use technologies like code signing at all to verify that the bits are their own.


I stopped using it since it wasn't open source. Worse when it became infested with "optional" ~~adware~~ search bar.


I installed it recently and even though I tried being careful not to install anything unnecessary, it tricked me into it! There was a checkbox saying something like "accept terms and conditions and install Bing toolbar", and I only readbthe beginning and left it checked as Eulas have conditioned me (of course I had accepted terms and conditions of utorrent before that).


Optional adware I can deal with in an otherwise open source application, but I've never understood why anyone would use a closed source bittorrent client if they ever plan on committing copyright infringement.


still using the last-open source version with the auto-updater disabled!


I'm pretty sure uTorrent was never open source. The mainline client was, though.


The current "mainline" one is simply the same as utorrent, with a different name.


my mistake it wasn't oss, it was the last version before BitTorrent began bundling it into installers.


May I suggest Deluge (http://deluge-torrent.org/)?

It's open-source, cross-platform and very similar to µTorrent in both functionality and looks.


Transmission ( http://www.transmissionbt.com/ ) is an open source torrent client with a nice web interface (as well as native interface) just like Deluge.

I think it is somewhat lighter resource-wise (I'm running it on my NAS), but apart from that I don't know the exact differences between Deluge and Transmission, but I thought I'd mention it for completeness' sake.


I love Transmission on OS X and wish they had a real Windows port!


Their website demonstrates a Qt GUI, as well as a web interface. What would, in your opinion, constitute a "real" Windows port?


Something better than those options? What about a web interface or a Qt GUI screams "great Windows UI" to you?


I suppose I did not place the same emphasis on "great" as you did. Alternatively, I couldn't name a "great" Windows UI offhand, anyway.

However, my experience is that some Qt apps on Windows behave normally, and depending on the application (but in this case, especially just the need to manage torrents) a web UI works just fine and avoids the waste of developer hours fighting against the local platform's quirks.

For my enlightenment, what do you consider as an example of a great Windows UI?


Just watch out for the latest (1.3.3) Windows release - it (or one of the bundled dependencies) seems very broken and I had to revert to the previous version to make things work again.


Can I choose which files to download before it puts empties on the file system?


Yes. It might create some folder structure, but if you choose at the time of adding the torrent to not download particular files, it won't create files. Tested just now on 1.3.1/Linux. I haven't tested recently, but I know I've gone in after adding the torrent, told it not to download some files, deleted what it had on the fs, and it did not regenerate them.


Interesting, I've been using deluge for many years, had no idea they had a build that runs on windows.

Deluge has all the features I want on a torrent client, I will replace my uTorrent installations on windows by deluge.


For those on Windows, here is a bit of code that can be used to validate Authenticode signature of the update package.

https://github.com/apankrat/assorted/blob/master/validate_pa...

Basically the idea is to get an Authenticode certificate and sign the update .exe with it. Then, when a program checks for an update and pulls it down, it would validate the package signature and will not proceed if the details - the application and the certificate subject names - are wrong. It is as simple as it gets.


And this is one of many reasons I love that almost all my software is installed through a secure package manager.


pacman cough cough sorry I just lost it for a second...


Some explanation to counter those terrible downvotes: Pacman, the package manager of Archlinux, is not implementing the verification of package signatures. It's a recurrent issue in the Arch community.





Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: