Join Now

Software architect working in Symbian/S60 area since 2000 and still being enthusiastic about mobility. Please visit my introduction page on Forum Nokia Champions web page.

Symbian Platform Security - hacked?

tote_b5 | 27 October, 2007 03:48

Well, 3:00am has already passed and I'm tired and sleepy. One thing doesn't let me sleep, though. I've just stumbled upon these articles (Exploring S60 with AllFiles and Goodbye S60 Platform Security, Hello CAPABILITIES!) and I can't believe my eyes: Platform Security hacked?!

Briefly, the solution is as follows:

  • Take a firmware update package (currently supported only by Nokia for their S60 phones).
  • Edit a well-isolated part of it, where all those capabilities (i.e. rights) are listed that a user can grant to a 3rd party application upon installation. Remove existing capabilities, add new ones, whatever.
  • Flash it.
Now you have such a phone (software) that allows you to give so powerful rights to any 3rd party application that they can do basically anything on the device. For example, your program can access DRM-protected content (you've downloaded it once and share it with others), browse other applications' secret folders, etc. You just need to
  • Extract a signed SIS (Symbian Installation) file
  • Add rights to it (whatever gives them more power)
  • Re-pack & sign it again
  • And install it
  • Although the Software Installer will notice that the application was not properly signed (== acquires for more capabilities than it can normally have), the user will be in such a position that he can grant those extra rights.
Actually, this is the approach that the author of the aforementioned articles followed with regards to a very popular file browser application: he added AllFiles capability to the program so that he could explore the entire file system, which he hadn't been able to do until then.

Unfortunately, I can't prove or disprove whether this solution really works, since I haven't even updated my N95's firmware yet (shame on me!). However, this guy seems to know what he was talking about and I sort of a believe him.

In any case, if what he wrote happens to be true, then I have a few questions:
  • Why on earth did Symbian publish such a confidential information that is useful solely for phone manufacturers? You know, the documentation of Software Installation Policy is a very internal thing, not anyone's business. You can see that it's enough if one talented person stumbles upon that documentation and uses it.
  • Why is a firmware package in such a format that anyone can edit it? I mean, locally on their machine. Okay, with such a low-level tool that very few people are familiar with, but it's still possible. Wouldn't it have made more sense to encrypt and sign the package so that
    • it cannot be decrypted by 3rd parties (well, easily at least)
    • it gets decrypted only on the target device right before flashing?
You know, I'm not a security expert, so I might easily be suggesting a stupid thing, but if there's any chance to do it that way, I think it's definitely worth the effort.
  • But even if it's not viable, then why does the firmware package update the whole system including the most critical parts? You could see that one can change the software installation policy this way. Why not make a process consisting of two steps:
    • User can download and flash a firmware package that updates the (vast) majority of the system, but it doesn't allow him to touch the critical parts
    • Those critical parts can either NOT be updated at all or only at service points.
I just really don't know what I've expected from Platform Security, but I have a feeling that in my secret dreams I thought it was unbreakable (I know, I'm naive). Again, I'm still looking for confirmation as to whether this solution really works, but I'm afraid that I already feel the bitter taste in my mouth. You know, a system that Symbian is proud of, operators love (some developers hate:) and even competitors acknowledge shall not be attackable and even if a security hole is discovered it shall be closed quickly without any major impacts. Nevertheless, I think this problem can be solved - hopefully very easily. But as to injecting the fixed version on to old phones, it will just take another firmware update. :)

Originally from mobile-thoughts.blogspot.com

Tote

Update: another fellow Forum Nokia Champion of mine, Antony Pranata, wrote an article about the very same topic. I think it completes my post in addition to confirming that the solution works. Worth reading.

General, S60, Symbian C++ | Next | Previous | Comments (29) | Trackbacks (0)

Comments

Re: Symbian Platform Security - hacked?

Sorcery-ltd | 27/10/2007, 16:38

Sorcery-ltd Well, no security is unbreakable but this is ridiculous (& embarrasing for Nokia). After all the man-years of effort that went into platform security, to have the user grantable capabilities listed in plain text in a software update package! What a thing to miss.

I can understand it being in the update because you might get your phone from a paranoid operator who doesn't allow any installs but their own certified ones or something like that. Then you'd need a software update that would effectively unlock the phone if you moved to another network.

However, this looks like the Unix security equivalent of storing your root password on your hard disk in plain text. It's just waiting for someone to find it. From the comments on the article it sounds like it had been spotted before it got out as someone has bricked their phone by trying the same thing on another model. Even with the file in plain text, if there was a CRC check for it stored somewhere else in the update image it would immediately be harder to crack. I agree completely though - the update should definitely be encrypted. The trouble is that the phone probably doesn't have enough RAM to decrypt a complete update, so it would have to be done on the PC - then it would still be in memory on the PC unencrypted at some point.

I had some involvement with the OTA software update stuff and that's a lot more secure than this.

I wouldn't be surprised if that article had disappeared early next week.... and this blog posting?

Mark

Re: Symbian Platform Security - hacked?

antonypr | 27/10/2007, 17:41

antonypr Hi tote,

Wow, we're writing the same posting almost at the same time.

I didn't post it on Forum Nokia Blogs because I am afraid someone will delete my posting. My posting on Forum Nokia Discussion Board on this topic has gone -> someone must have deleted it for some reasons.

Anyway, I couldn't believe either that the platform can be hacked so easily. What is more interesting, how come after 2 years, someone has figured this problem out. There is something fishy here.

Antony

Re: Symbian Platform Security - hacked?

tote_b5 | 27/10/2007, 17:51

tote_b5 Hmm,

This is the second comment now where it's foreseen that this post will not live here for so long ... you might know something.

As to the problem itself, I believe that Symbian (and/or Nokia?) will come out with the fix pretty soon, however, I'm afraid it won't solve anything for the existing phones. :(

Tote

Re: Symbian Platform Security - hacked?

Sorcery-ltd | 27/10/2007, 18:40

Sorcery-ltd Perhaps the real problem here is that the software update process is not in any way secure. The software updater shouldn't be re-flashing the phone with any old image. We have to sign applications before they can go on the phone, but you can just edit a software update and it will still be flashed.

I would have thought the immediate solution would be to withdraw the software update process until it is fixed!

Mark

Re: Symbian Platform Security - hacked?

Sorcery-ltd | 28/10/2007, 11:45

Sorcery-ltd One further thought that struck me, if it hasn't been done already. To align with the new changes to Symbian Signed, the obvious fix to this on the phone side is never to allow the user to grant AllFiles, DRM or TCB and also only to allow the most basic capabilities for self-signed applications regardless of the capabilities that are "user grantable" (since open signed is now available for freeware).

Mark

Re: Symbian Platform Security - hacked?

tote_b5 | 28/10/2007, 15:43

tote_b5 Mark,

While I fully agree with the idea of never alllowing the user to grant AllFiles, DRM and TCB, I don't see the difference between self-signed and open signed (w/o Publisher ID) from our point of view. You know, once the developer wants to give more capabilities to his app than what self-signed allows him, then he will simply submit his sis file to Open Signed and get a signed version back immediately. Please note that I presume that Symbian Signed doesn't check anything on the SIS file, for example, whether it acquires for more capabilities than it should. And it's reasonable to assume, since nobody at Symbian Signed will know what a given operator-branded phone allows the user to do.

Besides that, the set of "most basic" capabilities may effectively vary from operator to operator, since this is the sole purpose of keeping it in a text file that can change during customization. To be honest, I can't see why it's really worth for Symbian offering this option (i.e. to customize the "most basic" capabilities) to operators, because I don't think it's THAT advantegeous. But they must know it better.

Thanks for sharing your great ideas, btw! :)

Tote

Re: Symbian Platform Security - hacked?

Sorcery-ltd | 28/10/2007, 16:28

Sorcery-ltd Hi,

The difference between self-signed and open signed (w/o Publisher ID) is a matter for preventing application cracking. If someone cracks an applicaton and can redistribute a self-signed version then it is untraceable and can be installed on any number of devices. Open signed is restricted by to one IMEI in this case and so every user has to upload to open signed. That can be tracked and blocked.

For the most basic set of capabilities I'd just go for the manufacturer default user grantable ones. If some operator wants to block more and someone manages to enable the defaults on their phone it wouldn't exactly be a major security issue for anyone (or perhaps I just have very little sympathy for operators that want to lock down open phones completely).

Thanks for your blog posting, I know where to come to get the big news first!

Mark

Re: Symbian Platform Security - hacked?

tote_b5 | 28/10/2007, 17:40

tote_b5 Yeah, you're right in spotting the diff between the two types of deployment mechanisms. However, I still wonder 1: if Symbian Signed will really trace and eventually block applications, 2: how will they identify developers (since they don't require certificates, publisher IDs).

Tote

Re: Symbian Platform Security - hacked?

PushL | 28/10/2007, 17:15

This is certainly an excellent example of breaking a system by its weakest link. Using a secure cryptographic protocol doesn't make your program secure, and breaking such systems isn't generally done through the maths, but by finding flaws in the other tiers of the system.

I think this pic illustrates the topic quite nicely :-)

http://www.syslog.com/~jwilson/pics-i-like/kurios119.jpg

David.-

Re: Symbian Platform Security - hacked?

tote_b5 | 28/10/2007, 17:52

tote_b5 Well, as I've already pointed out, I can't see why the documentation of SW Intallation policy is published. That can be treated as sort of a flaw, negligence, I think.

On the other hand, adding more security to the package in terms of e.g. encrypting it would have made the firmware update process more secure. I agree with Mark, though, that it would have introduced more challenges for developers, too (e.g. how to decrypt a firmware package when the wholle system is just being overwritten), but imho it's simply such a critical part of the whole solution that it's not only worth thinking it over, but mandatory as well.

I must admit, though, that it's easier to criticize afterwards than trying to isolate each and every possible flaw during designing that might occur to the system. Now it's time to find a solution and I think and hope that this thread might help competent people to take the right step for everybody's pleasure.

Finally, your picture is great! You just had one for similar cases, right? :)

Tote

Re: Symbian Platform Security - hacked?

Mark Wilcox | 29/10/2007, 14:29

I think the idea with blocking cracked applications is that developers with publisher IDs report known cracks and applications uploaded to open signed are compared against them. Open signed then doesn't sign them. This still leaves the issues: 1) What about commercial applications that don't need restricted capabilities? 2) What about shareware developers that want to avoid the costs involved with publisher IDs and signing? I haven't given it much thought yet but the answers seem to be: 1) Just use some arbitrary restricted API just after your application starts up for no real reason other than preventing self-signed cracks. 2) Tough! Unless we abandoned self-signing all together which hurts the exact same developers and all freeware developers in development time.

Security through obscurity

puterman | 29/10/2007, 16:15

Tote, keeping things secret does not improve the security of a system. The problem isn't that this information is available, but that you're allowed to flash modified ROM images.

Nokia's on it

kevinauthor | 29/10/2007, 22:45

Gabor: thanks for bringing this discussion to the community. I agree with puterman that the issue is not who knows about an issue. In fact, IMO given that fact that this discussion is happening elsewhere makes it all the more important that those of us with a vested interest in the health of the S60 ecosystem have our say as well. As you can imagine, this issue is by now well known in the appropriate circles in Nokia and Symbian. One of the people involved in the issue asked me to add this update on what's going on, with more coming as more details become available: Nokia is aware of the claims presented in Symbaali.info and we are currently investigating the issue. Nokia takes all security issues seriously. We are determined to be active in the development of security controls and preventive measures.

What is definition of security?

Zdenko | 30/10/2007, 13:22

From my point of view security is here to protect myself from others. One of definitions of Computer Security: Confidentiality -- Ensuring that information is not accessed by unauthorized persons Integrity -- Ensuring that information is not altered by unauthorized persons in a way that is not detectable by authorized users Authentication -- Ensuring that users are the persons they claim to be. Symbian signed is here to protect me from malicious software. There is no way to make malicious software which will modify flash and reflash my phone.

Re: Symbian Platform Security - hacked?

chall3ng3r | 30/10/2007, 14:44

Gabor, nice find, and good discussion. from my poin of view, there's nothing to worry about. this is same as any user downloads and installs a cracked version of a software. and rule is same, do it on your own risk! no warranty, no support, can distroy your data, can make your phone useless, or even can include virus/trojan sending your data to server, etc. and generally, a normal user won't install anything suspecious. the hacking thing is possible after actually flashing the device with a patched version of firmware. i would not trust any thirdparty for nokia firmware updates until i read nokia's press-release about it :) doing it myself is harmful as well, as nokia won't provide any support after this. and i don't wanna lose it :) sencondly, as developer of SWF2Go, i get requests for adding /private folder security to Flash Lite applications. well, i can do it, and it works well with FL2 and later. but i have found even easier option to get access to so called *secure* contents of S60 installed applications. simply install a app into memcard, and read /sys /private or any other folder you like on PC using cardreader. crack the exe, make a sis again, post it on warez! so, where's the security to third-party apps? its was always open. i'll be watching this topic, and i'm also interested to know if nokia also takes care for third-party apps. i've read somewhere, that WM6 have option to encrypt contents of a memcard, so it can only be read by that specific device, cannot be read elsewhere. will this sort of protection can be good for developers? // chall3ng3r //

You're right, but it's still not good

tote_b5 | 30/10/2007, 15:06

@Zdenko: You're absolutely right. Why would I flash a hacked image on to my phone that allows malicious programs to access extra-sensitive information? Well, I certainly won't do that. On the other hand, geeks are still able to hack the system (I mean, their own) and can get access to information that's been hidden from them so far. Not to mention the "DRM-flaw": what if I have a hacked system where I'm in full control to give or not to give DRM capability to applications? Then I can do that I purchase one song for $1, retrieve the plain content from DRM framework (since I am capable of doing that) and then sell it for $0.5 to others.

Nokia's statement

Rippe | 30/10/2007, 15:23

Rippe

Nokia takes all security issues seriously. We are determined to be active in the development of security controls and preventive measures.

Nokia is aware that it may be possible to modify the software update package of a limited amount of device models. This type of intentional modification may make the mobile device inoperational. This issue has no impact to the user unless there's intention to do these modifications.

We have taken necessary steps to correct this issue, and it will be fixed in future releases. It's important to note that our latest device models are not impacted with this case.

Fortunatelly it's not easier (paths fixed)

alb3530 | 30/10/2007, 18:40

There should never be a way to actually change security parameters.
If there's a standard set of capabilities that are user-grantable in Symbian v9, they should be the only ones user-grantable, and system shouldn't be expecting changes in a single ini file.

But what we see is the system is watching a configuration file, as if it was waiting for the security parameters to be changed and all capabilities to be granted by user.

In S60 2nd edition, you can change some system parameters by taking advantage of the fact some configuration files have priority when they are in writeable drives.

For example, you find the file Z:/System/data/genericnif.ini in the device.Then you copy it to the same path of E: drive (E:/System/data/genericnif.ini) , edit "mtuvalue" using some text editor, save the changes, and you've just changed the real MTU value.You can also copy resource files located at Z:/System/data/ from other phones to E:/System/data/ of your phone and give applications new languages.

All i can say is fortunatelly (or unfortunatelly for some people) it's not even easier to disable platform security in S60 3rd edition.The file swipolicy.ini (a plain text file) is found under Z:/System/data/ , that's a public directory in real device.If you copy it to E:/System/data/ and edit it, giving user the power to grant all capabilities, the changes won't take effect even after phone is restarted.The ini file copied to E: (from Z:) luckily isn't considered.

But if such a small breach was open, the Symbian 9 PlatSec concept would be really ruined at least in some devices.Even i'd have already done it 6 months ago approximately, cause i've tried such approach in a N80.And anyone else could have done also even without reading the documentation about software installer's policy parameters, available at symbian site, cause the contents of swipolicy.ini are easily understandable by anyone with average knowledge of Symbian 9.

If Symbian really needed to keep platform security settings that flexible, they should at least have stored it in binary format instead plain text.

PlatSec configurations were the last thing that should be stored in plain text format.

Best regards

Why is "swipolicy.ini" @publishPartner?

Antony | 30/10/2007, 22:57

Hi,

It's been asked a couple of times here - why is the format of "swipolicy.ini" published in the Symbian Developer Library?

There are two answers to this question.

(1) It was intended to allow developers working within the emulator to re-configure the platform security settings during development so they don't even need to use developer certificates.

(2) Any security system that relies on file formats, function ordinals, or any non-user-specific information being kept secret is doomed. Security by obscurity is well established as a bad idea.

Cheers,
Antony

s/@publishPartner/@publishAll

Antony | 31/10/2007, 09:48

Hi,

The above posting should have said @publishAll rather than @publishPartner.

Cheers,
Antony

Symbian tagging policy

tote_b5 | 31/10/2007, 10:23

tote_b5

To those not familiar with Symbian's tagging policy (e.g. @publishPartner, @publishAll), you may find this document useful:

http://developer.symbian.com/main/downloads/papers/symbian_tagging_policy/Symbian_Tagging_Policy_&_Guidelines_v1.0.pdf

Tote

Re: Symbian Platform Security - hacked?

-miniME- | 01/11/2007, 08:07

hi are you all that paranoid because you cant help yourself or you do not understand the reason behind capabilities? they are not to protect yourself but to protect nokia and symbian. why software/hardware manufacturers can not understand that users can protect themself. nobody tells me i have to lock my house - i just do it because i know it is secure. the same with software - i install software/firmware only from a secure source. and every lock can be broken. so dont be so sure that that capabilitiy paranoidity is so clever and useful as you might think. bye

Re: Symbian Platform Security - hacked?

klaus peter | 01/11/2007, 08:36

hi are you all that paranoid because you cant help yourself or you do not understand the reason behind capabilities? they are not to protect yourself but to protect nokia and symbian.why do i have to pay them to protect themself. why software/hardware manufacturers can not understand that users can protect themself. nobody tells me i have to lock my house - i do it because i feel secure. the same with software - i install software/firmware only from a secure source - which makes me think secure. ... every lock can be broken. so dont be so sure that that capabilitiy paranoidity is so clever and useful as you might think. they should save their resources to produce usable software/hardware. just take the nokia e90 as an example - compared to the s80 communicator the e90 is useless. bye

Configuration

William | 01/11/2007, 13:07

I think configuration always should be in place, but why it is not encrypted in firmware package? Just use open key encryption and nobody could change firmware package.

Re: Symbian Platform Security - hacked?

bjoernQ | 01/11/2007, 14:25

I don't really see why there's so much agitation about this. Yes it seems to be too easy to modify the image. And it would have been not so hard to make it harder. On the topic about publishing sensitive information: I think that "security by obscurity" never worked and never will work in the future. But at the end the platform isn't compromised in my eyes. Yes by using a rude hack it's possible for a user to grant anything he likes to an application. But I guess such a user really knows what he's doing and ... Well, it's his own hardware. The user paid for it and he can do whatever he want with it. (No matter if we developers like this idea or not.) If there would be a possibility to do such things on a unmodified phone (without the user's knowledge) I would say it's a desaster. But this way I call it a storm in a teacup. I'm sure it will be fixed in the future but there's no need to worry so much about it.

Hacked?

Durr | 01/11/2007, 16:04

Is that little bit overstatement that Symbian platform security is hacked? If there is some application exploiting platform security _on_ device, then I would say it is hacked. The case itself is not dangerous but these kind of statements are so you really should think what you're saying. There is no any harm for normal users, as this is just a bug on PC side updater which can be exploited using updater software by yourself. So hardly any harm for anybody else than for yourself. I think this is a feature and should be available for anyone who wants to do this. It is your phone, do what ever you want with it.

Hacked? god bless

anonymous | 09/11/2007, 10:40

It's been said it's in ini file to make debugging more easy. It's very good that now it is more easy on phone too :)

Should be taken in positive sense

Kumar | 11/11/2007, 13:28

With the discovery of this issue i think both nokia and symbian should re think their stratergies as far as the developer community is concerned. Symbian 9.x is the most restriced platform i have ever worked in my life (come-on even java apps dont need a certificate to be installed and run). However i would urge nokia to open up the device manufacture capabilities for the developers so that developers can easily produce better apps for their platform which will ultimetly help them i suppose. The Qualcomm brew platform is an example. They would testenable devices so that developers can easily develop and test their apps. I think its time for nokia to take lessons from the outside world specifically Qualcomm and Android.

Nokia is quite positive

tote_b5 | 12/11/2007, 02:20

@Kumar: As you might have already read here and on other blogs, articles alike, this issue has eventually not been found as showstopper. It is critical, it will be fixed soon, however, it won't be used widely by everyone, most probably only by some hackers. As to learning from others: well, in general it's a principal to be followed. And I'm sure that Nokia does it already. On the other hand, referring to Qualcomm and Android might not be the best idea: we know basically nothing about Android, they haven't released their SDK yet. As to Qualcomm, I heard that you have to pay 20% of your revenue to them? Or something close. I don't think that it's a good idea and having a look at sales of devices I think it's rather Qualcomm who should take a lesson from Nokia, don't you think?
You must login to post comments. Login
 
 
Powered by LifeType 
     
     RDF Facets:
     
     
     qfnZtopicQUqfnBlogTopicZgeneralQ
     qfnZtopicQUqfnTopicZcppQ
     qfnZtopicQUqfnTopicZseriesE5f60Q
     qfnZtypeQUqfnTypeZBlogContentQ
     qfnZtypeQUqfnTypeZBlogE45ntryQ
     qfnZtypeQUqfnTypeZCommunityContentQ
     qfnZtypeQUqfnTypeZWebpageQ
     qmarsZlanguageQUxhttpE3aE2fE2fswE2enokiaE2ecomE2flanguageE2d1E2fenX