LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
Recent Features
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityRemotely wiping mobile phonesA mobile phone "feature" that is touted as a way to remove data from stolen phones is also being used in far less reasonable ways. It is, or could be seen as, an anti-feature added for the benefit of companies, but without taking users' needs into consideration. The "remote wipe" available for (at least) Android, iOS, and Palm's webOS allows Exchange administrators to remotely reset logged-in mobile phones—removing all personal data and resetting them to factory defaults. The amount of sensitive information that is stored on mobile phones today—especially smartphones—is quite substantial. It is no surprise that both companies and individuals are worried about those phones falling into the wrong hands. Under those circumstances, one can well imagine that being able to remotely wipe that data as quickly as possible would be seen as a nice feature. But there are a number of concerns with the current approach. As Nathan Hamblen reports on his blog, remote wipe is currently being misused by Exchange administrators to punish users who access their corporate email from unapproved devices. In many, perhaps most, cases, those unapproved devices are the personal property of a user who is just trying to get their work done. One can understand administrators wanting to impose draconian access rules, and even to enforce them, but punishing users by deleting their photos, applications, and other personal data seems just a tad beyond the pale. Evidently the remote wipe feature was originally added for Blackberry devices to protect against loss or theft. Exchange administrators have been clamoring for the same functionality for other mobile phones as those devices added Exchange compatibility. Over time, the phone makers have complied, with Android adding (and touting) remote wipe in its 2.2 ("Froyo") release. But it's not clear that users are being warned about the power they are placing in the hands of their corporate IT staff when they connect to the Exchange server. From the comments on Hamblen's blog, it would seem that iPhones do not warn users about the remote wipe, but that Android 2.2 does. It certainly is not particularly intuitive that logging in to check your work email suddenly puts your phone at risk. If administrators do not want to provide Exchange access to mobile devices, a smaller, more focused hammer—like access restrictions of some kind—is likely to work out better in the long run. For Android phones, Exchange access—and remote wipe—are implemented in the standard email application. There is evidently no mechanism to override the server security policies via the email application settings, but there is a way to disable the remote wipe functionality for those with root access or the ability to install non-Market applications. Essentially, a securitypolicy.java file in the application bundle (i.e. the .apk file) needs to be changed to turn off security policy enforcement. It seems to be something of a historical artifact that remote wipe is tied to Exchange. Some users and administrators would undoubtedly like to have this capability without it necessarily being dependent on an active connection to an Exchange server. So, some kind of remote wipe protocol getting added into phone operating systems may be on the horizon. That will, of course, open up another set of potential issues. There are obviously situations where a connection to the Exchange server might be interrupted when a phone gets lost or stolen. One would guess that those interested in obtaining phones for corporate espionage—as opposed to the more run-of-the-mill criminal looking for a quick buck at the pawn shop—would know enough to disable Exchange immediately. For those truly concerned about mobile data security, the current remote wipe is something of a half-measure. Beyond the question of administrators wiping phones as punishment for trying to keep on top of email, there are other concerns as well. How well protected is the remote wipe command from attackers? One hopes that Microsoft (and the phone implementers) have provided strong authentication and/or encryption for that command channel. But, as we have seen before, vulnerabilities may well be found that allow random attackers to wipe phones. It's bad enough to give that kind of power over your personal phone to administrators, but putting it into the hands of script kiddies is well over the top. There is clearly a balance to be struck. Companies are rightly concerned about their proprietary information and its dispersal to devices that might end up in the clutches of competitors. On the other hand, those same companies are interested in having productive employees but it is difficult and expensive to hand out smartphones to all employees so they can check their email. Not to mention the fact that many of those people will already have a phone they like and may not be willing to carry around a second one to check their email. The problem goes further than that, though. Laptops and other non-phone devices (e.g. tablets, netbooks, possibly even home desktops) probably hold a lot more sensitive corporate data. Some of those devices can have their disks encrypted and/or require more rigorous authentication for access, but the problem still remains. There will always be windows of vulnerability and sophisticated attackers will find ways to exploit them. The problem here is with data that leaves the confines of the company, regardless of where it is stored. It has been suggested that "cloud" backups of personal data from phones might partially solve the problem as users can just restore their data after being punished for accessing their email. That seems fraught with peril as well, however, not least because the sensitive corporate email probably gets backed up right along with the photos of the user's children and the funny sign they saw on the way to work. In the end, companies that apply punitive sanctions to their employees' personal property for transgressions of the security policy may just find that folks will come up with better ways to spend their time. Perhaps taking pictures or playing games with their phones instead of keeping up with their work email.
Brief items Severe Adobe Flash vulnerabilityFor those of you using the Adobe Flash player (including on Linux or Android), and, possibly, Adobe Reader users as well: the company has announced a "critical" vulnerability which, evidently, is being actively exploited. "We are in the process of finalizing a fix for the issue and expect to provide an update for Adobe Flash Player for Windows, Macintosh, Linux, Solaris, and Android operating systems during the week of September 27, 2010. We expect to provide updates for Adobe Reader 9.3.4 for Windows, Macintosh and UNIX, and Adobe Acrobat 9.3.4 for Windows and Macintosh during the week of October 4, 2010." Even people who cannot do without this software might want to consider taking it off their systems until the update comes out.
O'Brien: Haystack vs How The Internet WorksDanny O'Brien writes about the Haystack debacle, which may have exposed many of the people it was supposed to be helping to protect. "Lessons? Well, as many have noted, reporters do need to ask more questions about too-good-to-be-true technology stories. Coders and architects need to realize (as most do) that you simply can't build a safe, secure, reliable system without consulting with other people in the field, especially when your real adversary is a powerful and resourceful state-sized actor, and this is your first major project. The Haystack designers lived in deliberate isolation from a large community that repeatedly reached out to try and help them: that too is a very bad idea. Open and closed systems alike need independent security audits."
New vulnerabilities couchdb: arbitrary code execution
cvsnt: privilege escalation
django: cross-site scripting
libglpng: arbitrary code execution
mountall: arbitrary code execution
ntop: denial of service
ocsinventory: multiple vulnerabilities
phpMyAdmin: cross-site scripting
samba: remote code execution
slim: arbitrary code execution
webkitgtk: multiple vulnerabilities
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||