On 2010.8.30 5:21 PM, Ilya Zakharevich via RT wrote:
Show quoted text> Queue: FindBin
> Ticket <URL:
https://rt.cpan.org/Ticket/Display.html?id=60892 >
>
> On Mon, Aug 30, 2010 at 07:55:41PM -0400, Michael G Schwern via RT wrote:
>>> Silly me, I was confusing $^X with $0... But the analysis remains: if
>>> the caller is able to change $0, all bets are off anyway.
>
>> Tainting does not make value judgments like that. Going down that road, what
>> if the data is coming from a file that the process owner owns and its set only
>> owner writable? Certainly sounds safe, why taint it? What if an attacker
>> tricked the process (or another process) into writing that file?
>
> Of course tainting DOES value judgements. Does it check whether CRTL is
> one which is expected? Does it check that there are not hot-fixes to
> Perl's DLL? (Possible on Solaris.) Does it check that things are not
> maliciously chroot()ed?
While those are security concerns, those are not "data coming from outside the
program" which is all tainting is really about. Tainting has nothing to say
about any of that.
If you want to talk about expanding the scope of tainting, or adding
additional security checks to Perl, or the value of taint in general, that's a
whole other issue.
Show quoted text>> All bets are not off if $0 can be changed. Initial breeches are usually very
>> narrow and specific and rely on bootstrapping from that small hole into more
>> and more privileges. As Graham pointed out, maybe you tricked a program into
>> running a linked file with a poisoned name.
>
> It is still not clear to me how this would be possible, but replacing
> the script by a different one is not.
When it comes to security, I find I'm usually not smart enough to see the
holes either. So I'm perfectly happy with leaving everything sealed up tight.
$0 need not have been attacked and changed. You could be generating programs
with filenames based on user input (I've seen sillier things) and someone
slipped in some input that causes your filename to be "rm -rf /;" in the hopes
you'll use the filename in a system call.
Its a stretch, but I've seen crazier things. The temp file attacks that
cropped up a while back, all relying on very well timed file replacements and
very subtle slips in temp file handling.
Show quoted text>> Tainting would stop the attacker from bootstrapping further, if
>> detainting is doing its job. [2]
>
> Seeing the code you propose below, I do not see how it would stop anyone...
Sorry, I was misleading about what it does.
bin_to_lib() would leave everything outside tainted. $0 remains tainted.
$FindBin::Bin remains tainted. It *only* detaints for the specific purpose of
pushing $FindBin::Bin/../lib onto @INC so that @INC does not catch $0's taint.
I don't think that's any more exploitable than the whole idea of FindBin is
to begin with. I could be wrong, but its better than people blindly
untainting $FindBin::Bin as the original reporter was.
The important bit is that because we don't know how they'll be used, it leaves
$FindBin::Bin and friends tainted for the rest of the program.
Here's what it might look like:
sub bin_to_lib {
my @lib = @_;
# Is there any checks we can do here?
# Can anything malicious be put into @INC?
my($bin) = $FindBin::Bin =~ /(.*)/;
require lib;
lib->import(File::Spec->catdir($bin, $lib));
return 1;
}
Does that clear things up?
Show quoted text>> That would be the equivalent of:
>>
>> use FindBin;
>> use lib "$FindBin::Bin/../lib";
>>
>> but with everything detainted and done in a cross platform manner and making
>> its assumptions about how the detainted data will be used explicit.
>
> And making as great a security hole as one had when $0 was untainted...
>
> I do not see any solutin except for having
> use FindBin;
> FindBin::untainted_bin_to_lib '../lib';
> (as you see, I see no point in manually breaking into components when
> untainted_bin_to_lib() can split on '/' anyway).
How the file path is handled can go either way. Its not really important.
Show quoted text>> use FindBin qw(bin_to_lib);
>> bin_to_lib("..", "lib");
>
> [OT: not clear why you think it is better than
> use FindBin;
> FindBin::bin_to_lib("..", "lib");
> ...]
In this specific case, with a very short module name, it really doesn't matter
much one way or the other.
--
52. Not allowed to yell "Take that Cobra" at the rifle range.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
RT for rt.cpan.org