What if your phone could destroy an entire network base station with just a single command? Would you rework the OS so safeguards would be in place, or would you prefer to hold back every third party application, Canute style, hoping nothing gets through? The attitude of Apple and Symbian to this issue reflects the benefits of the open platform that Symbian and the upcoming Foundation promote, in my opinion. Read on.
Read on in the full article.
never thought jailbreaking ur iphone could lead to such severe ramifications.
It is not that Symbian has better security, even hackers are not interested in symbian.
I don't know if we should read that much into Apple's article. It sounds like huffing and puffing from lawyers looking to build a case.
Unregistered wrote:It is not that Symbian has better security, even hackers are not interested in symbian.
Rubbish.
Being able to charge a users sim account for accessing premium content or receving those texts which have reverse chanrges on them would be very appealing to some wannabe hacker.
This is to do with buggy software rather than security models.
e.g I wrote a program once which used a Symbian API which required a particular capability (which is normally available to anyone). I happened to have no capabilities in my app since i didn't think I needed it.
Anyway, when running on target hardware the device died and rebooted. It took me ages to figure out that it was because i needed this capability in my MMP file.
Now the interesting thing here was that Symbian only tested assuming that you have the capability and did not test apps that didn't (since it was a basic capabillity).
Anyway, since I'm interested in this sort of thing. I removed the capability and made the app autostart and sure enough - my phone is bricked.
The reason is that the app accidentally causes ESOCK server to fallover and panic rather the app failing itself. This means that any protection added to the autostart list is mute.
Allabout symbian are way too naive and trusting about the security messages given out by Symbian.
In the new open world. Thing about the new avenues of attacks. I could submit a change to the dreadful perl scripts that make up the SYmbian build system which detects if the kernel is being compiled and insert a backdoor into the code before it's compiled. In fact, it wouldn't have to be the kernel - it could be any subsystem or plugin.
Anyway. Apple are probably talking shit since cell tower software are designed to be resilient. And all the baseband software runs on a separate chip to the application processor - so people who are jailbreaking for legitimate reasons have no cause to try and hack the baseband processor (which no doubt has its own checksums and security).
Of course the baseband processor might have a bug which could bring down the tower, but it's probably just as easy to stimulate it with the appropriate AT commands.
Symbian devices have around 10 million lines of code from 255+ or so partners. If you think every line of code is checked (a lot is delivered as binaries), then you are a fool.
On a similar subject the artilce "How To Hijack 'Every iPhone In The World'" on Forbes.com makes interesting reading.
Oh please! Usual AAS tripe! If bloody Symbian is so amazing and fun to develop for and so secure then why does Apple have billions of downloads with tens of thousands of apps in 1!!! Year as with one phone model as opposed to Symbians crap loads of years and MILLIONS of varied devices??
I'm liking AAS less and less these days, I mean I know you have to cater to your audience and remind everyone how "amazing" Nokia and Symbian are (as you hardly ever cover any other symbian device) but the blatant in-your-face rubbish posted here sometimes is for some strange reason maddening :-/
This site IMO is going Downhill and was MUCH better and less biased when I came here in the N95 days, maybe it's because the competition has increased so therefore the "reminding" of how awesome Symbian/Nokia are has to too?
Sorry for the rant, and I know you's are only boosting your chosen OS, but sometimes you guys are far too blind/passionate about it.
Rant over 😛
Wow, this has struck a nerve.
However, as someone with a security background (sold my previous internet security company to IBM), I can assure doubters that Symbian has a much more sophisticated approach to security than Apple.
Even from an external perspective it's obvious that Apple is desperately trying to keep things simple for themselves (and thus, hopefully for the customer, although that doesn't always follow). The restrictions on third party apps are there for Apple's benefit (so they don't have to do the hard work Symbian has done and/or make their dev. environment as complex as Symbian's). The AppStore restrictions (eg. Google Voice being banned because of alleged pressure from AT&T) are similar, with Apple maintaining a single store worldwide so everyone is limited to the lowest common denominator.
This is an Apple tradition.
A Symbian tradition is exposing the complexity to the developer. 😉
The poster (Serious 60) who talks about a phone crashing when using an API without a required capability certainly points out the complexity of implementing fine grained capabilities, but it's notable that the capability wasn't allowed through, which would have been a security failure.
In other words, the poster hadn't discovered a security flaw, but rather a device flaw. (The poster even says so themselves, so I'm not quite sure what their point is.) Perhaps they're implying that this flaw could be used as an attack, but where's the motive apart form simple maliciousness? Not a good motive for the effort required to achieve widespread delivery. Note that the motive of the vast majority of malware is the same as the motive for most crime: filthy lucre (money).
So it doesn't make sense to follow this up with the rather naive comment about submitting a change to a core build perl script to insert a backdoor into the Symbian codebase. This shows a lamentable understanding of (a) how software engineering in general works and (b) how the Foundation's practices work (you can read about them -- in this case the package owner is responsible for reviewing all changes and it's incredibly unlikely that such a change would get by even the most distracted package owner).
Also, I have it on good authority (from one of our engineers who used to work in Symbian) that Symbian's processes were so heavy that they almost stifle innovation -- they are constantly striving to balance agile with robust (you can see that in David Wood's blog). I suspect that Nokia is a bit different, though...
In any case, we can all see what the Foundation's processes are, and they are certainly designed to ensure all submitted code is reviewed. (That doesn't guarantee anything, of course.)
Also a couple of other comments are amusing: the idea that hackers are not interested in Symbian is ludicrous. There are plenty of crackers out there working to pirate every third part app, and the installed base of Symbian is vast, so it's a very juicy target. It's just a harder target than something like Windows or even Mac OS. Things like the despised descriptors actually have a huge security payoff.
Finally, the comparison between the Apple AppStore and Symbian's failure (and let's be honest, it is a failure up to now) has nothing to do with security implementations, and Symbian's sophisticated security framework does the opposite of making it fun to develop for (which explains why there are not a surfeit of trivial apps -- it's just too hard to make an app of any kind).
Just some thoughts.
>>A Symbian tradition is exposing the complexity to the developer. 😉
Symbian has a history of making appalling design decisions in its API. It's almost as if the engineers at symbian never wrote applications themselves before writing services for app developers.
>> In other words, the poster hadn't discovered a security flaw, but rather a device flaw.
erm. Most security flaws are just bugs. Look how many SMS overun issues there have been on mobiles.
I choose this example since the topic of the post was about "how to bring down a tower with one line of code"
the post seemed to be about destruction of property (base stations) rather than security of data. And my point perfectly illustrates how a DOS attack can be generated exploiting a bug in the system.
A DOS attack can be valuable (if stupid). It's called data ransom. You don't have to be in possession of someone's data to hold it to ransom. If you stop them from being able to access it in the way i describe above, then you can add then sell them solution to access their data again.
(ok this is a contrived example, but the principle is the same).
Symbian has a fairly good security architecture which has no concept of user privileges (no sudo here). But it doesn't make it any less susceptible to buffer overruns in 3rd party code.
Now things like descriptors provide bounds checking, but increasingly a Symbian rom contains a huge volume of open source code (sqlite, webkit, freetype, helix etc) and with that comes a whole host of vulnerabilities.
>> Symbian's processes were so heavy
That's Symbian LTD. Not the foundation. Symbian foundation has scattered ownership and not all parts will be vetted in the same way.
>>rather naive comment about submitting a change to a core build perl script to insert a backdoor into the Symbian codebase.
I think you are being naive. What stops a Bernie Madoff of engineering being a 'trusted' member of the community.
In my post I'm merely highlighting some of the more creative ways at exploiting a widespread
OS.
I think you are forgetting that Symbian foundation do not review code before it goes into the final device.
It goes S^n -> handset manufacturers + ISVs +3rd party apps -> ROM -> Shops.
in the symbian world. all those folk in the chain get access to the FULL source code and a rogue employee can easily generate a vulnerability without raising much suspicion.
Hell, one release of S60 accidentally had logging enabled in one of the networking components which printed out all your loggin and passwords details for your email accounts.
I don't want to labour the point. But an open system has so menu avenues for attack - my perl example was just one of the wildest ideas. Most of the avenues come from the fact that software is too complex to test now.
>>the idea that hackers are not interested in Symbian is ludicrous
I think this is more of an old joke that Symbian APIs are so illogical and idiosyncratic that hackers are better off going straight and getting a job at the supermarket than going through the stress of writing symbian code.
I don't understand why you launch into a tirade of ad-hominen attacks calling me and that I show lack of understanding. You sir are an asshole