There's little-to-no practical opportunity to choose a Flash implementation, and Flash is not open-source, so we cannot secure it ourselves. Nothing you said is true.
I'm not looking forward to 'the next level' of the web. It will only have more dancing and blinking crap on the page.
Want to make you site fast? You don't need Ajax, Flash, or any other "Hype du Jour". Toss it all out, stick with plain old HTML and make it look decent with simple CSS. Wham, your site is now an order of magnitude faster. You don't need those five load balancers and those twenty application servers just to serve up a page that could easily run on one server when you actually had a clue.
Want to view content? I agree with your theme in that case, and there are plenty of sites out there that are designed around just that: simple presentation-focused static content display.
However, most of the impetus for "Web 2.0" has not been around content viewing, but rather about utilizing the web browser as an effective, cross-platform thin client for applications. Now, granted, some sites are (ab)using AJAX and whatnot for purposes ranging from nefarious to just annoying, and there is some spillover from the dynamic application-based web pages into the static information-based ones, but it's generally kept in balance by the ease with which people can transition to a competing website if yours is too annoying.
Recent advancements in Javascript execution speed are oriented towards polishing the thin client experience and capabilities. If fast Javascript execution becomes ubiquitous, sites can design much more successful thin clients because they can take that execution speed for granted. It's not all just flashing lights and annoying ads: take a look at the stunning Deluge BitTorrent Client's Web UI to see how nicely "Web 2.0" can be used.
Of course I DNRTFA before commenting, but this interested me:
Any test begins by sending out a driver in a conventionally driven car to map the route and road conditions. By mapping features like lane markers and traffic signs, the software in the car becomes familiar with the environment and its characteristics in advance.
It's kinda lame that Google's solution to hard problems like how to get a computer to drive a car, is basically replaying a recording of how a human drove on that exact piece of road. So what if some things are changed, or the software gets thrown onto an unknown road? A human will still be able to cope, but this software?
Not a recording of how a human drove; rather, they sent someone to map the area (record lane sizes, lights, crosswalks, traffic hazards, stop signs, speed limits, etc.) for the software. The software still drove the car; it just used its knowledge of the static environment to assist it in making the decisions. It can focus more on reacting to reality (by mapping it as a deformed version of that static image) rather than trying to visually recognize and read speed limit signs etc.
In a future where this sort of thing is actually implemented, there would certainly be a central knowledge base of this information for every street available to the computer. Updates (such as construction, accidents, etc.) would be broadcast in real-time. This is information that can be routinely gathered and thus is safe to take for granted.
The terrorists will develop their own encryption schemes so using wiretaps would be completely worthless anyway. The mafia is smart enough to outsmart this, street gangs are smart enough, terrorists are smart enough. This is to watch the civilian population like you and me.
Not so. Even if terrorists roll their own encryption, or even use AES, they are now explicitly guilty of a crime. the goal is less to decrypt the traffic and more to change the enforcement landscape. Even if I can't decrypt your traffic, I can arrest you and detain you. I can coerce you to decrypt it yourself or charge you for failing to.
While I certainly appreciate the effort, in the future please don't semi-obfuscate your publicly-released source code. That really doesn't give me the confidence that I need to run it on my machine.
Interesting read, and I can see you've given the problem a lot of thought. Mind if I ask why simply using standard crypto (AES-256) is not adequate? AES with CBC should not be distinguishable from random data.
As for the password-to-AES-key problem, just generate a random 256-bit key and prepend it to the file. If it's random, it shouldn't be distinguishable from the rest of the AES output data. Perform a 256-bit SHA-2 hash of the password and XOR it in with the key (or use a 160-bit SHA-1 hash and repeat the first 96 bits). Use some combination of the file size and date as a salt. Someone who wants to recover the key cannot do it without recovering the password, so, just as you wanted, the fastest path to proof / validation / recovery is your exhaustive password search.
I dunno, you've probably already thought about this, but in the event that you haven't, and in the event that the scotch hasn't made me miss something obviously wrong with this idea, I hope that you find this useful.
DES is considered too weak for many uses due to its small key size.
Nonetheless, if you can find a way to reliably distinguish DES output from random bits, without knowledge of the key and with remotely-practical efficiency, you can publish a paper that will gain you substantial name recognition among the world's cryptographic elite.
Agreed, but his point is well-taken regarding the identical encryption of duplicate blocks and the need for a rotating key schedule.
It's the difference between copying an unmodified MPEG (or VC1) stream at whatever rate your machine can muster, or recording the uncompressed output of such a stream at no faster than real-time.
The former is lossless, smallish, and fast. The latter is lossless only if you can keep up with and store the intense datarate, or is lossy if you recompress it, and it always takes as long to record as the playing-length of the source.
Big differences. Huge, giant, overwhelming differences, in fact.
Maybe I'm missing something here. It seems to me that you don't need to re-encode the huge data stream on-the-fly. The only thing you have really have to do in real-time is buffer the raw data stream to some persistent storage. After that, you can re-encode it however you like at your leisure.
I'm too tired to do the math and calculate how much storage a full Blu-Ray disc stream would require. Whatever it is, though, It only takes one guy with a hard disk array and an Internet connection and the media's toast.
This has drone research written all over it! Take out a signal to a drone and it's as good as shooting it down. It's probably easier to mess with a drone signal than shooting it down as well, but that's just pure speculation on my part.
I wouldn't be surprised if the drone has enough wherewithal to at least attempt to make it home when command-and-control and/or GPS signals fail. Even assuming whatever radio channels it uses are jammed, it still shouldn't have too much trouble using magnetic / visual orientation to return to base. Seems unlikely that there aren't quite a few layers of redundancy in there.
Funny how that's coming from the guy who's indexing it all so we can find it easier.
While Google may be the dominant information indexer, what they're doing doesn't require any special magic. Anybody can be indexing some or all of the information is out there (it's publicly-available, after all). Google being both dominant and public gives us a good idea of what can be done, but if Google didn't exist or limited itself, others would surely step in to fill that gap. It doesn't make what Mr. Schmidt said any less true.
To some degree we should count ourselves lucky that Google is both dominant and public. Imagine all of that information (still) being used against you, but you not having any idea of the vast quantity and depth of correlation that could be done.
Nowhere. But right now it's the most widely adopted and implemented (pretty much everyone but Firefox either does or is planning to support it). Until there is an alternative that all the major browsers support, Firefox is going to continue to lag behind. WebM is promising. But without MS onboard, it's going nowhere.
Really, there are two options:
MS chooses to adopt WebM. This is not unreasonable, especially as it starts to get rolled out more across the web. Part of MS's reluctance is probably due to the novelty of the technology.
MS doesn't ever adopt WebM. In that case, a FOSS plugin to IE will certainly end up being made (probably by Google, a la Chrome Frame) that adds WebM support, and any sites that use WebM will direct IE users to that plugin.
Either way, I don't see MS's explicit WebM support as a serious hurdle.
The problem isn't that Etisalat isn't who they claim to be. The problem is that their CA certificate was delegated as an intermediate CA by Verisign.
With an intermediate CA, they could issue certificates to anyone they want to, for any domain. This would allow them to snoop on (and interfere with) any SSL communications between absolutely anyway.
Neither Microsoft, nor Mozilla "trust" Eltisalat. They don't have Eltisalat's CA certificate installed. They. All major browsers include Verisign's root CA certificates. Since Verisign trusts Eltisalat, that means any software that trusts Verisign also trusts Eltisalat.
Eltisalat is basically owned by the government of the United Arab Emirates. This same government have, as the article (and summary) mentions, tried to snoop on users of Blackberries before, and have threatened RIM to have a back-door installed. Should these people be trusted with the ability to issue any SSL certificates, for any domain they want to?
The article references Verizon, not Verisign. Not trying to be pedantic here - just figured it was a worthwhile correction.
You are completely missing the point. The point is that it is feasible for an application that *does* appear to legitimately need these permissions (e.g. an improved SMS application, of which there are many).
Is it? Android lets you share data via SMS without needing your application to request SMS privileges via Intents (see my last comment to SuperKandall for way too much more information on that. This covers the vast majority of SMS-related use cases.
Granted there are still applications that may want to send SMS on their own (like Google Voice), but those applications ought to be scrutinized heavily when they request that particular permission. Who is their author? What do they do? Does it make sense for such an application to request that permission?
For any given capability, there will be a legitimate uses for them. Ultimately, it's up to the user to make the call. The best the operating system can do is provide the user with:
The opportunity to make such a decision, and
As much knowledge as possible to make the right decision.
Android (specifically) provides both to a very significant degree. Prior to installing any application, I know who wrote it, how popular it is, what other people think about it, and specifically what capabilities it will have. It's up to the user to weigh those qualities against each other and determine if they trust it with those capabilities, and you'll never find a security model (save total vendor control) that removes that responsibility, especially because most users want that kind of control.
There is no way for the user to specify that the only SMS messages that can be sent are those ones that they wish to send, or that the OWNER_DATA permission should only be used to read data required for the application to do its job. The fact that it's just a tic-tac-toe application is beside the point, a more complicated application could claim to need these permissions and all kinds of users are going to trust that the application is not doing the wrong thing.
It is the point, though. There may be legitimate uses for combinations of permissions, but the user can still make the call to avoid dangerous combinations of permissions (e.g., SMS text + user data, contacts + Internet access, etc.), just as application developers should do their best to avoid such dangerous combinations. Android provides very powerful capabilities in the form of Intents to minimize the need for an application to have its own capabilities.
If a user sees an application requesting numerous permissions, even if those permissions make sense, they can still weigh the consequences against the respectability of the author. The real risk to the security plan is a malicious application from a well-respected source (such that the trust in that source outweighs the concern for the application's requested capabilities), and fortunately the market works powerfully to minimize that risk, in the form of financial damage. The security model leverages free market to gain strength, and that is, indeed, quite powerful.
This is not "fearmongering bullshit", this is a legitimate concern for smartphones these days. I'm really confused why your comments got moderated up.
Maybe it's because I'm awesome? Seriously, don't be an ass.
I will explain my title:
The security model in Android is a very well-designed middle ground between opening up the device's potential to legitimate applications and giving the user the discretionary insight and power to make decisions. In fact, from a security point of view, I have never seen a better one (and feel free to point one out). The BBC doesn't offer any insight as to what they feel is wrong with the model. They just present a stylized, selective narrative isolating a worst-case scenario. Hence the "fearmongering".
I am taking hurdles that are already there and making the user remove them when it makes sense, instead of making them sign a paper saying they are OK with hurdles located somewhere distant being removed because they are an eyesore.
You are never PLACING hurdles in front of anything. Instead you should only ever be selectively removing system access controls when and where it makes sense.
I see what you're saying, but that methodology has the serious limitation in that it annoys the user. Furthermore, the security derived from your implementation is directly proportional to how many times you annoy the user - namely, the threshold that you set. At an extreme (pop-ups every time an SMS gets sent) it is very much more secure than the current implementations, since the user will immediately notice unsolicited SMS messages. However, anything short of that adds basically nothing, as all the malware has to do is ride out the threshold. And, unfortunately (speaking to user behavior), whatever the threshold is, if it's not very low, the users will likely get frustrated with the interruptions and automate through it (e.g., Internet Explore + ActiveX installation popups, or UAC).
It's sad, because a handful of power users could definitely take advantage of the system, but I am of the general opinion that those power users are not typically the ones that need protection from malware.
Yes they do. And they are impossible to judge. As I said in response to another post somewhere, you are asked to choose before you have even used an app. Well how do you know it's request to SMS is unreasonable? I cannot think of a single application type I could not see some potential in sharing information from via SMS. And the same is true for many users - in a media player they would be like "cool, I can SMS movies I like to friends".
...
We can disagree but it's very dangerous for Android to continue doing this - there will be many more, and many worse exploits. That's why I'm so fired up about this because I see it as a huge looming threat and I don't want to repeat the mistakes Microsoft made for any mobile OS moving forward.
Android has a generally good security model but it's undermined almost wholly by the presentation of user interaction for adjusting app controls.
I can only speak to Android, but I think I can say something particularly useful in this context. Specifically, on an Android platform, an application that wants to send text messages will likely do so not by requesting permissions to send SMS messages, but rather by soliciting Android's assistance via Intents. In this manner, if my application has text or media that it wants to send to someone else, it simply wraps it in an Intent describing the nature of it and passes it to Android, which proceeds to connect it to the appropriate service, oftentimes with user interaction.
Using Intents, applications can send data using services like Internet or SMS without, themselves, needing to request permissions to directly access the SMS system. Through Intents and IntentFilters, a type of ad-hoc network-of-trust is established: if I start only with non-malicious services, and never install apps that can send SMS messages, then malicious SMS messages cannot be sent; any app that wants to send SMS messages has to go through a trusted path, which (in a reasonable installation) involves things like pre-populating text fields and presenting the user with a "Send SMS" dialog.
As such, your theoretical SMS-sending media player should exist without needing to request a single permission. It'll work wonderfully and automatically integrate with the software on the phone to send media updates via SMS, Facebook, GMail, and any other paths that are present on your phone. Any application that requests "Send SMS" capabilities is a huge red flag; it wants to send SMS messages outside of the scope of the existing infrastructure. Unless I have a good reason to allow this (e.g., Google Voice), it's an automatic "no", no confusion necessary.
Just because it cannot stop all attacks does not mean it should stop none. It's still a better solution.
The key to security is defense in depth, and that means improving any one system when you can, because the system as a whole benefits from it. And it provides a much greater tangible awareness from the user about particular points of access to resources, which in turn is inadvertently providing the very education you wanted to give the user in the first place!
If I create a system with known limitations, someone seeking to exploit that system will take those limitations into account. Your idea serves to change the behavior of the malware; not to inhibit it or diminish its effectiveness. You're effectively placing hurdles in the path of the malware and hoping it gets tired of jumping them. Even worse, you are making your user base jump those same hurdles! Your entire premise is based on the idea that the software (or malware authors) will get tired before your users, and I can assure you this will never be the case.
You'll never get anywhere with that either. Ask any user in real life if they are looking for that, the answer 99 times out of 100 (for firefox users) would be no. A fair number of people may know to look for the lock though at this point since it is ubiquitous. Probably not a majority though.
I can only offer my own experiences here, but I have had near 100% success getting my friends, family, girlfriends, and coworkers to check that icon. "Look at the color, look at the lock, and make sure the name is right, and you'll be secure." I think it is a very effective and well-designed UI modification. I'm pretty proud of them:) YMMV, I guess.
And my suggestion provided a way to give a user a real context in which to make a security choice, instead of presenting a laundry list of security items which the average user will not have means to judge.
This is also pretty subjective, but I don't think these kinds of lists are overly-complex or obscure. They very clearly spell out exactly what the application is doing in words that everybody can understand. I believe that the issue, if any, is that users just aren't used to being presented with that kind of useful information, and they have to get accustomed to it.
Also only offering my own experiences here, but I know a lot of non-technical people who would refuse an app because of weird permissions. I also know someone who will install an app no matter what (my brother), but he can be an idiot sometimes.
Anyways, not to make this into a flamewar; I suppose we'll have to agree to disagree.
Instead, when a user opens an app they should be asked at the time of access to a resource if it's OK to access that resource. Now here I'm sure you start to be reminded of Vista UAC and innumerable "Are you sure" dialogs. But I don't mean every tine, I mean only once or twice and then the app is granted that permission permanently.
Yes it means that an app could potentially do something later on after being granted some permission. But it also would block a lot of obviously wrong things from working, like opening a media player and then being asked if it's OK to SMS a big ol' number you do not recognize.
You mentioned the shortcomings yourself; this wouldn't stop any serious malware author. They would either wait out whatever "trial period" you impose, or find a clever way to masquerade their malice to seem innocent. With application models like these, you really can't beat around the bush, and solutions that try and mitigate will only find their limits probed, explored, and worked around.
If you have to rely on that, the system will not work. Users don't want to, and will not be "educated" to. They want to buy and use something. You can't make users do something they don't want to, any more than force everyone to carefully listen to the flight attendants on an airline explain the safety procedures beforehand.
Education isn't as impossible as you seem to think it is. It is a compromise between the vendors and the users. I'll use browsers as examples: you'll never get Joe Averageuser to validate SSL certificate roots of trust by clicking through dialogues. You will, however, get very far giving him a simple piece of advice, like check the color of the bar before you use a banking website.
That is what phone OS's need to be designed to do (and they are, hence the "bullshit" in my title). They need to simplify the absurdly-complex system that is a mobile phone down to a manageable set of qualities that everyday users can handle and make intelligent decisions based on. You will always find your idiots, but smart OS / UI design can put the top 99% of people in a position to make the right call, and that's very powerful.
Existing mobile phone UIs certainly have plenty of room to grow, but the vendors understand the psychological and intellectual landscape, and I believe strongly that they are moving in the right direction at a very respectable pace.
If it's not a company that you are comfortable trusting
To be fair, the BBC is one company that even a lot of skeptical, careful people would think they could trust. I don't have the app, so I'm not sure how it was listed, but if it said BBC, I could see how people would tend to trust it.
Absolutely, and that is a wonderful part of the system. If BBC actually released this application maliciously under their trusted name, and anyone found out what it was doing, then BBC would face a hailstorm of complaints, bad press, and lost trust. This would almost certainly affect its bottom line.
Users trust BBC precisely because they have a lot to lose by betraying that trust.
I'll open with a disclaimer: most of my smartphone experience and awareness is centered around Android phones. That said, this article is yet another with a standard theme: "Remember, you stupid public, that smartphones are still computers". This is another in the a set of articles about people who write phone applications requesting a smorgasbord of permissions, receiving them from the user, and using them maliciously. Put simply, this is another in the formulaic series:
Mystique of Computers * Fear of Malware * Novelty of Phones = Profit
Chris Wysopal, co-founder and technology head at security firm Veracode, which helped the BBC with its project, said smartphones were now at the point the PC was in 1999.
No offense, but Chris Wysopal is an idiot. Modern smartphones run every application in a sandboxed per-application environment with fine-grained permission controls that are, to some degree, opaque to the user. These applications, by a well-defined default, must exist in a central repository managed by a powerful authority and receive realtime user reviews. This is nothing like PCs in 1999 (remember, that was Windows 98). Then again, he's certainly quite biased, as his company makes a living certifying applications.
All of the information-stealing elements of the spyware program were legitimate functions turned to a nefarious use.
Yes, of course they were. BBC didn't actually do anything innovative, like find an exploitation or break out of the sandbox. They just abused the OS's granted privileges to the fullest extent. Is this actually a problem? Given any set of privileges and any degree of fine-grained control, you can still abuse whatever you're given to the fullest extent.
At least one fundamental thing failed here: the user installed a phone game that requested privileges such as:
SEND_SMS: Allows an application to send SMS messages.
INTERNET: Allows applications to open network sockets.
READ_CONTACTS: Allows an application to read the user's contacts data.
READ_OWNER_DATA: Allows an application to read the owner's data.
... to name a few
As the owner and user of the device, it is ultimately your responsibility to determine what software you install on your phone. If you are downloading a single-player game that asks for these kinds of permissions, you had damned well better check out the source of that game. If it's not a company that you are comfortable trusting and you still install it, then you are (frankly) stupid. BBC does, of course, presume that its users are stupid.
But that's the problem... no amount of protection will allow stupid people have free access to a computer and remain protected. You have to strip away something from one of these factors... either whittle down free access or reduce the base of stupid users. Better design models only serve to decrease the thresholds required for either.
Is there an inherent issue with those kinds of permissions being available and grantable? Sure, there is! Applications, especially closed-source ones, are effectively black boxes. The permissions that I am presented with at installation-time are, in fact, my only real insight as to what the application is capable of doing. Arguing for a finer grain of control is pointless, though. Regardless of what permissions are grantable, you will never circumvent the fundamental problem that stupid users will blindly install applications. Presenting them with more information will not change that fact.
It is the job of the OS vendor (Apple, Google, RIM, etc.) to declare a set of permissions that reasonably mitigates the dangers of overly-gener
But that's the point... no attack vector means nothing interesting. The rootkit and its capabilities are presumed! It's common knowledge that anything software (kernel and higher) can do, a rootkit can do. Software can obviously make calls, read and send text messages, etc., therefore a rootkit can too. Same goes with Apple, by the way.
I'm not saying that there is no attack vector... just that this story is a non-issue, as all it exposes is already obvious. Let a hacker find an attack vector. Hopefully he'll present it next DEFCON, and that would be very interesting. Regardless, the rootkit never was the technical challenge.
FWIW, a subsequent presentation does show a privilege escalation Android exploit. Was very cool. Anyone who can write one of these can drool the rootkit in his sleep.
So yet more developers want to make a make for themselves by elevating a non-issue. I am currently attending their talk, and must admit that I am disappointed.
The first half of the presentation is them chatting about.how rooting a phone is desirable due to its intimate association with the user.No shit! Everybody knows this.
So let's get to the interesting part: There is no new attack vector. No propagation from Dalvik VM to kernel. No new technique. They wrote a Linux rootkit, like anyone can do. It is a kernel module. Anyone can make one of those. It hooks the kernel in various places to hide itself from various process / module listings. How innovative? Please.
The call this an exploit... nothing is exploited. They willingly participate in the installation at the root level. Their conclusion seems to be that someone with root has access to everything on a system. Shocking, eh?
The only funny part is that this took them 2 weeks to create. How terribly disappointing.
Yes, Mesa has a software implementation, but Mesa is a *lot* more than that. Most, if not all, open source drivers use Mesa/Gallium3D infrastructure, including nvidia/ati/intel open source drivers.
So yes, it is a problem even if you got the best graphics card on the market unless you use proprietary software. But staying open means staying with OpenGL 2.1 right now.
Honestly, if you're buying closed hardware, you might as well take the dive and download (for free) the closed software to support it. I don't see how, morally or ethically, one is any worse than the other. Drivers are just software glue to connect hardware to your OS. For all practical purposes, you should consider them to be an extension of the hardware, so long as the vendor maintains them responsibly (like NVidia does). FOSS has a very respectable value, but knowingly crippling your hardware for a deviant extension of that value is just a waste.
Slashdot Mirror
And the same thing could be said about Flash too.
There's little-to-no practical opportunity to choose a Flash implementation, and Flash is not open-source, so we cannot secure it ourselves. Nothing you said is true.
How much you wanna bet we're going to have to wait for Adobe's next 90-day update cycle, since this was released right on the day of another patch?
Looks like not. From the article:
Adobe security officials said they plan to patch the Flash bug on Nov. 9 and will release a fix for Reader and Acrobat during the week of Nov. 15.
I'm not looking forward to 'the next level' of the web. It will only have more dancing and blinking crap on the page.
Want to make you site fast? You don't need Ajax, Flash, or any other "Hype du Jour". Toss it all out, stick with plain old HTML and make it look decent with simple CSS. Wham, your site is now an order of magnitude faster. You don't need those five load balancers and those twenty application servers just to serve up a page that could easily run on one server when you actually had a clue.
Want to view content? I agree with your theme in that case, and there are plenty of sites out there that are designed around just that: simple presentation-focused static content display.
However, most of the impetus for "Web 2.0" has not been around content viewing, but rather about utilizing the web browser as an effective, cross-platform thin client for applications. Now, granted, some sites are (ab)using AJAX and whatnot for purposes ranging from nefarious to just annoying, and there is some spillover from the dynamic application-based web pages into the static information-based ones, but it's generally kept in balance by the ease with which people can transition to a competing website if yours is too annoying.
Recent advancements in Javascript execution speed are oriented towards polishing the thin client experience and capabilities. If fast Javascript execution becomes ubiquitous, sites can design much more successful thin clients because they can take that execution speed for granted. It's not all just flashing lights and annoying ads: take a look at the stunning Deluge BitTorrent Client's Web UI to see how nicely "Web 2.0" can be used.
Of course I DNRTFA before commenting, but this interested me:
It's kinda lame that Google's solution to hard problems like how to get a computer to drive a car, is basically replaying a recording of how a human drove on that exact piece of road. So what if some things are changed, or the software gets thrown onto an unknown road? A human will still be able to cope, but this software?
Not a recording of how a human drove; rather, they sent someone to map the area (record lane sizes, lights, crosswalks, traffic hazards, stop signs, speed limits, etc.) for the software. The software still drove the car; it just used its knowledge of the static environment to assist it in making the decisions. It can focus more on reacting to reality (by mapping it as a deformed version of that static image) rather than trying to visually recognize and read speed limit signs etc.
In a future where this sort of thing is actually implemented, there would certainly be a central knowledge base of this information for every street available to the computer. Updates (such as construction, accidents, etc.) would be broadcast in real-time. This is information that can be routinely gathered and thus is safe to take for granted.
The terrorists will develop their own encryption schemes so using wiretaps would be completely worthless anyway. The mafia is smart enough to outsmart this, street gangs are smart enough, terrorists are smart enough. This is to watch the civilian population like you and me.
Not so. Even if terrorists roll their own encryption, or even use AES, they are now explicitly guilty of a crime. the goal is less to decrypt the traffic and more to change the enforcement landscape. Even if I can't decrypt your traffic, I can arrest you and detain you. I can coerce you to decrypt it yourself or charge you for failing to.
Exactly my thoughts, that would mean that no one can sue Torrent-Sites in Spain.
Do precedents work like that in Spanish court?
Wrong? It's not true that the general Bond-watching audience thinks of lasers as being white hot?
It's pretty obvious: The atoms are stirred, not shaken.
[disclaimer] Any agency that is sniffing my packets will find the stench of wrongdoing here.
Oh no, IP packet fragmentation!
While I certainly appreciate the effort, in the future please don't semi-obfuscate your publicly-released source code. That really doesn't give me the confidence that I need to run it on my machine.
Interesting read, and I can see you've given the problem a lot of thought. Mind if I ask why simply using standard crypto (AES-256) is not adequate? AES with CBC should not be distinguishable from random data.
As for the password-to-AES-key problem, just generate a random 256-bit key and prepend it to the file. If it's random, it shouldn't be distinguishable from the rest of the AES output data. Perform a 256-bit SHA-2 hash of the password and XOR it in with the key (or use a 160-bit SHA-1 hash and repeat the first 96 bits). Use some combination of the file size and date as a salt. Someone who wants to recover the key cannot do it without recovering the password, so, just as you wanted, the fastest path to proof / validation / recovery is your exhaustive password search.
I dunno, you've probably already thought about this, but in the event that you haven't, and in the event that the scotch hasn't made me miss something obviously wrong with this idea, I hope that you find this useful.
DES is nowadays considered a weaker algorithm
DES is considered too weak for many uses due to its small key size.
Nonetheless, if you can find a way to reliably distinguish DES output from random bits, without knowledge of the key and with remotely-practical efficiency, you can publish a paper that will gain you substantial name recognition among the world's cryptographic elite.
Agreed, but his point is well-taken regarding the identical encryption of duplicate blocks and the need for a rotating key schedule.
It's the difference between copying an unmodified MPEG (or VC1) stream at whatever rate your machine can muster, or recording the uncompressed output of such a stream at no faster than real-time.
The former is lossless, smallish, and fast. The latter is lossless only if you can keep up with and store the intense datarate, or is lossy if you recompress it, and it always takes as long to record as the playing-length of the source.
Big differences. Huge, giant, overwhelming differences, in fact.
Maybe I'm missing something here. It seems to me that you don't need to re-encode the huge data stream on-the-fly. The only thing you have really have to do in real-time is buffer the raw data stream to some persistent storage. After that, you can re-encode it however you like at your leisure.
I'm too tired to do the math and calculate how much storage a full Blu-Ray disc stream would require. Whatever it is, though, It only takes one guy with a hard disk array and an Internet connection and the media's toast.
This has drone research written all over it! Take out a signal to a drone and it's as good as shooting it down. It's probably easier to mess with a drone signal than shooting it down as well, but that's just pure speculation on my part.
I wouldn't be surprised if the drone has enough wherewithal to at least attempt to make it home when command-and-control and/or GPS signals fail. Even assuming whatever radio channels it uses are jammed, it still shouldn't have too much trouble using magnetic / visual orientation to return to base. Seems unlikely that there aren't quite a few layers of redundancy in there.
Funny how that's coming from the guy who's indexing it all so we can find it easier.
While Google may be the dominant information indexer, what they're doing doesn't require any special magic. Anybody can be indexing some or all of the information is out there (it's publicly-available, after all). Google being both dominant and public gives us a good idea of what can be done, but if Google didn't exist or limited itself, others would surely step in to fill that gap. It doesn't make what Mr. Schmidt said any less true.
To some degree we should count ourselves lucky that Google is both dominant and public. Imagine all of that information (still) being used against you, but you not having any idea of the vast quantity and depth of correlation that could be done.
Nowhere. But right now it's the most widely adopted and implemented (pretty much everyone but Firefox either does or is planning to support it). Until there is an alternative that all the major browsers support, Firefox is going to continue to lag behind. WebM is promising. But without MS onboard, it's going nowhere.
Really, there are two options:
Either way, I don't see MS's explicit WebM support as a serious hurdle.
The problem isn't that Etisalat isn't who they claim to be. The problem is that their CA certificate was delegated as an intermediate CA by Verisign.
With an intermediate CA, they could issue certificates to anyone they want to, for any domain. This would allow them to snoop on (and interfere with) any SSL communications between absolutely anyway.
Neither Microsoft, nor Mozilla "trust" Eltisalat. They don't have Eltisalat's CA certificate installed. They. All major browsers include Verisign's root CA certificates. Since Verisign trusts Eltisalat, that means any software that trusts Verisign also trusts Eltisalat.
Eltisalat is basically owned by the government of the United Arab Emirates. This same government have, as the article (and summary) mentions, tried to snoop on users of Blackberries before, and have threatened RIM to have a back-door installed. Should these people be trusted with the ability to issue any SSL certificates, for any domain they want to?
The article references Verizon, not Verisign. Not trying to be pedantic here - just figured it was a worthwhile correction.
You are completely missing the point. The point is that it is feasible for an application that *does* appear to legitimately need these permissions (e.g. an improved SMS application, of which there are many).
Is it? Android lets you share data via SMS without needing your application to request SMS privileges via Intents (see my last comment to SuperKandall for way too much more information on that. This covers the vast majority of SMS-related use cases.
Granted there are still applications that may want to send SMS on their own (like Google Voice), but those applications ought to be scrutinized heavily when they request that particular permission. Who is their author? What do they do? Does it make sense for such an application to request that permission?
For any given capability, there will be a legitimate uses for them. Ultimately, it's up to the user to make the call. The best the operating system can do is provide the user with:
Android (specifically) provides both to a very significant degree. Prior to installing any application, I know who wrote it, how popular it is, what other people think about it, and specifically what capabilities it will have. It's up to the user to weigh those qualities against each other and determine if they trust it with those capabilities, and you'll never find a security model (save total vendor control) that removes that responsibility, especially because most users want that kind of control.
There is no way for the user to specify that the only SMS messages that can be sent are those ones that they wish to send, or that the OWNER_DATA permission should only be used to read data required for the application to do its job. The fact that it's just a tic-tac-toe application is beside the point, a more complicated application could claim to need these permissions and all kinds of users are going to trust that the application is not doing the wrong thing.
It is the point, though. There may be legitimate uses for combinations of permissions, but the user can still make the call to avoid dangerous combinations of permissions (e.g., SMS text + user data, contacts + Internet access, etc.), just as application developers should do their best to avoid such dangerous combinations. Android provides very powerful capabilities in the form of Intents to minimize the need for an application to have its own capabilities.
If a user sees an application requesting numerous permissions, even if those permissions make sense, they can still weigh the consequences against the respectability of the author. The real risk to the security plan is a malicious application from a well-respected source (such that the trust in that source outweighs the concern for the application's requested capabilities), and fortunately the market works powerfully to minimize that risk, in the form of financial damage. The security model leverages free market to gain strength, and that is, indeed, quite powerful.
This is not "fearmongering bullshit", this is a legitimate concern for smartphones these days. I'm really confused why your comments got moderated up.
Maybe it's because I'm awesome? Seriously, don't be an ass.
I will explain my title:
I am taking hurdles that are already there and making the user remove them when it makes sense, instead of making them sign a paper saying they are OK with hurdles located somewhere distant being removed because they are an eyesore. You are never PLACING hurdles in front of anything. Instead you should only ever be selectively removing system access controls when and where it makes sense.
I see what you're saying, but that methodology has the serious limitation in that it annoys the user. Furthermore, the security derived from your implementation is directly proportional to how many times you annoy the user - namely, the threshold that you set. At an extreme (pop-ups every time an SMS gets sent) it is very much more secure than the current implementations, since the user will immediately notice unsolicited SMS messages. However, anything short of that adds basically nothing, as all the malware has to do is ride out the threshold. And, unfortunately (speaking to user behavior), whatever the threshold is, if it's not very low, the users will likely get frustrated with the interruptions and automate through it (e.g., Internet Explore + ActiveX installation popups, or UAC).
It's sad, because a handful of power users could definitely take advantage of the system, but I am of the general opinion that those power users are not typically the ones that need protection from malware.
Yes they do. And they are impossible to judge. As I said in response to another post somewhere, you are asked to choose before you have even used an app. Well how do you know it's request to SMS is unreasonable? I cannot think of a single application type I could not see some potential in sharing information from via SMS. And the same is true for many users - in a media player they would be like "cool, I can SMS movies I like to friends".
...
We can disagree but it's very dangerous for Android to continue doing this - there will be many more, and many worse exploits. That's why I'm so fired up about this because I see it as a huge looming threat and I don't want to repeat the mistakes Microsoft made for any mobile OS moving forward.
Android has a generally good security model but it's undermined almost wholly by the presentation of user interaction for adjusting app controls.
I can only speak to Android, but I think I can say something particularly useful in this context. Specifically, on an Android platform, an application that wants to send text messages will likely do so not by requesting permissions to send SMS messages, but rather by soliciting Android's assistance via Intents. In this manner, if my application has text or media that it wants to send to someone else, it simply wraps it in an Intent describing the nature of it and passes it to Android, which proceeds to connect it to the appropriate service, oftentimes with user interaction.
Using Intents, applications can send data using services like Internet or SMS without, themselves, needing to request permissions to directly access the SMS system. Through Intents and IntentFilters, a type of ad-hoc network-of-trust is established: if I start only with non-malicious services, and never install apps that can send SMS messages, then malicious SMS messages cannot be sent; any app that wants to send SMS messages has to go through a trusted path, which (in a reasonable installation) involves things like pre-populating text fields and presenting the user with a "Send SMS" dialog.
As such, your theoretical SMS-sending media player should exist without needing to request a single permission. It'll work wonderfully and automatically integrate with the software on the phone to send media updates via SMS, Facebook, GMail, and any other paths that are present on your phone. Any application that requests "Send SMS" capabilities is a huge red flag; it wants to send SMS messages outside of the scope of the existing infrastructure. Unless I have a good reason to allow this (e.g., Google Voice), it's an automatic "no", no confusion necessary.
Just because it cannot stop all attacks does not mean it should stop none. It's still a better solution.
The key to security is defense in depth, and that means improving any one system when you can, because the system as a whole benefits from it. And it provides a much greater tangible awareness from the user about particular points of access to resources, which in turn is inadvertently providing the very education you wanted to give the user in the first place!
If I create a system with known limitations, someone seeking to exploit that system will take those limitations into account. Your idea serves to change the behavior of the malware; not to inhibit it or diminish its effectiveness. You're effectively placing hurdles in the path of the malware and hoping it gets tired of jumping them. Even worse, you are making your user base jump those same hurdles! Your entire premise is based on the idea that the software (or malware authors) will get tired before your users, and I can assure you this will never be the case.
You'll never get anywhere with that either. Ask any user in real life if they are looking for that, the answer 99 times out of 100 (for firefox users) would be no. A fair number of people may know to look for the lock though at this point since it is ubiquitous. Probably not a majority though.
I can only offer my own experiences here, but I have had near 100% success getting my friends, family, girlfriends, and coworkers to check that icon. "Look at the color, look at the lock, and make sure the name is right, and you'll be secure." I think it is a very effective and well-designed UI modification. I'm pretty proud of them :) YMMV, I guess.
And my suggestion provided a way to give a user a real context in which to make a security choice, instead of presenting a laundry list of security items which the average user will not have means to judge.
This is also pretty subjective, but I don't think these kinds of lists are overly-complex or obscure. They very clearly spell out exactly what the application is doing in words that everybody can understand. I believe that the issue, if any, is that users just aren't used to being presented with that kind of useful information, and they have to get accustomed to it.
Also only offering my own experiences here, but I know a lot of non-technical people who would refuse an app because of weird permissions. I also know someone who will install an app no matter what (my brother), but he can be an idiot sometimes.
Anyways, not to make this into a flamewar; I suppose we'll have to agree to disagree.
Instead, when a user opens an app they should be asked at the time of access to a resource if it's OK to access that resource. Now here I'm sure you start to be reminded of Vista UAC and innumerable "Are you sure" dialogs. But I don't mean every tine, I mean only once or twice and then the app is granted that permission permanently.
Yes it means that an app could potentially do something later on after being granted some permission. But it also would block a lot of obviously wrong things from working, like opening a media player and then being asked if it's OK to SMS a big ol' number you do not recognize.
You mentioned the shortcomings yourself; this wouldn't stop any serious malware author. They would either wait out whatever "trial period" you impose, or find a clever way to masquerade their malice to seem innocent. With application models like these, you really can't beat around the bush, and solutions that try and mitigate will only find their limits probed, explored, and worked around.
If you have to rely on that, the system will not work. Users don't want to, and will not be "educated" to. They want to buy and use something. You can't make users do something they don't want to, any more than force everyone to carefully listen to the flight attendants on an airline explain the safety procedures beforehand.
Education isn't as impossible as you seem to think it is. It is a compromise between the vendors and the users. I'll use browsers as examples: you'll never get Joe Averageuser to validate SSL certificate roots of trust by clicking through dialogues. You will, however, get very far giving him a simple piece of advice, like check the color of the bar before you use a banking website.
That is what phone OS's need to be designed to do (and they are, hence the "bullshit" in my title). They need to simplify the absurdly-complex system that is a mobile phone down to a manageable set of qualities that everyday users can handle and make intelligent decisions based on. You will always find your idiots, but smart OS / UI design can put the top 99% of people in a position to make the right call, and that's very powerful.
Existing mobile phone UIs certainly have plenty of room to grow, but the vendors understand the psychological and intellectual landscape, and I believe strongly that they are moving in the right direction at a very respectable pace.
If it's not a company that you are comfortable trusting
To be fair, the BBC is one company that even a lot of skeptical, careful people would think they could trust. I don't have the app, so I'm not sure how it was listed, but if it said BBC, I could see how people would tend to trust it.
Absolutely, and that is a wonderful part of the system. If BBC actually released this application maliciously under their trusted name, and anyone found out what it was doing, then BBC would face a hailstorm of complaints, bad press, and lost trust. This would almost certainly affect its bottom line.
Users trust BBC precisely because they have a lot to lose by betraying that trust.
I'll open with a disclaimer: most of my smartphone experience and awareness is centered around Android phones. That said, this article is yet another with a standard theme: "Remember, you stupid public, that smartphones are still computers". This is another in the a set of articles about people who write phone applications requesting a smorgasbord of permissions, receiving them from the user, and using them maliciously. Put simply, this is another in the formulaic series:
Mystique of Computers * Fear of Malware * Novelty of Phones = Profit
Chris Wysopal, co-founder and technology head at security firm Veracode, which helped the BBC with its project, said smartphones were now at the point the PC was in 1999.
No offense, but Chris Wysopal is an idiot. Modern smartphones run every application in a sandboxed per-application environment with fine-grained permission controls that are, to some degree, opaque to the user. These applications, by a well-defined default, must exist in a central repository managed by a powerful authority and receive realtime user reviews. This is nothing like PCs in 1999 (remember, that was Windows 98). Then again, he's certainly quite biased, as his company makes a living certifying applications.
All of the information-stealing elements of the spyware program were legitimate functions turned to a nefarious use.
Yes, of course they were. BBC didn't actually do anything innovative, like find an exploitation or break out of the sandbox. They just abused the OS's granted privileges to the fullest extent. Is this actually a problem? Given any set of privileges and any degree of fine-grained control, you can still abuse whatever you're given to the fullest extent.
At least one fundamental thing failed here: the user installed a phone game that requested privileges such as:
As the owner and user of the device, it is ultimately your responsibility to determine what software you install on your phone. If you are downloading a single-player game that asks for these kinds of permissions, you had damned well better check out the source of that game. If it's not a company that you are comfortable trusting and you still install it, then you are (frankly) stupid. BBC does, of course, presume that its users are stupid.
But that's the problem ... no amount of protection will allow stupid people have free access to a computer and remain protected. You have to strip away something from one of these factors ... either whittle down free access or reduce the base of stupid users. Better design models only serve to decrease the thresholds required for either.
Is there an inherent issue with those kinds of permissions being available and grantable? Sure, there is! Applications, especially closed-source ones, are effectively black boxes. The permissions that I am presented with at installation-time are, in fact, my only real insight as to what the application is capable of doing. Arguing for a finer grain of control is pointless, though. Regardless of what permissions are grantable, you will never circumvent the fundamental problem that stupid users will blindly install applications. Presenting them with more information will not change that fact.
It is the job of the OS vendor (Apple, Google, RIM, etc.) to declare a set of permissions that reasonably mitigates the dangers of overly-gener
But that's the point... no attack vector means nothing interesting. The rootkit and its capabilities are presumed! It's common knowledge that anything software (kernel and higher) can do, a rootkit can do. Software can obviously make calls, read and send text messages, etc., therefore a rootkit can too. Same goes with Apple, by the way.
I'm not saying that there is no attack vector... just that this story is a non-issue, as all it exposes is already obvious. Let a hacker find an attack vector. Hopefully he'll present it next DEFCON, and that would be very interesting. Regardless, the rootkit never was the technical challenge.
FWIW, a subsequent presentation does show a privilege escalation Android exploit. Was very cool. Anyone who can write one of these can drool the rootkit in his sleep.
So yet more developers want to make a make for themselves by elevating a non-issue. I am currently attending their talk, and must admit that I am disappointed.
The first half of the presentation is them chatting about.how rooting a phone is desirable due to its intimate association with the user.No shit! Everybody knows this.
So let's get to the interesting part: There is no new attack vector. No propagation from Dalvik VM to kernel. No new technique. They wrote a Linux rootkit, like anyone can do. It is a kernel module. Anyone can make one of those. It hooks the kernel in various places to hide itself from various process / module listings. How innovative? Please.
The call this an exploit ... nothing is exploited. They willingly participate in the installation at the root level. Their conclusion seems to be that someone with root has access to everything on a system. Shocking, eh?
The only funny part is that this took them 2 weeks to create. How terribly disappointing.
Yes, Mesa has a software implementation, but Mesa is a *lot* more than that. Most, if not all, open source drivers use Mesa/Gallium3D infrastructure, including nvidia/ati/intel open source drivers. So yes, it is a problem even if you got the best graphics card on the market unless you use proprietary software. But staying open means staying with OpenGL 2.1 right now.
Honestly, if you're buying closed hardware, you might as well take the dive and download (for free) the closed software to support it. I don't see how, morally or ethically, one is any worse than the other. Drivers are just software glue to connect hardware to your OS. For all practical purposes, you should consider them to be an extension of the hardware, so long as the vendor maintains them responsibly (like NVidia does). FOSS has a very respectable value, but knowingly crippling your hardware for a deviant extension of that value is just a waste.