The question has been asked, here and elsewhere, what we possibly could have told the novices out there in order to immunize them against this sort of attack. The question is even more relevant now that this proof of concept has been a smashing success, which must surely have emboldened other bad guys to improve up on it.
Just tell them to deny any request, even from a trusted entity, to obtain permissions or passwords to another service they use, even if, as in this case, the service (Google Docs) is under the same roof as the message delivery service (GMail).
This means:
NO autodebit. (Just give us your account numbers and Telephone Inc will autodebit your monthly bill!)
NO autoimport. (Just import all your tax data using your MyBux.com password, and we'll do the rest!)
NO autosubscription. (For just $9.99 automatically billed to your credit card every month, Happy Music will deliver unlimited music!)
And above all NO permissions to your personal accounts for ANYONE other than on a doc-by-doc basis for the sake of collaboration, in which case grant the permission manually by going to Google Docs (or whatever collaboration app) and explicitly adding the person by his/her email address, NOT his/her name, which might map to a different email address.
The only thing you can safely give out is your wifi password, because all routers should be presumed pwned. Practice good endpoint security, and give up on everything else.
In the US anyway, freedom is worth dying for. The best way to fuck the terrorists is to show them that they can't change anything about our social norms. As far as I'm concerned, Whatsapp should be considered an in-the-clear messenger which is only "encrypted" because the government happens not care about the sender at this particular moment. What this sort of "pretend encryption" approach does is let the terrorists know that we're willing to give up our core values so they won't kill anymore of us. Heck, why stop there? We all might as well convert to their perverted brand of Islam. Of course, this is all misguided because eventually they'll find out how to do more damage, encryption or not. Which means we'll still have terror attacks a century from now, but what we won't have is private messaging.
What do we need in order to reclaim the freedom that our ancestors (in America, at least) literally died for? Open source everything, from the circuit diagrams in our chips all the way to the app layer. Is this happening? I hope I'm just ignorant, but the answer would seem to be "no". There's no "real money" in open source anything, and things are getting exponentially more complicated with time. So maybe there's something to be said for building a truly dumb "combox" for private messaging and nothing else, which actually could make money for the people behind it, and therefore be economically viable. Does anyone know of anything like this? And no, I'm not talking about some "brilliant" encryption app running on top of swiss cheese dogshit like Android.
The important takeaway here is not that flawed tutorials lead to bad code. It's the implication that one could actually poison tutorials intentionally, perhaps in some very subtle way. While it would be quite difficult to inject malware this way (unless the tutorial convinces some idiot to download this "include file that you need for this function"), it probably wouldn't be too difficult to inject, say, buffer overflows or XSS vulnerabilities that could well be invisible to novice programmers. Those vulnerabilities could then be exploited post-deployment, perhaps using a bot scan of Github to identify broken apps that include the code.
Rust is better because for something on the order of a 10% overhead vs C, it effectively eliminates buffer overflows (unless something is amiss with Rust itself, in which case we have only one bug to fix, but millions of precompiled vulnerabilities in the field). On balance, Rust seems like a net positive to security. It does nothing much, however, to prevent vulnerabilities having nothing to do with memory exploits. For that matter, one could probably write Rust code to exploit Rowhammer. Or poison a tutorial to do that. It would be completely "safe" multithreaded code... that isn't, thanks to ubiquitous shitty DRAM.
There's another, subtler issue: UTF8 hacks. One could post a tutorial and substitute various characters with various similar characters. Maybe, just maybe, one could find a way to get some dufus to copy the code into his source and create an exploit because he confuses one character with another one that looks almost the same (or, even worse, exactly the same due to text rendering shortcomings on his end).
On the vigilante end, I suppose the only solution is to first of all identify the poisoned/flawed tutorials, and secondly to search Github or other repositories for key snippets. This is a hard problem to automate due to the zillions of ways that the tutorial code might be imported into a project and tweaked to fit, without destroying the vulnerability it injects.
So, to the noobs out there: read tutorials, but, at most, copy code from them by retyping it yourself. DON'T DOWNLOAD INCLUDES OR "REQUIRED BINARIES". DON'T CUT AND PASTE CODE INTO YOUR PROJECT. Cross-verify with multiple sources (which could have been manufactured by the same hacker, so beware similar look-and-feel), and if you still don't really understand what you're doing, then do it some other way.
Now, for the public generally, I wish there were a way for us to protect ourselves from this crap. I don't think there is, apart from avoiding software like the plague. It's not like the code you cut and paste from the tutorial is going to create some obvious malware signature in most cases, especially if the tutorial is very abstract in nature. After all, there are endless versions of compilers and compiler settings in use out there.
"Reed and Klimkowski show that this combination of DASH and VBR can produce sequences of video segment sizes (i.e. fingerprints) that are unique for each video."
Do we really need yet another lesson to teach us that mixing variably (but deterministically) sized traffic segments with HTTPS is self-defeating? Netflix needs to confront the fact that if they value user privacy over performance, they need to roughly double their bandwidth by appending non-pseudo-random junk traffic to each segment, and enforcing a global minimum segment size. I would go so far as to say, furthermore, that they need to ensure that the latency between segment send times is also highly random (up to some acceptably small limit). Otherwise, at least within the first few hops from their server farm, it would be possible to deduce the video ID just from that stream of latencies, as it's probably being read from the same cache hierarchy using the same processors and busses with roughly consistent behavior.
The real threat they've discovered has nothing to do with Silverlight. It regards the implications for doing the same on video sites generally, most notably YouTube, using only modestly more sophisticated techniques. Time to reinvent the DVD rental store...
While I think Shuttleworth is right that the software industry in general suffers from profound sociopathy, he doesn't seem to have asked the obvious question, which is why people hated his UI, and Ubuntu in general. Sure, we should be grateful that a group of developers would share the fruits of their labor with the community, for free. Perhaps we should actually pity them for not being able to monetize it worth a damn, while legions of their users profit, directly or indirectly, from their work. To that extent, the economic model of open source is completely broken. That said, I don't consider Ubuntu an asset worth sharing. It's so buggy, so slow, so awkward, so annoying, and so devoid of architectural consistency, that it's just a giant liability masquerading as a "Trusty" OS. I see no commitment to quality assurance, or even a commitment to user engagement. Their project is swamped with a hundred thousand open bugs, most of which having rotted for months on their website. They constantly mix new features (read: annoyances) with bug fixes, so nothing is ever stable. At least when Microsoft created its own dogpile of an OS, its founder reinvested the profits in laudible charitable causes. But Ubuntu has just created more hassle than it relieved, taxing its users in many nonobvious ways including potential privacy compromises, and AFAIK not even making enough money for its creators to be worthwhile.
Give up, Mark. Your heart is in the right place, but unfortunately not your head. Acquire Solus Linux. It actually works, and it boots like 10X faster.
Slashdot Mirror
The question has been asked, here and elsewhere, what we possibly could have told the novices out there in order to immunize them against this sort of attack. The question is even more relevant now that this proof of concept has been a smashing success, which must surely have emboldened other bad guys to improve up on it.
Just tell them to deny any request, even from a trusted entity, to obtain permissions or passwords to another service they use, even if, as in this case, the service (Google Docs) is under the same roof as the message delivery service (GMail).
This means:
NO autodebit. (Just give us your account numbers and Telephone Inc will autodebit your monthly bill!)
NO autoimport. (Just import all your tax data using your MyBux.com password, and we'll do the rest!)
NO autosubscription. (For just $9.99 automatically billed to your credit card every month, Happy Music will deliver unlimited music!)
And above all NO permissions to your personal accounts for ANYONE other than on a doc-by-doc basis for the sake of collaboration, in which case grant the permission manually by going to Google Docs (or whatever collaboration app) and explicitly adding the person by his/her email address, NOT his/her name, which might map to a different email address.
The only thing you can safely give out is your wifi password, because all routers should be presumed pwned. Practice good endpoint security, and give up on everything else.
In the US anyway, freedom is worth dying for. The best way to fuck the terrorists is to show them that they can't change anything about our social norms. As far as I'm concerned, Whatsapp should be considered an in-the-clear messenger which is only "encrypted" because the government happens not care about the sender at this particular moment. What this sort of "pretend encryption" approach does is let the terrorists know that we're willing to give up our core values so they won't kill anymore of us. Heck, why stop there? We all might as well convert to their perverted brand of Islam. Of course, this is all misguided because eventually they'll find out how to do more damage, encryption or not. Which means we'll still have terror attacks a century from now, but what we won't have is private messaging.
What do we need in order to reclaim the freedom that our ancestors (in America, at least) literally died for? Open source everything, from the circuit diagrams in our chips all the way to the app layer. Is this happening? I hope I'm just ignorant, but the answer would seem to be "no". There's no "real money" in open source anything, and things are getting exponentially more complicated with time. So maybe there's something to be said for building a truly dumb "combox" for private messaging and nothing else, which actually could make money for the people behind it, and therefore be economically viable. Does anyone know of anything like this? And no, I'm not talking about some "brilliant" encryption app running on top of swiss cheese dogshit like Android.
The important takeaway here is not that flawed tutorials lead to bad code. It's the implication that one could actually poison tutorials intentionally, perhaps in some very subtle way. While it would be quite difficult to inject malware this way (unless the tutorial convinces some idiot to download this "include file that you need for this function"), it probably wouldn't be too difficult to inject, say, buffer overflows or XSS vulnerabilities that could well be invisible to novice programmers. Those vulnerabilities could then be exploited post-deployment, perhaps using a bot scan of Github to identify broken apps that include the code. Rust is better because for something on the order of a 10% overhead vs C, it effectively eliminates buffer overflows (unless something is amiss with Rust itself, in which case we have only one bug to fix, but millions of precompiled vulnerabilities in the field). On balance, Rust seems like a net positive to security. It does nothing much, however, to prevent vulnerabilities having nothing to do with memory exploits. For that matter, one could probably write Rust code to exploit Rowhammer. Or poison a tutorial to do that. It would be completely "safe" multithreaded code... that isn't, thanks to ubiquitous shitty DRAM. There's another, subtler issue: UTF8 hacks. One could post a tutorial and substitute various characters with various similar characters. Maybe, just maybe, one could find a way to get some dufus to copy the code into his source and create an exploit because he confuses one character with another one that looks almost the same (or, even worse, exactly the same due to text rendering shortcomings on his end). On the vigilante end, I suppose the only solution is to first of all identify the poisoned/flawed tutorials, and secondly to search Github or other repositories for key snippets. This is a hard problem to automate due to the zillions of ways that the tutorial code might be imported into a project and tweaked to fit, without destroying the vulnerability it injects. So, to the noobs out there: read tutorials, but, at most, copy code from them by retyping it yourself. DON'T DOWNLOAD INCLUDES OR "REQUIRED BINARIES". DON'T CUT AND PASTE CODE INTO YOUR PROJECT. Cross-verify with multiple sources (which could have been manufactured by the same hacker, so beware similar look-and-feel), and if you still don't really understand what you're doing, then do it some other way. Now, for the public generally, I wish there were a way for us to protect ourselves from this crap. I don't think there is, apart from avoiding software like the plague. It's not like the code you cut and paste from the tutorial is going to create some obvious malware signature in most cases, especially if the tutorial is very abstract in nature. After all, there are endless versions of compilers and compiler settings in use out there.
"Reed and Klimkowski show that this combination of DASH and VBR can produce sequences of video segment sizes (i.e. fingerprints) that are unique for each video." Do we really need yet another lesson to teach us that mixing variably (but deterministically) sized traffic segments with HTTPS is self-defeating? Netflix needs to confront the fact that if they value user privacy over performance, they need to roughly double their bandwidth by appending non-pseudo-random junk traffic to each segment, and enforcing a global minimum segment size. I would go so far as to say, furthermore, that they need to ensure that the latency between segment send times is also highly random (up to some acceptably small limit). Otherwise, at least within the first few hops from their server farm, it would be possible to deduce the video ID just from that stream of latencies, as it's probably being read from the same cache hierarchy using the same processors and busses with roughly consistent behavior. The real threat they've discovered has nothing to do with Silverlight. It regards the implications for doing the same on video sites generally, most notably YouTube, using only modestly more sophisticated techniques. Time to reinvent the DVD rental store...
While I think Shuttleworth is right that the software industry in general suffers from profound sociopathy, he doesn't seem to have asked the obvious question, which is why people hated his UI, and Ubuntu in general. Sure, we should be grateful that a group of developers would share the fruits of their labor with the community, for free. Perhaps we should actually pity them for not being able to monetize it worth a damn, while legions of their users profit, directly or indirectly, from their work. To that extent, the economic model of open source is completely broken. That said, I don't consider Ubuntu an asset worth sharing. It's so buggy, so slow, so awkward, so annoying, and so devoid of architectural consistency, that it's just a giant liability masquerading as a "Trusty" OS. I see no commitment to quality assurance, or even a commitment to user engagement. Their project is swamped with a hundred thousand open bugs, most of which having rotted for months on their website. They constantly mix new features (read: annoyances) with bug fixes, so nothing is ever stable. At least when Microsoft created its own dogpile of an OS, its founder reinvested the profits in laudible charitable causes. But Ubuntu has just created more hassle than it relieved, taxing its users in many nonobvious ways including potential privacy compromises, and AFAIK not even making enough money for its creators to be worthwhile. Give up, Mark. Your heart is in the right place, but unfortunately not your head. Acquire Solus Linux. It actually works, and it boots like 10X faster.