CODEWITHSUNDEEP
iosobjective-csecurity
Romain TAILLANDIER
Romain TAILLANDIER

Reputation: 1995

Prevent Heap inspection for NSString

I am trying to improve our code security. We use a static code analysis tool named CheckMarx. The tool is new at the company, in particular we are the only team to work on iOS with objective C.

I have a parameter class to connect to a server, it contains server address, port, few parameters, login and password The password should not be taped by user but. It is retrieved as a token from another strong authentication service each time needed. It should not be saved as persistant value (because it change every time), so keychain do not looks to answer my need. For the demo project, the user will tap it in a textField. That demo projet is under security validation.

When running the analysis, I get a 'heap inspection' vulnerability : https://cwe.mitre.org/data/definitions/244.html about the password. In theory i understand the problem I should clear the memory space where the password was stored, but I have no idea to achieve this, in objective C.

The password is an NSString, which is immutable, so if i try to overwrite the NSString, I will only create a new string and let the old one somewhere in the heap. (And if I overwrite it anyway in dealloc method, i get another warning saying that hardcoded string is a bad practice for password). renaming the variable into another dummy variable name like MyDummyPropThatContainsData

1) ARC will clear the pointer but i do not think it will clean up the heap. So i believe this is not a false positive. Am i wrong ?

2) I have try using a NSMutableString allocated with MAX_SIZE_PASSWORD. I use the setString method to set the variable (at the same place). I erase it in the dealloc method by calling setString method with a dummy value of exactly MAX_SIZE_PASSWORD. It removed the warning, is it a good practice ? I am quite sure that this should be another warning saying that hardcoded string is a bad practice for password, but it is not detected. I suppose the bad practice remains ...

3) I have thought to use a char* so i would be able to memset it later, but it sounds bad to me. I am afraid that it could be a reliability and maintenance issue. Is this could solve my problem ? is it recommanded with ARC to manage myself allocation of char * everywhere I need to manage passwords ?

I have found nothing in objective C to prevent Heap Inspection vulnerabilities. Is there some common way to prevent that in objective C ? Do you know some good points where to start ?

Any help appreciated !

Upvotes: 3

Views: 1389

Answers (1)

adonoho
adonoho

Reputation: 4339

One comment and also a recipe. In a system that supports either no swap or an encrypted swap, nil-ling out the data is mostly moot. The main remaining attack to discovering the password is directly attaching to the running app. I use the keychain modes to defend against this attack.

The goal is to erase the secret on the heap.

As I keep passwords in my keychain, they are returned as an NSData BLOB. This is key. You can then initialize an NSString with the BLOB's bytes and disallow the string from owning them (freeWhenDone: NO). While I cannot guarantee that NSString does not copy the data, it appears to be the case. (Make sure you do not specify an encoding that causes the NSString to have to recast the data. UTF-8 generally works fine.)

When you are done with the password NSString, release it. (Using ARC, set it to nil.)

Now the key to cleaning up the heap is to use the NSData routine to enumerate through each of its byte arrays, typically there is only one, and then set the bytes to NULL. If you prefer, you can bang in random bytes. You can now release the NSData BLOB.

Yes, this breaks all of the rules of mutability preservation. That is what unsafe pointer operations are for. They are unsafe. But you are also doing something in a specific place for a very good reason.

As this is a rather delicate operation, I hesitate to share code that implements the above algorithm. IMO, you need to be responsible for your own security hygiene.

If the above isn't clear, I'm happy to refine the answer further.

Upvotes: 5

Related Questions