Security
Remotely wiping mobile phones
A 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 vulnerability
For 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 Works
Danny 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
| Package(s): | couchdb | CVE #(s): | CVE-2010-2953 | ||||||||||||
| Created: | September 9, 2010 | Updated: | September 21, 2010 | ||||||||||||
| Description: | From the Debian advisory: Dan Rosenberg discovered that in couchdb, a distributed, fault-tolerant and schema-free document-oriented database, an insecure library search path is used; a local attacker could execute arbitrary code by first dumping a maliciously crafted shared library in some directory, and then having an administrator run couchdb from this same directory. | ||||||||||||||
| Alerts: |
| ||||||||||||||
cvsnt: privilege escalation
| Package(s): | cvsnt | CVE #(s): | CVE-2010-1326 | ||||
| Created: | September 14, 2010 | Updated: | September 15, 2010 | ||||
| Description: | From the Debian advisory:
It has been discovered that in cvsnt, a multi-platform version of the original source code versioning system CVS, an error in the authentication code allows a malicious, unprivileged user, through the use of a specially crafted branch name, to gain write access to any module or directory, including CVSROOT itself. The attacker can then execute arbitrary code as root by modifying or adding administrative scripts in that directory. | ||||||
| Alerts: |
| ||||||
django: cross-site scripting
| Package(s): | Django | CVE #(s): | CVE-2010-3082 | ||||||||||||
| Created: | September 13, 2010 | Updated: | October 14, 2010 | ||||||||||||
| Description: | From the Django advisory:
As of the 1.2 release, the core Django framework includes a system, enabled by default, for detecting and preventing cross-site request forgery (CSRF) attacks against Django-powered applications. Previous Django releases provided a different, optionally-enabled system for the same purpose. The Django 1.2 CSRF protection system involves the generation of a random token, inserted as a hidden field in outgoing forms. The same value is also set in a cookie, and the cookie value and form value are compared on submission. The provided template tag for inserting the CSRF token into forms -- {% csrf_token %} -- explicitly trusts the cookie value, and displays it as-is. Thus, an attacker who is able to tamper with the value of the CSRF cookie can cause arbitrary content to be inserted, unescaped, into the outgoing HTML of the form, enabling cross-site scripting (XSS) attacks. This issue was first reported via a public ticket in Django's Trac instance; while being triaged it was then independently reported, with broader description, by Jeff Balogh of Mozilla. | ||||||||||||||
| Alerts: |
| ||||||||||||||
libglpng: arbitrary code execution
| Package(s): | libglpng | CVE #(s): | CVE-2010-1519 | ||||||||||||
| Created: | September 13, 2010 | Updated: | September 15, 2010 | ||||||||||||
| Description: | From the CVE entry:
Multiple integer overflows in glpng.c in glpng 1.45 allow context-dependent attackers to execute arbitrary code via a crafted PNG image, related to (1) the pngLoadRawF function and (2) the pngLoadF function, leading to heap-based buffer overflows. | ||||||||||||||
| Alerts: |
| ||||||||||||||
mountall: arbitrary code execution
| Package(s): | mountall | CVE #(s): | CVE-2010-2961 | ||||
| Created: | September 9, 2010 | Updated: | September 15, 2010 | ||||
| Description: | From the Ubuntu advisory: Alasdair MacGregor discovered that mountall created a udev rule file with world-writable permissions. A local attacker could exploit this under certain conditions to cause udev to execute arbitrary commands as the root user. | ||||||
| Alerts: |
| ||||||
ntop: denial of service
| Package(s): | ntop | CVE #(s): | CVE-2009-2732 | ||||
| Created: | September 14, 2010 | Updated: | September 15, 2010 | ||||
| Description: | From the Mandriva advisory:
The checkHTTPpassword function in http.c in ntop 3.3.10 and earlier allows remote attackers to cause a denial of service (NULL pointer dereference and daemon crash) via an Authorization HTTP header that lacks a : (colon) character in the base64-decoded string. | ||||||
| Alerts: |
| ||||||
ocsinventory: multiple vulnerabilities
| Package(s): | ocsinventory | CVE #(s): | CVE-2010-1594 CVE-2010-1595 CVE-2010-1733 | ||||
| Created: | September 13, 2010 | Updated: | September 15, 2010 | ||||
| Description: | From the Mandriva advisory:
Multiple cross-site scripting (XSS) vulnerabilities in ocsreports/index.php in OCS Inventory NG 1.02.1 allow remote attackers to inject arbitrary web script or HTML via (1) the query string, (2) the BASE parameter, or (3) the ega_1 parameter. NOTE: some of these details are obtained from third party information (CVE-2010-1594). Multiple SQL injection vulnerabilities in ocsreports/index.php in OCS Inventory NG 1.02.1 allow remote attackers to execute arbitrary SQL commands via the (1) c, (2) val_1, or (3) onglet_bis parameter (CVE-2010-1595). Multiple SQL injection vulnerabilities in OCS Inventory NG before 1.02.3 allow remote attackers to execute arbitrary SQL commands via (1) multiple inventory fields to the search form, reachable through index.php; or (2) the Software name field to the All softwares search form, reachable through index.php. NOTE: the provenance of this information is unknown; the details are obtained solely from third party information (CVE-2010-1733). | ||||||
| Alerts: |
| ||||||
phpMyAdmin: cross-site scripting
| Package(s): | phpMyAdmin | CVE #(s): | CVE-2010-3263 | ||||||||||||||||
| Created: | September 10, 2010 | Updated: | September 21, 2010 | ||||||||||||||||
| Description: | From the Red Hat bugzilla:
phpMyAdmin (x < v3.3.7) improperly sanitized server name provided to the setup script. An attacker could use this flaw (under certain installations) to conduct cross-site scripting (XSS) attacks (execute arbitrary HTML or scripting code). | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
samba: remote code execution
| Package(s): | samba | CVE #(s): | CVE-2010-3069 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 14, 2010 | Updated: | November 11, 2010 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | The Samba server does not perform proper array boundary checking when parsing Windows security identifiers. A malicious client could exploit this vulnerability to run arbitrary code under the ID of the samba server. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
slim: arbitrary code execution
| Package(s): | slim | CVE #(s): | CVE-2010-2945 | ||||||||||||
| Created: | September 9, 2010 | Updated: | September 15, 2010 | ||||||||||||
| Description: | From the Red Hat bugzilla entry: It was reported that SLiM versions prior to 1.3.1 assigned logged-in users a predefined PATH which included './', which could allow for unintentional code execution. | ||||||||||||||
| Alerts: |
| ||||||||||||||
webkitgtk: multiple vulnerabilities
| Package(s): | webkitgtk | CVE #(s): | CVE-2010-1780 CVE-2010-1782 CVE-2010-1784 CVE-2010-1785 CVE-2010-1786 CVE-2010-1787 CVE-2010-1788 CVE-2010-1790 CVE-2010-1792 CVE-2010-1793 CVE-2010-2648 CVE-2010-2264 CVE-2010-1783 | ||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 15, 2010 | Updated: | March 10, 2011 | ||||||||||||||||||||||||||||||||||||||||||||
| Description: | The webkitgtk 1.2.4 release fixes a long list of scary-looking vulnerabilities. | ||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>