Thanks! Reducing friction for these kinds of things is good for everyone.
I didn't bother checking after I read that the autoupdate wasn't compromised, but never hurts to check - and I was not really going to do it until I saw your post.
If anyone wonders why this is taking too long, you may have done the same daft thing I just did, which was to copy the first command and then copy pbpaste | sh -. The latter will of course create an infinite loop.
Your line downloads and executes the latest version of the gist, it could have changed from a file check to a virus installer by the author (unlikely, but I have to point it out). To be a bit more safe (while trusting that GitHub is not compromised) pin a known, verified version:
As a general pattern, please do not do this. In this specific case I think most people trust the service (GitHub) and their DNS recursor + SSL library. Attacking these is not on the level of "random drive-by phishing", more like "targeted high value state sponsored".
To avoid this discussion I did not include the curl version in my original posting.
Yeah, let's download and blindly run stuff directly from the internet (that may have changed since we last saw it) without saving and trying to read what it does first.
If you can copy/paste the curl | bash, is it really more difficult to copy/paste the original snippet into a text editor[0], and from there, into bash?
If you C&P it, at least you see what's being C&P'd (although it's up to you to take the trouble to understand it). `| bash`ing it runs it automatically, without even giving you a chance to see it.
EDIT: This comment was based on the assumption that my parent hadn't read carefully. My facile point ignores both the specific vulnerability pointed out by [czinck](https://news.ycombinator.com/item?id=12406080) below, and the general vulnerability that you just can't trust anything pulled in from an external source. I think that re-directing to a file, and viewing the file with something like `:set list` set in `vim`, will work, at least in the sense of showing you the code that will actually be executed (although nothing can save you from not understanding the code), as long as you can trust your own stack. However, it is a near-certainty that this edit will prompt someone to explain how to exploit that. (That may sound like whingeing, but it's just a (happy) acknowledgement of the hacker mentality; unexpected exploitations, as PsoC rather than attacks, are pretty neat, too!)
Is this robust against locating `Transmission.app` somewhere other than `/Applications`? (I put my applications in `~/Applications`, but I don't know the specifics of Keynap; maybe it ignores applications not in the usual location.)
Might it be better to replace the first two tests with something like `-f /[star][star]/Transmission.app/Contents/Resources/License.rtf`?
They never responded with details of what they were doing to improve security after the last incident: https://forum.transmissionbt.com/viewtopic.php?f=1&t=17938. The outside appearance is that they didn't address the problem seriously enough.
Second time that this has happened to Transmission this year. Last time a ransomware got included. If you're a Transmission user then be very cautious when installing new versions.
Depending on where they get their checksums. Anyone can submit an app update, so long as the official download link matches the provided checksum then it will get merged. The only benefit here is the delay introduced in receiving the update.
Changes made by GitHub pull requests. I'm sure an anonymous contributor who submits only a checksum change, without version bump, would most certainly fail review.
I'm googling to try to find how Homebrew uses checksums and where it gets them. But not everything homebrew installs comes from GitHub, so I don't see how checksums for all of it could come from 'Changes made by GitHub pull requests'.
And it looks like homebrew checksums both source packages and pre-compiled binaries. There's no way an upstream dependency would be providing their own checksum for a homebrew compiled binary. Homebrew also switched from using MD5 to using SHA1 recently (https://github.com/Homebrew/brew/blob/master/share/doc/homeb...), obviously all of their dependencies didn't switch in unison too, which suggests the checksums do not come from the dependencies themselves.
Looking for more info about this, having trouble finding it. To have confidence in homebrew's checksum system, one needs to know how it works and where they come from, but having trouble finding it.
Or did you mean the checksum is made in a PR to homebrew's own repo? Right, but the question is still where it comes from. If it was generated from bad source obtained from upstream, it will of course be bad. It's just verifying that the package as installed matches what homebrew maintainers meant to install; but that's no guarantee that what homebrew maintainers meant to install wasn't bad in the first place. Since transmission was distribution bad packages itself due to a hack, I'm not following how homebrew providing a checksum means that it can't re-distribute bad packages from upstream. It does mean that homebrew itself is harder to hack than transmission, but doesn't necessarily help when transmission is hacked.
When this happens regularly like with Transmission, is there a guarantee the version in official repos is not affected? The only way to be sure would be code checks and I doubt they do that.
For Ubuntu, the universe repo (where Transmission is located) is community maintained and not even security upgrades are guaranteed. They do key checks only.
It was the .dmg file hosted on their own server, so any version could be compromised. I guess the safest route to take is to build the app from source.
I feel stupid knowing that I actually considered this when installing on the 28th, but thought that they wouldn't allow a repeat of KeRanger. Looks like I'll be building all my software from source now (and switching to Aria2).
No it did not. They distributed a new version via the build-in updater to try to remove the malware from the copies downloaded from the website. Sparkle use a digital signature and the malware author did not have the private key to create a valid signature for the update. So even if a malware was downloaded, Transmission would report a "invalid archive downloaded" error.
So what happened with the codesigning? That's pretty much the only viable line of defense for the average user (nobody is going to be verifying SHA signatures, or the site is going to be compromised along with the download)
Was the malware version also signed with an official Apple Developer ID? The same ID? Is a change of ID verified with the auto-updater?
If there was a malicious Developer ID, has it been revoked by Apple?
> According to this article [1], the compromised app was indeed signed – but with a different Developer ID than usual.
That's the terrible part about all of this. Having signed applications without any verification of the signer is pointless.
A simplistic, yet more secure approach, would be to have domain validated keys that could be used to sign applications. Browsers could then verify that the application downloaded from example.com was signed with a key for example.com. I think OSX already stores "This was downloaded from the scary internets!" in a separate resource fork so this info could go there as well. Maybe even cut out the middle mad and put them in DNS SRV records so you don't even need a central CA. If DNS gets compromised the client's have bigger problems already.
Unfortunately like all things like this, it'd be forever before it's widespread enough to be useful.
It's not completely pointless, as it allows Apple to (silently and quickly) release updates which distrust that Developer ID, however a stronger protection would be to pin apps to a particular Developer ID.
>> If your membership expires, users can still download, install, and run your Developer ID–signed applications. However, once your Developer ID certificate expires, you must be an Apple Developer Program member to get new Developer ID certificates to sign updates and new applications.
What I understand is that codesigning costs $99 a year, which open-source projects may want to skip, but this harms their credibility if their downloads are compromised.
I really thought Apple had added a free option (maybe even specifically for open source projects?), but I can't find it anywhere. Can anyone else find that info, or am I misremembering?
Thank you! I'd confused it with recent changes to the iOS program allowing people to self-sign so they can test on their own iOS devices.
It looks like Educational memberships are Sign-In With Apple ID only, which doesn't provide a Developer ID (which is required for code signing, as far as I can tell).
It's nasty that a free software project has to deal with this, given their limited resources. This shows the importance of reproducible builds and using package managers with verification like APT or homebrew.
> The OSX/Keydnap backdoor is equipped with a mechanism to gather and exfiltrate passwords and keys stored in OS X’s keychain. The author simply took a proof-of-concept example available on Github called Keychaindump. It reads securityd’s memory and searches for the decryption key for the user’s keychain. This process is described in a paper by K. Lee and H. Koo. One of the reasons we think the source was taken directly from Github is that the function names in the source code are the same in the Keydnap malware.
I guess any security tools and scripts are bound to be used for naughty stuff at some point, but I thought "real" malware writers would put more effort (at least obfuscation) into their products. Keychaindump is a crude hacky PoC, and I honestly didn't expect it to get directly copy-pasted into "serious" malware.
This is why applications should use app sandboxing on OS X. And Apple should provide an option to reject (by default) any application that is not signed + sandboxed, rather than: anything, signed, or app store.
I'm not a Transmission user, but this makes me wonder, as a sort of Ask HN question: How long do you wait before updating software?
If you always update as soon as possible, then you risk getting hit by a compromise like this one, or you could suffer other unintentional bad effects of a botched update.
But the longer you delay updating, the more you raise your risk of becoming a victim of a new vulnerability that's just been patched and is now in the wild.
Problem is that apps nowadays check for updates automatically. And if the release message says it's a security patch I guess the most of usrs will update right away. At least I do. And obviously if I was a hacker I would play that "important security update, upgrade immediately" card, it's a basic social engineering...
Neither during this or the previous incidence the updates were compromised (they were checked by the installed binary). Only fresh downloads from the website.
I haven't read much about this, so perhaps I'm not understanding clearly, but if the downloaded binary from Transmission's "website server" was replaced, then how is that not a compromise?
I genuinely feel for the developers, and I personally would not blame them if I was affected, but unless the data was intercepted enroute from their server, then I think they have to accept some degree of responsibility for the whole delivery chain to the end user.
It was compromised, but wouldn't affect updates as the internal updater checks signatures.
(IIRC the first compromised version (not sure about the second) also had broken / no Mac OS codesigning, though I'm not sure how many people turn off / bypass gatekeeper).
Well, they do accept some kind of responsibility: it is spelled out clearly in the license what they accept, and you can choose whether you prefer the terms defined in GPL, or MIT (Transmission is dual-licensed).
Do you mind linking to that? Please quote the relevant part of license if you have time.
I ask that because I think they'd be insane to accept responsibility.
I searched on their site, briefly, but I couldn't find this.
I haven't checked MIT license but the GPL 3.0 has got this clause about liability limitation.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
To me it sounds like it means whatever happens after you use our software, it's not our fault! Which sounds like a reasonable license for open source free software, to me.
Exactly that. They give you their work for free (as in freedom and also as in beer), so why would they accept anthing more than a responsibility to provide you with the source and wish you a good luck? If you want protection, you can buy commercial support for a GPL-licensed software, if it exists for the software in question, or look for an insurance company to buy insurance against any calamity. Why would Transmission developers provide such thing, and what's more, for free?
I wait about a week, unless I've heard out of band talk about some terrible hack with a punny name and we all need to upgrade NAO!1! I suppose I should always look for a secondary source for release notes or such as soon as possible; I don't because I am a lazy human.
Yes, totally, if you want to make the best decision, then you have to keep up with the news. That's why I'm interested in other opinions about this, because there's a lot of datapoints you need to factor into a decision. It's not a simple decision. That's work, and we are lazy humans, you're right.
But, I don't wait a whole week if the update is from an organization which I think I can trust not to totally botch an update, because they're conscious of the enormous potential for costly legal liability. I'm thinking of organizations such as Microsoft, Apple, Nvidia, AMD, Google, as a few examples. I might wait 1 or 2 days in that case.
The size of the user base is certainly an important factor. To maybe exaggerate a contrary opinion though, I'd say that users of, for example, Ubuntu Linux, are far more alert to security issues than Microsoft customers.
I'm not totally disagreeing, I'm just trying to say that calculating a confidence score for software updates is not simple. Maybe it's clearer if I give you a real-world example: I use cryptocurrencies to move moderately large amounts of capital in my business, and so my paranoia-level for software installed on the single, air-gapped laptop that handles cryptocurrencies is sky high and crazy cautious. My other business is separated from that, and I can be much more relaxed about software updates for it, because the risks are much lower.
Service announcement: You were only at risk when you downloaded fresh copies from the website. As with the previous incident, updates within the app were safe and checked.
It's pretty scary that they still haven't fixed the Sparkle RCE vulnerability from a few months back. Attackers with access to their servers could've installed malware for every user, even if they didn't install the update.
Kinda sucks, and I haven't followed Transmission for a while, but them transitioning more to Github is a good thing -- I trust Github more than a self hosted solution, in general. It sucks they've been compromised twice in a year, but hopefully this will help mitigate some of that.
I like Transmission, but this is the second serious security problem they've had this year. Once you can forgive, but twice and it's time to look for a new BitTorrent client.
FYI: Transmission binaries are now hosted on GitHub, so it is very unlikely that anything like this can happen in the future without compromising developer machines.
Instead of "Blah-blah, less than a day, go check yourself", they could grep the logs for IPs (and session cookies if they log that) of lucky winners and explicitly inform them, when they hit any page on their site. Then show generic version to everyone else. This takes all but 5 minutes to set up.
Nice idea with a major problem: If they did this, the absence of such a message could suggest that you were not affected, when in fact you could be (changed IP, cleared browser, etc).
False negatives are pretty bad in this case, better for users to check themselves.
It will all remain exactly as it is now, except for the case when they recognize a visitor that is likely to have downloaded the malware. In this case they should throw an extra warning.
You would be right if nobody besides the affected people would ever know that they are doing this.
But as soon as other people know or hear of it, they will go check the website to "see if they are affected". Even if the website has a huge disclaimer telling people that they could still be affected, the absence of the warning would still suggest that they are not affected, even when they could be.
I've been using rtorrent for years and I wouldn't ever suggest anything else. It's just so damn simple and reliable. I love the concept of watch directories too. Upload a torrent file to a specific directory, and the data will be downloaded to a specific directory. You can have multiple watch directories for different types of data.
I like Deluge, but I really wish its default API (protocol) wasn't so difficult to use. It's bencoded Python objects as far as I can tell. If you've never heard of bencoding, that's because it's only used by Deluge.
Pay for it then? Netflix scratches my entertainment itch now, but prior to it launching in Australia I almost went ahead and paid for uTorrent. It's a good, lightweight client. Software that works well deserves to be financially supported.
The parent comment was suggesting paying for uTorrent to remove the ads, not paying for Netflix. (Although paying for subscriptions to overseas services might also be an option.)
qBittorrent is just as good and free, why pay for something that's maybe a few MB smaller? Do you really not have gigabytes of RAM on your machine? If you don't, I suggest spending that money on RAM.
They say that the infected file was only there for a day, but maybe it would behoove them to do some bash-fu w/ their logs and get an approximation of the number of users affected!
Thanks for the correction. I wrote the original title based on the warning on their homepage: "Critical security notice to users who downloaded Transmission 2.92 for Mac on August 28th or 29th".
Android users have way more money in aggregate, but iPhone apps make more money. This is because iPhone users have a lot more disposable income, while Android users are cheap.
