|
|
Subscribe / Log in / New account

EFF: Don't Sacrifice Security on Mobile Devices

EFF: Don't Sacrifice Security on Mobile Devices

Posted Jan 24, 2011 19:01 UTC (Mon) by cmccabe (guest, #60281)
In reply to: EFF: Don't Sacrifice Security on Mobile Devices by foom
Parent article: EFF: Don't Sacrifice Security on Mobile Devices

In Daniel J. Bernstein's "Thoughts on Security after Ten Years of Qmail 1.0" (http://cr.yp.to/qmail/qmailsec-20071101.pdf), he points out that "chasing attackers" is more of a distraction than a solution to security problems. As he writes, security patches "do nothing to fix the software engineering deficiencies that led to the security holes being produced in the first place." Instead, Dan thinks the best idea is to minimize the size of the trusted code base-- i.e., the code that needs to be audited for security bugs.

Android certainly seems to have minimized the trusted code base, compared to a typical Windows or Ubuntu install. Since most software is Java, there are no such things as buffer overflows, return-to-libc attacks, and so on. There is a better security model-- for example, random applications can't just read and write the user's data unless they've specifically been given that capability. Another advantage Google has against malware is that it can remove known malware from Google Market, which is the only way that most users get their applications.

Of course, since Android now supports native code, hackers can attack the kernel API. I kind of hate to admit this, but that API might be one of the more vulnerable parts of the system at the moment.

One thing that annoys me about Android is that you can't install an app without granting it all the security capabilities it wants. This has led to me uninstalling things like the Pandora radio application, because it just wanted too much power.

A lot of people think that the computer security battle has more or less been lost on the desktop front. Developers keep adding features, which also add security bugs, and hackers keep finding those bugs. It's a never-ending cycle which will never lead to real security. In order to really start winning, we need to change the game so that new bugs get put in at a lower rate than they're discovered. Higher level languages and better security models are a good start. You don't have to constantly patch applications and libraries unless they're part of the trusted code base.


to post comments

EFF: Don't Sacrifice Security on Mobile Devices

Posted Jan 24, 2011 20:16 UTC (Mon) by foom (subscriber, #14868) [Link] (1 responses)

> Of course, since Android now supports native code, hackers can attack the kernel API. I kind of hate to admit this, but that API might be one of the more vulnerable parts of the system at the moment.

I think the image display libraries and the web browser are still prime attack targets (written in C, note!). Think of an MMS message, spam email, or webpage that takes control of your phone. And of course emails or MMSes itself to all your contacts to continue propagation.

EFF: Don't Sacrifice Security on Mobile Devices

Posted Jan 25, 2011 1:12 UTC (Tue) by cmccabe (guest, #60281) [Link]

> I think the image display libraries and the web browser are still prime
> attack targets (written in C, note!). Think of an MMS message, spam email,
> or webpage that takes control of your phone. And of course emails or MMSes
> itself to all your contacts to continue propagation.

Remember that just because code is written in C, doesn't mean it's part of the trusted codebase.

For example, the Chrome web browser is sandboxed. So if you can buffer overflow a webkit HTML rendering thread (not a very hard task), you get control of... what is displayed on the screen. Nothing else.

There was an article on the sandbox at http://lwn.net/Articles/347547/

I'm not 100% sure if Google has deplyed the seccomp stuff yet on Chrome for Android (I haven't checked the source.)

On the other hand, I'm guessing that the image display libraries are built into Dalvik itself. They probably are part of the trusted codebase.

C.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds