The Dumber Android Is, the Better, Say Experts

ZDOne writes "ZDNet UK is reporting that it will not be known until the Android software development kit comes out on Monday whether the Gphone will be strictly Java-based, but security experts claim that the less smart a phone is, the less vulnerable it is. Android developers should stick to a semi-smartphone platform because the Java sandbox can protect against the normal kinds of attacks, experts claim. The article also discusses some of the pros and cons of open vs. closed source security. 'The debate about the relative security merits of open-source as opposed to proprietary software development has been a very long-running one. Open-source software development has the advantage of many pairs of eyes scrutinizing the code, meaning irregularities can be spotted and ironed out, while updates to plug vulnerabilities can be written and pushed out very quickly. However, one of the disadvantages of open-source development is that anyone can scrutinize the source code to find vulnerabilities and write exploits. The source code in proprietary software, on the other hand, can't be directly viewed, meaning vulnerabilities need to be found through reverse engineering.'"

Comments

The most secure phone ever!

[reverseengineer]

Experts suggest security-conscious consumers consider the Western Electric 500 for their next smartphone. Lacking Java, JavaScript, ActiveX, and any other type of software, its spartan phone interface makes it virtually immune to any security vulnerabilities, and its innovative "rotary dial" system circumvents attacks possible on touch-tone phones. The casing is constructed of nearly indestructible Bakelite plastic, making it far more durable than the average smartphone. It does however require a service agreement with AT&T.

Re:The most secure phone ever!

[Billosaur]

I know it's meant to be funny, but strangely it's one of the reasons I haven't ditched my land-line to go all wireless. Mobile phones, especially those that try to do everything, aren't particularly good at anything and the more things you cram onto them, the greater their vulnerability profile. My wife just traded her old broken-down phone for a T-Mobile Shadow, and it's not the world's greatest phone (it runs Windows Mobile, but that isn't the root of the problem). The sound quality is horrendous and I haven't tried the MP3 player in it, but I'm not holding out hope.

I don't think we're at the point where phones can handle multiple tasks well, and using one is leaving yourself open to all sorts of mischief.

Re:The most secure phone ever!

[sm62704]

The rotary dial was a pain in the ass, but we never knew that until they invented pushbutton phones. And you had to look up your police/fire/ambulance in the phone book as there was no 9-1-1 service. Although most people just dialed "O" and when the lady answered (a real live human being, we didn't have voice mail either) you said "MY HOUSE IS ON FIRE" and she'd plug some plug on her switchbopard in and the fire department would come out.

But the Western Electric 500s were hackable! Some of them had no dials; businesses used the dial-less phones for where they wanted a low level employee, like the teenaged me at the ticket booth at the drive in theater, to be able to answer them but not make outgoing calls.

You could, however, "dial" them by repeatedly hitting the hangup buttons. So I was hacking your "unhackable" phone when I was 16. Actually I was cracking not hacking; I was hacking when I made guitar fuzzboxes out of $10 transistor radios and selling them for $50 each to other teenaged guitar players.

-mcgrew

PS- I've almost forgotten this, but in the Metro East St Louis area you could dial Bridge 1300 and a spooky noise cane out of the phone. The other kids said it was a ghost, I never had the heart to educate them about the reality.

Re:The most secure phone ever!

[sm62704]

In March 2006 We got hit by two tornados in one night. They went right through my neighborhood; the big tree behind my apartment looked like Godzilla had stomped on it. Half the utility poles were gone (as were a lot of buildings). My power was out for a week, my cable and internet were out for a month, and the landlines were all out as well.

My cell phone worked, however. It also was a very handy flashlight, as there was no power AT ALL anywhere near my apartment and boy, was it dark there at night! It's been years since I've had a landline.

-mcgrew

Huh?

[Matt867]

The dumber the smart phone is the better? Sounds like someone doesn't want to take their programming job seriously.

No wrong...

[El_Muerte_TDS]

The smarter the user is the more secure the phone is.

Re:No wrong...

[ceeam]

I thought all companies established long ago that "smart users" market is so tiny it can safely be ignored.

Did I miss something?

[zappepcs]

However, one of the disadvantages of open-source development is that anyone can scrutinize the source code to find vulnerabilities and write exploits. The source code in proprietary software, on the other hand, can't be directly viewed, meaning vulnerabilities need to be found through reverse engineering.'" If I remember right, that closed source thing... hmmm it seems to be working out really well for Microsoft.

Re:Did I miss something?

[DanielJosphXhan]

I think researchers and experts, when they talk about how exploits are found, fundamentally mistake the issues. No-one reads source to find exploits: that's the hard way to go about it. Closed source has only disadvantages in this regard, especially with fewer hands to fix things.

The "many eyes" argument fails as well, though, simply because many eyes do not make for better security. Many hands, on the other... um... hand, make for better response time. Open source code tends to be more agile because it's open.

Re:Did I miss something?

[Torvaun]

Did you just fix your own, or did you give back to the community that provided the app?

Re:Slasddot Grammary Advisory

[sm62704]

Isn't Ann Droid Cowboy Neal's latest girlfriend?

This is more "smart network, dumb device" logic.

[argent]

This is the old telecom industry chant. "Let's put the smarts in the network, they say, where they're out of touch and nobody can even get in to attack them, and have dumb devices out on the edge. Blue boxes are just a rumor."

By all means it should be possible to make dumb phones with Java sandboxes around third party software using Android. Yes, every layer of security is good. But it's not perfect... if you put everything you want to protect inside the sandbox, who cares whether someone breaks out of it or not?

Don't forget, the OS they're basing it on was designed for timesharing use, where it was common for people who had very different security requirements running code together on the same computer. Linux is a relatively young implementation of UNIX, but it's still using the same design that was able to keep some of the world's smartest CS undergrads from getting at the test papers and scores stored on the very same computers as their class accounts in the early '80s.

And some of the biggest vulnerabilities available to attackers on any platform are in application layers, in code doing what it was designed to do, with no individual component violating any constraint that a sandbox would prevent. The biggest problems are not implementation flaws, they're design flaws.

That's why, despite years of warnings from antivirus company experts, we don't have a flood of smartphone viruses... because PalmOS and Pocket PC and the rest don't have multiple internal firewalls like UNIX or Windows NT, but they're also not designed around a model of accepting code from untrusted sources and running it, like Windows is.

Get the application design right, and you're solid. Get it wrong, and you lose... no matter whether the kernel is inviolate or not.

proprietary security is like creationism

[Ba3r]

There is an overwhelming consensus amongst real security professionals that security is achieved through openness, not obscurity and closed source. Just look at the systems that hyper secure organizations like the NSA advocate. Those who continue to rail against open source systems as being insecure because "hackers can look at the source" (yeah but they can't look at my key) seem as out of touch as creationists.

Re:proprietary security is like creationism

[ichthus]

Ah, the new buzzword of the day, "consensus." There is hardly consensus on the superiority of openness in a security model. The scrutiny of many eyes argument is valid, but is arguably countered by a "probing of many eyes" for exploits argument.

And, there are good arguments for security through obscurity -- a concept all too quickly shot down here at Slashdot. For example, leaving a house key inside a fake rock in your garden is arguably more secure than leaving the key under your welcome mat. Another example, in which I have personally experienced the behefits of security through obscurity, is network ports. I used to have ann SSH server running on the standard, port 22. Every day, my logs showed numerous login attempts by unknown individuals trying to gain access to my system. Once I moved the server to a different, more _obscure_ port, though, my logs rarely show any connection attemps. Now, is this new port more secure? No. But, because it's further hidden it does afford _more_ security.

And, as for your final, fanny-pat statement to the "consensus" of the "scientific" world: I'm a creationist, and I'm not out of touch. For me, the incalcuably small probability of spontaneous generation of a lifeform able to be nourished by it's environment and then able to reproduce is not a large-enough foundation on which to build a scientific consensus.

Android

[hansamurai]

This is the second article about Google Android today already and we never even discussed the original announcement, just what Ballmer and now ZDNet have to say. But I suppose there will be a long line of articles in the future so maybe it won't matter, just seems odd.

I think you've come to the wrong conclusion.

[argent]

First: She's always like, "I'm sorry, I don't know who you are." her policy is to never buzz anyone in. She angered the chairman once over it, who was talked out of firing her precisely because he's in the office like 3 times a year. She won't buzz people in and she's unrepentently steadfast about it. She's dumb as dirt.

She's not dumb, she's smart.

Second: Simple systems are more likely to be secure than more complex systems in general as they are less prone to component failure.

The Java sandbox is an extremely complex system, with trusted and untrusted code running in the same address space calling the same libraries, with the security managed by code that's also using the same libraries and running in the same address space. I am honestly amazed that it's worked as well as it has.

The multiuser protection in UNIX is an extremely simple system, with untrusted code running in separate address spaces and, traditionally, with the ability to run security applications using no shared libraries at all. It's also proven extremely effective, and it has the advantage that even if flawed code is run those flaws do not automatically provide an escape route from the whole sandbox the way flaws in libraries called from Java do.

This is not to say that the Java sandbox isn't a useful tool, but rather to say that when analyzing the security of the system as a whole the fact that an application is written in Java should not be given the kind of importance that it seems to be getting here.

Still wrong:

[norminator]

Actually... I think it should be: the smarter the user thinks they are, the less secure the phone is. Reminds me of my PC Tech Support days long ago... "My neighbor came over, and he knows a lot about computers, so he started fixing my computer, now it won't start..."

Can you say DLL Hell?

[erroneus]

People will want to make their phones do special and complex things. To facilitate this, they will write API libraries that other parties will also use because the phone's basic API will not support much.

The results of a non-robust API will be large amounts of object code libraries being built and installed, varying dependencies and conflicts and on and on. As much as possible, it would be best to maintain the API from a single point. This will also enable a much smoother user experience since people won't be forced to create their own GUI libraries and the like.

It needs to be complex and it needs to support everything... at least potentially. Ideally, everything except the data and the object code should be provided through the OS and OS supplied libraries. This would best guarantee compatibility and stability. But we know it won't happen that way. We can't even get KDE and GNOME unified. Some "smarter-than-you-and-me" guy will write something that will be rejected by the masters of the API but will be used by a variety of other developers and then it all begins.

And what happens when the OSS community rebels? Recall how XFree86 became stagnant and people rebelled to create X.org? That wasn't a disaster, but what happens when it happens on users' phones? And will there be multiple phone distros? And will AT&T and T-Mobile try to lock them up? And if they "can't" then will they block those phones from being used on their network (in spite of laws to the contrary)?

Re:Open is better

[starfishsystems]

From the parent article:

The debate about the relative security merits of open-source as opposed to proprietary software development has been a very long-running one

Indeed. The principle of open security was first proposed by Auguste Kerckhoffs in 1883.

Any time security depends on the secrecy of some mechanism, that security is pepetually at risk. All these millions of instances of the same vulnerable mechanism, no way to tell in general whether their security has been broken, and -- as you point out -- a certainty that the vulnerable secret cannot be contained.

In what way exactly does this remain a matter of debate?

Reverse engineering not required

[tjwhaynes]

The source code in proprietary software, on the other hand, can't be directly viewed, meaning vulnerabilities need to be found through reverse engineering.'

This is so wrong it isn't funny. I need know NOTHING about the internals of a program to exploit it - I only need to find a set of inputs that make it crash in interesting ways. Buffer overflows can be trivially used to redirect a running program to jump to a stack frame supplied as part of the crafted inputs. There are other ways to play the game against binaries without reverse engineering.

Cheers,
Toby Haynes

Re:From the wha...?

[Kryten107]

The world needs more Red Dwarf references. And it's spelled Kryten. I should know.

Re:Slasddot Grammary Advisory

[smittyoneeach]

Thought she was Ann Flatable.