Gabor Torok's Forum Nokia Blog - Symbian Platform Security - hacked?

Nokia is quite positive

tote_b5

@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?

Should be taken in positive sense

Kumar

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.

Hacked? god bless

anonymous

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 :)

Hacked?

Durr

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.

bjoernQ

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.

Configuration

William

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.

klaus peter

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

-miniME-

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

Symbian tagging policy

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

s/@publishPartner/@publishAll

Antony

Hi,

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

Cheers,
Antony

Why is "swipolicy.ini" @publishPartner?

Antony

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

Fortunatelly it's not easier (paths fixed)

alb3530

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

Nokia's statement

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.

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

tote_b5

@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.

chall3ng3r

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 //

What is definition of security?

Zdenko

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.

Nokia's on it

kevinauthor

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.

Security through obscurity

puterman

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.

Mark Wilcox

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.

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

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

PushL

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.-

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

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

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

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

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

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

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