3 ms·
I think it's sort of unclear if "breaking out of a sandbox" is what's happening. Obviously no one expects this to be happening. But the features are known, an
by ajross 1y ago
I think it's sort of unclear if "breaking out of a sandbox" is what's happening. Obviously no one expects this to be happening. But the features are known, and mostly desired, things:
* Apps can open local TCP/UDP ports on the device to talk to each other. That's good, often. It's a valuable capability, just like access to shared storage is. And it doesn't leak any info the app doesn't want to leak.
* Apps can get a reasonably unique fingerprint for the device they're running on. Again, that's desired: backends want to know who they're talking to, and that it's not a MitM or hijacked account.
* Browsers can talk to those local servers too. Again, this seems useful to me, as long as native apps have capabilities that web apps lack, they should be able to offer them as extensions to the web API.
So basically we have a situation where Facebook's native app tells Facebook's web app (or rather Facebook's web code being distributed by Facebook's partner sites) what machine it's operating on (and maybe some more details about the history, like user account cookies, etc...), in contravention of the user's expectations about what they told the partner site to store about them.
It's that last bit that's the bad part. But it's not really about device security as I see it. Facebook broke the spirit of the cookie tracking rule, but not the letter.
- Nextgrid 1y agoMalware also takes advantage of known and useful features. Being able to read and write your files (to steal or encrypt them), being able to open sockets (to connect to the C&C server) and so on. Which is why we generally look at the intention rather than how it was achieved technically.
- abeyer 1y ago> Browsers can talk to those local servers too. Again, this seems useful to me, as long as native apps have capabilities that web apps lack, they should be able to offer them as extensions to the web API. Not sure if I agree on that one... at a minimum I think that should be behind a user consent prompt.
- ajross 1y agoMaybe, but it's worth pointing out that even that wouldn't prevent the exploit in question. Facebook didn't have to transfer this cookie locally, the app and web site could just as easily have exchanged it via some RESTful API server somewhere (well, on the same origin as the Facebook JS in question). The reason they didn't do that is pure obscurity: if they blasted a tracking cookie over the internet they would have been caught faster. Trying to design "security" features by pushing the "obscurity" boundary around is usually wasted effort.
- swiftcoder 1y agoI'm not sure I agree about any of these being desirable as specified. * App-to-app network communication really only seems sane between apps from the same vendor. * Unique fingerprinting of the device is explicitly not desirable. They should have access to a unique anonymous identifier for the device, which cannot be compared between apps from multiple vendors. * Browsers talking to native apps again seems like something that should only be possible if both the web domain and the app belong to the same vendor. I don't have a huge problem with Facebook.com talking to the Facebook app - I do have a problem with random 3rd-party sites talking to the Facebook app.