Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

How to ensure that a supported version of my script is being executed?

by sanbiswa (Initiate)
on Aug 21, 2012 at 06:46 UTC ( #988600=perlquestion: print w/ replies, xml ) Need Help??
sanbiswa has asked for the wisdom of the Perl Monks concerning the following question:

I have a Perl script ("use"-ing a number of packages written by me) which is supposed to be run from a particular directory (this is the "supported" version of the script). Some smart users are making a local copy of this script and using that after making whatever modifications they want. How to prevent this?

My users can run the script from various platforms (different flavors of Unix and Windows). They run the script typically from command line (or from other scripts) but never from a web interface.

I have an Oracle database which I make use of. By running the modified versions of my script, users can insert/update junk data into the database which I want to stop.

I can think of various ways to check if the absolute path (obtained using, e.g. FindBin) of the script run is a "supported" one, but the problem is that this check is done in the Perl file itself and the malicious user can easily remove that part of the code from his local copy.

Due to the huge number of platforms I have to support, I don't want to do the above check in, e.g. C (where I can have a complied version of the code) as to manage the compilations would be a nightmare then.

Any suggestions would be appreciated.

Comment on How to ensure that a supported version of my script is being executed?
Re: How to ensure that a supported version of my script is being executed?
by moritz (Cardinal) on Aug 21, 2012 at 07:09 UTC
    I have a Perl script ("use"-ing a number of packages written by me) which is supposed to be run from a particular directory (this is the "supported" version of the script). Some smart users are making a local copy of this script and using that after making whatever modifications they want. How to prevent this?

    Make your users sign a contract not to change the code, and only to run the script in the supported way.

    Or only provide the software "as a service", i.e. have it run on machines that you control.

    I'm serious. There's no reliable way to ensure the integrity of a program (be it Perl, C or anything else) on a machine that somebody else has administrative access to.

    Update: as davido++ pointed out, there's a third option: you can make your code flexible enough and provide an API for extensions. Then others don't feel a need to change your code.

      Thanks for your reply. So you're saying it's not doable, right?

      Not sure why you think the same even for C where all the user gets is the binary and there's no chance of him changing the code!

        So you're saying it's not doable, right?

        Not doable on a technical level, no. Unless you're willing to go the software-as-a-service route.

        Not sure why you think the same even for C where all the user gets is the binary and there's no chance of him changing the code!

        What makes you think that it's impossible to change binaries? Disassemblers, debuggers and other tools exist.

        There's a whole industry around DRM, digital rights/restriction management, and basically all the protections against copying have been cracked. And they all come in binary files, one way or another.

Re: How to ensure that a supported version of my script is being executed?
by ig (Vicar) on Aug 21, 2012 at 07:47 UTC

    Even if you lock down your application, if your users have permission to enter junk data in your database they can write their own application to do it, or just connect to it with Excell and Access and start entering junk.

    If you want to prevent them entering junk, remove direct access to the database and only let them run stored procedures which validate the inputs.

      Thanks for your response. I do have all the mechanisms in place (stored procedures with proper grants etc.) so that the users can modify the database only via this script. So his modified script gets into the database and writes x instead of y; how to prevent that? Validating the data entered is not always possible in my case, so my idea was to ensure that the script that entered such data is the correct one.

        How do you prevent the user entering x instead of y in your script?

        If your script doesn't allow the user to enter x or y, but derives y from some other input, then don't accept either x or y as input to your stored procedure but, rather, accept only the primary input from which y can be derived.

Re: How to ensure that a supported version of my script is being executed?
by flexvault (Parson) on Aug 21, 2012 at 13:52 UTC

    sanbiswa,

      Due to the huge number of platforms I have to support...

    At one time some *nix versions allowed you to 'chmod a+x-r-x YourScript.plx' and the script could execute, but someone couldn't copy it, modify it or delete it. I think the 'user:group' had to be 'bin:bin'. It may not work with your platforms, but you could try it.

    Your problem is not a technical one, but a management problem!

    Have you mentioned this to the manager(s) of the problem user(s).

    Why do they want to allow this?

    Good Luck! You need it...Ed

    "Well done is better than well said." - Benjamin Franklin

      Greetings, I'm not sure what kind of an environment you are working in. But you should have little difficulty controlling who uses your script(s), and from where.
      For example, you could prevent exec(ing) based on an eval as to where the posted || query is comming from ( $local || $remote), or even from where the script has been exec(ed) within the system itself (get $pwd || $cwd). This is a farily trivial matter. You could perfom the eval(s) from within the script, or, if Apache for example, within the server itself. Example:
      Create a var(iable) : $ENV{SERVER_NAME};
      create a Condition : unless (defined($ENV{SERVER_NAME}) == mydomain.tld, die "goto h3ll";
      Problem solved. :)
      Best wishes.
      --Chris
      #!/usr/bin/perl -Tw
      use perl::always;
      my $perl_version = "5.12.4";
      print $perl_version;

        taint,

        Don't know it you meant your comment for me or for the OP's original question, but the OP did state that the 'person(s)' know(s) Perl, and can delete/modify code that tests for the correct script. A simple '#" in front of your code would defeat the test.

        It's still a management problem.

        "Well done is better than well said." - Benjamin Franklin

Re: How to ensure that a supported version of my script is being executed?
by flexvault (Parson) on Aug 21, 2012 at 20:51 UTC

    sanbiswa,

    Since I was brought back into this and since for the moment I'll assume that management wouldn't help you, because they think it's cute to corrupt an Oracle database. Here's a non fool proof idea.

    First, you have to nullify all existing copies of your code, good and bad, and then the good code must be read-only to all users (including you). If you need to update the script, then you have to delete it, and then copy a new version, and then make it read-only. You also have to change the way you call Oracle so that your old scripts don't work any more. (hint: change password, change Table name, etc.)

    Now write your 'C' program to verify the exact Perl script by not allowing it to be a symbolic link and that MD5 or SHA1 is correct. What I suggest is to read the Perl script into memory and add 50+ characters of non-printable data to it and then verify the MD5/SHA1 of that. If it fails then abort. Obviously the 'C' program must know the valid MD5/SHA1 value, but you can split the MD5/SHA1 into parts and resemble in memory, plus make the 'C' executable at least 100K in size. Now have the C executable write the script to an unique location with a unique name and then have the C program execute your script from there.

    It will help, but if someone is determined...

    If the 'C' program works, then you can update you Perl scripts and distribute them to happy users. We can hope!

    This may help you if your problem user(s) doesn't want to spend a few days figuring out what you have done, but if s/he's good and persistent...

    Plan B..Z is find a better job with better management :-)

    Good Luck!

    "Well done is better than well said." - Benjamin Franklin

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://988600]
Approved by Ratazong
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2014-09-15 04:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (145 votes), past polls