[Bug 751886] CVE-2011-4115 perl-Parallel-ForkManager: insecure temporary file usage

bugzilla at redhat.com bugzilla at redhat.com
Thu Nov 10 09:17:51 UTC 2011


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=751886

--- Comment #3 from Tomas Hoger <thoger at redhat.com> 2011-11-10 04:17:49 EST ---
I gave this some look yesterday, and I can't see any nice way to fix this
either.

Safely creating temporary directory under /tmp would probably be the least
invasive way to fix, but there's a problem with the clean-up at the end.  It
seems it's valid to use this module in a way that parent process forks bunch of
child processes, let them do their work and exit before they finish.  Hence
this approach should leave a temporary directory behind on each run of such
script.

Changing child code to create the file safely does not seem like an option
either.  If the predictable file name is used, attacker may "DoS" the child
(create temp file so that child can not while its "reply" data structure). 
Child can block (keep re-trying to create the file) or exit (let parent parse
malicious file), but cases seem wrong.  As a side note, in current
implementation, parent process tries to read the temp file even when the script
is not written to use this data passing feature.  Hence attacker can easily
make parent deserialize arbitrary malicious Storable blob.  Storable man page
only mention it's unsafe when storing / retrieving of CODE is allowed (not by
default), but still sounds like "don't do this".  Even if it's safe, that may
have other side effects (block parent on read, make it use extra memory,
trigger side effects when opening special files).

Parent process can create temp file safely, but can not use predictable file
name with its current format, as it does not know child pid before fork.  Hence
it'd need to use random name and have it stored in both parent and child data
structs.  Of course, this has the same problem as temp dir idea in cases where
parent exits before child.

One improvement can be to create temp file only when script wants to use
structure passing (and hence parent is expected to wait for child), i.e. when
on_finish callback is set.  However, even though docs say to declare callbacks
before first start, it's apparent you can set them after start, as
run_on_finish accepts optional pid argument to set child-specific callback. 
I'm not sure what the intended semantic was, as setting callback after run is
racy and the callback may not be run if child exits quickly.

One idea is to make new's tempdir parameter mandatory if script wants to use
structure passing, and document that caller should provide a safe temporary
directory (i.e. not /tmp) - such as directory that is not world writeable
(/home/user/something or /var/lib/something), or safely created under /tmp.  Of
course, that's something that we can't do without upstream.

We can downgrade module to the F14 version that lacks this new feature ;).

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the perl-devel mailing list