views:

231

answers:

4

Hi,

I have a shell script stored in the resources folder of my Cocoa app. If used improperly it could be dangerous (even though I have taken precautions to reduce exploits, such as using the absolute path to commands) so is there any way to encrypt the script in binary format, then decrypt it when it needs to be used?

Thanks

A: 

No. If the user will decrypt it to use it, then she can see (and intercept) the clear text at some point. If you think you have "shell-like" things to do, do them in C/ObjC... This can be your friend.

Massa
A: 

What you're asking for is essentially DRM. A different purpose (“security” instead of thwarting copyright infringement), but the same approach, with the same problems.

In order for the user to be able to normally use the (music|video|script), they must be able to decrypt it. You would do this for them under only the right conditions in your (player|app), but that doesn't matter: no matter how well you hide it, you still have to provide the user with all the technology and keys necessary to decrypt the (music|video|script), so that your (player|app) can do that.

And then, since the user has all the technology and keys necessary to decrypt it, an attacker can and eventually will uncover them all and decrypt the (music|video|script) on their own.

I second Massa's suggestion of switching away from a shell script. This doesn't completely eliminate risk: If an attacker can gain access to write to your shell script, they can gain access to write to a Mach-O executable just as easily. But editing a Mach-O executable is not nearly as easy, so you are at least raising the bar that way.

Peter Hosey
I think PCWiz is thinking about vectors of attack like "reading this shell script and changing -- for instance -- awk for a vulnerable version of awk, someone can make my program execute random code coming from the Internet without asking the user first etc."
Massa
Yeah, Massa is correct. To make it more secure I've used absolute paths to the commands (so that the PATH variable cannot be exploited to run unwanted code), but if an attacker gets write access to the script they could easily modify it.I'm going to try the compiler in Massa's link. Another idea I had was storing the script as an NSString inside a ObjC app, then writing the script to a temporary location, executing it, and then deleting it when the process is over. Would this work?Thanks
macatomy
There seems to be an issue with the ccsh compiler, I get this when I try to run it online:The requested URL /pcgi-bin/ccsh.cgi was not found on this server.
macatomy
About assemblying the string as a script somewhere: you would be running as the user, so, the user can see the script popping up at '/tmp' or something, so she can read it and (possibly) try an exploit. About ccsh.cgi not working: well, it worked Years Ago (TM) for me, sorry... you'll have to do the translation on your own apparently...
Massa
+3  A: 

It seems as if your concern is about people getting write access to the script and modifying it to run arbitrary code. You could keep a checksum for the script in the binary and compare that with the checksum of the script before you run it. Now, how do you stop people from editing the binary too? Code signing. In fact, if you keep the shell script in the app bundle then editing the script will break the signature of the bundle anyway.

Graham Lee
Thats a brilliant idea and I never really thought of it. I'm gonna try code signing.
macatomy
I tried following this tutorial: http://www.red-sweater.com/blog/514/development-phase-code-signing However it seems to raise no warning when the app has been modified
macatomy
look at the manual pages for codesign and csreq, and you'll see that you can set custom requirements and options. If you use the 'hard' flag then the app will die if its signature is broken.
Graham Lee
+2  A: 

This does not make a lot of sense. If an attacker has access to edit this script file, then they likely have access to edit any number of files, your application is less likely to be a security risk than any number of other things would be attacker could do.

Jacob