Re^2: pp --clean does not seem to work

[afoken]

scan the directory at start of running the script, then after the script is done, scan the directory again and delete the new dir if the dir name =~ /temp/par-xxxxx/

Race condition. Don't do that. While the pp "compiled" perl script runs, someone can change the contents of the directory, or even remove the directory and replace it with something else.

Almost all linux distributions come with some perl version and a package manager. To distribute a perl script, either use the system perl as script interpreter and create a package (*.rpm, *.deb, ...) that depends on it (and perhaps some pre-packaged modules from the distribution), or package a custom perl, perhaps some custom modules, and make the script depend on the custom perl and the custom modules. There is no need to bundle a huge amount of binaries (perl interpreter, libraries, modules) into a single executable that starts polluting the file system every time it is started just to distribute a perl script.

To make things worse, the bundled binaries are most likely already present on the target system, wasting space. And even more worse, security updates distributed to the target system won't update the pp bundled script, it will still have security problems, even on a patched target system.

Now imagine not one pp-packed script, but hundreds of them, all with their own copy of a vulnerable library, where patching the system library just won't help. Welcome to the latest nightmare of Java.

Plus, using pp limits the resulting executable to a single operating system on a single processor platform. While the perl script could run, for example, on MIPS, ARM, x86, and x64 on Linux, *BSD, MacOS, and Windows, running pp on Linux x64 limits the resulting executable to Linux x64.

Alexander

[james28909]

i completely disagree, i have never had a problem scanning directories that my script created, whether it be created on the fly or be created statically. the average user of said compiled prgram isnt going to even know the directory was even created, much less change it contents. not to mention, you could lock the dir or every file in it,

also i think you are way off in left feild. if you have 100 pp programs running, then you will have 100 "temp" dir.. then when you run your program it will scan the dirs, then create its own. which can easily be singled out and filtered. i honestly dont know where the other stuff you mention would even come into play while /just/ scanning directories tbh

EDIT: the only thing that could be a problem is if the script/exe created the dir BEFORE the directory could be scanned.

[afoken]

Is your shift key broken or are you too lazy to use it?

i completely disagree, i have never had a problem scanning directories that my script created, whether it be created on the fly or be created statically. the average user of said compiled prgram isnt going to even know the directory was even created, much less change it contents. not to mention, you could lock the dir or every file in it,

Bullshit. The problem is not the average user, the problem is the malicious user that can abuse a pp-bundled perl script to gain more privileges on the system or to execute a denial-of-service attack. Also, locks on linux are advisory, not mandatory, unless you explicitly enable mandatory locking (1, 2). So, you CAN'T "lock" a directory so that is invulnerable, unless you have tuned the system to allow mandatory locks AND explicitly enabled them for all files by setting proper permissions for each and every temp file created by pp.

also i think you are way off in left feild. if you have 100 pp programs running, then you will have 100 "temp" dir.. then when you run your program it will scan the dirs, then create its own. which can easily be singled out and filtered. i honestly dont know where the other stuff you mention would even come into play while /just/ scanning directories tbh

The "other stuff" explains why it is a stupid idea to use pp, especially on systems derived from Unix.

EDIT: the only thing that could be a problem is if the script/exe created the dir BEFORE the directory could be scanned.

I see lots of problems:

What algorithm is used to determinate the name of the temp directory?

If the name can be determinated before the pp-created executable is started, several trivial attacks are possible. See 3 for some examples.

What permissions are used for the temp files and directories?

You don't want to allow group or world access to temp files and directories, for the reasons shown in [3].

When are permissions set for the temp files and directories?

Creating a file / directory with liberal permissions and then changing them to 0600 or 0700 is yet another race condition. The operating system may switch to another process during every single syscall, so another process may change the filesystem between creating the file and the chmod call.

How are symlinks handled while creating temp files?

You don't want to follow symlinks to vital files like /etc/passwd. See [3].

How are symlinks handled while deleting temp files?

Imagine a stupid directory deleter, as posted in Re: Copy folders (Re^2: Copy folders explains some of the bugs). Remove your temp files and vital system files are "magically" gone, because someone could insert symlinks into the temp directory and make root execute a pp-packed script including a stupid directory deleter.

And these are just the most trivial problems.

Did you actually follow the Java nightmare link and read the text there? You don't have to understand the unserialize problem, it's a nasty bug, caused by lazy people trusting unverified data, but that's not the real problem. The real problem is that a lot of software from the Java world bundles its own copy of the vulnerable libraries, often hidden inside archives. pp-bundled libraries have exactly the same problem. But because pp stuffed everything into a single executable, it is even harder to find problematic libraries than in the Java world, where you could at least try to search for *.jar and *.class files.

Alexander

[Anonymous Monk]

so, if the attacker can execute programs on the users machine, the game is lost ... this never made any sense to me , I don't get it