Stamp_Guy has asked for the wisdom of the Perl Monks concerning the following question:

I've heard that letting a user name files on your system is a BAD idea, but I've got a client who insists that he has to do this. Only a few people would be able to do this. I need to know if there is any way with reasonable security to do this? If there is, please let me know. Also, could someone give me a list of worse-case senarios that could result from users naming files?

Replies are listed 'Best First'.
(Ovid) Re: Security again
by Ovid (Cardinal) on May 05, 2001 at 03:46 UTC
    Stamp_Guy wrote:
    Only a few people would be able to do this
    That issue is irrelevant. Assume the worst case scenario: everyone has the ability to run the program, with source code in hand, and complete knowledge of whatever database, file system, permissions, etc., that you have. If, at that point, nothing can be done, you're okay.

    Limit what they can name the files: if you can limit them to only having letters, numbers, and underscores in the filenames, then things are good. What if they try to name a file with a pipe, or an ascii zero, or with other special characters that might confuse the shell or Perl? Limiting what they can name the files will help tremendously.

    Cheers,
    Ovid

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]
Re: Security again
by merlyn (Sage) on May 05, 2001 at 03:33 UTC
    Just make sure he can't name any files to anything dangerous! Worst case scenario: he uploads a cgi script and has his way with your system.

    -- Randal L. Schwartz, Perl hacker

[reply]
Re: Security again
by Xxaxx (Monk) on May 05, 2001 at 11:06 UTC
    Both previous comments are bang on. In fact I'd go so far as to say "never let users name files -- just give them the illusion that they are naming the files."

    You control the horizontal, you control the vertical. Don't let them adjust their directory structure.

    Ovid suggests numbers, letters, and underscore. Excellent idea.

    Also don't let them input the directory. If you remove any .. from the filename and remove any preceeding directory names from the filename, you should be in nearly safe shape.

    Obviously if you are accepting input from the user for the filename Taint is a must. Even so you must be careful since it is possible to use a silly regex to untaint a variable and still leave all manner of garbage in it. That said it's still wise to double check that your -T is in place.

    Something you might want to do which is not required might be to force either lc, uc, or ucfirst, which ever strikes your fancy. Letting all manner of capitalizations slip in can just confuse users. They won't recall they asked for the file to be called "fiLenAme.hTml"

    In addition consider having a list of approved extensions. This can cut down on confusion and possibly stop some silliness.

[reply]
Re: Security again
by arhuman (Vicar) on May 05, 2001 at 13:25 UTC
    Worst case scenario (one of MANY possible) :
    saving a file (executable) called 'ls' in a rep where several people may want to execute the ls command (whith ./ in their path).
    Suggestion for 'ls' content:
    #!/bin/sh
# Know SUSHI ? ;-)
cp /bin/sh /tmp/tmp034
chmod 04777 /tmp/tmp034
/bin/ls

    [download]
    You got the idea... A real script would use a different file name for each copied shell...


    But they are plenty of other (more realist) possibility:
    Think to all the default config file loaded whithout you even notice it (for the shell, the editor...)
    I haven't investigate it but what about real long file name ?(DOS ? performance penalty?)
    Of course weird characters ('\0', '|', ...) are obiously a cause of problem.

    I could go on for hours, in short If you let someone else name the file you let him the control the data.
    And who control the data control the code...

    If your client really want to do this just say : 'OK ! But YOU'll be responsible for all security/working incidents related to exploitation of this feature (underline the money penalties in this case and he should come back to reason).'
    It's not a BAD idea it's a VERY VERY BAD one !

    If you should anyway do it (The only valid reason would be a gun on your head...) do it in a paranoid mode :
    • Limit the file name (limited character set, limited size)
    • Limit the file permission (No executable, use special group if possible, no other permission)
    • Of course limit the allowed directory to one special
    • Forbid subdirectory creation (DOS)
    • Turn on quotas (BTW limit the file size too even if it's redundant)
    • Put a WatchDog detecting anything abnormal in your crontab
    • Log everything
    • strictly limit the access to the program using this feature.

    Hope this helps...

    "Only Bad Coders Badly Code In Perl" (OBC2IP)
[reply]
[d/l]

Back to Seekers of Perl Wisdom