…and they want their flaws back. A recent post by Justin Case over at Android Police discusses some file permission issues (as in “world readable” file permission issues) in the Skype client for Android. Skype’s CISO even posted a terse, slightly boilerplate response to Justin’s finding. As a user of said software, and a natural-born-skeptic, I decided to validate this finding — faith [in security], after all, is the antithesis of proof. First, let’s see what the package name is for my Skype installation (it differs from the package name of the beta build cited in the Android Police post):
Sure enough, the directory, and files therein, are world-readable. The Android Police article details just what these files contain, so I’ll skip detailing that here. There is one point of contention that’s a little FUD-y and perhaps slightly misguided (emphasis added):
Skype mistakenly left these files with improper permissions, allowing anyone or any app to read them. Not only are they accessible, but completely unencrypted.
Of course, this information could be encrypted, but is it really necessary or correct from a security/control perspective? A priori, there are two other points to consider, I think: first, that these data (logs, contacts, and other information) are even stored on the device to begin with and that the user has no way to disable their storage; secondly, the insecure permissions. Would anyone have cared about encryption, or lack thereof, if these files had been adequately protected? Those issues aside, the overhead of crypto for every little operation on client-side chat log entries, contact lists, and other data used by Skype would likely have a significant impact on performance and battery life — and then there’s the issue of the key, which would undoubtedly result in some blog post lambasting Skype for storing key material incorrectly (or something similar).
(Sidebar: yes, there certainly are privacy implications with chat logs and contact data being accessible by other applications, not to mention the compound issue of easily retrieving the user’s login name and subsequently the path to their files, and I’m not rushing to Skype’s defense — insecure file permissions and lack of crypto are perennial issues — but the crypto argument might not have much firepower here when weighed against the data being stored and the idea of re-evaluating some design elements.)
Anyway, such a file permission weakness is not novel or, honestly, even earth-shattering — a rough search for “world readable” or “world writable” related security advisories yields numerous results, easily spanning the bulk of two decades. As evidenced by Justin Case’s finding, this is no less applicable to the mobile application space. We at Intrepidus have discussed file permission issues identified during the course of our assessments, ranging from information leakage to modification of application components. Moreover, renowned security researcher, Tavis Ormandy, even discovered an interesting permissions-related issue in Lookout Mobile Security for Android, for which the sharp folks at Lookout issued a straight-to-the-point technical advisory. In this case, the file permission issue manifested in a different way — a notably insufficient umask(2) setting inherited by the software, something that could have been easily overlooked in design.
Web applications still struggle with 10+ year old security problems, and remote code execution is still possible (albeit a bit waning) on network-facing services. So, then, is it really a surprise that “mobile”, as a nascent space, is susceptible to many of the same security-pertinent design, development, and implementation blunders that have pervaded other areas for 10, 20 years and beyond?
Both comments and trackbacks are currently closed.