From @lightsey

I noticed this while cleaning up two-argument open usage in blead.

This obscure script uses two-argument open to read files in the search
directories. If it's used in a directory where other users can provide files,
this will allow shell command execution.

Example​:

jd@​slug​:~/ $ echo xyzzy> 'testme;wall hello world|'
jd@​slug​:~/ $ perl win32/bin/search.pl 'Lightsey'
Useless use of a constant ("di") in void context at win32/bin/search.pl line 2.
Useless use of a constant ("ig00") in void context at win32/bin/search.pl line 3.
sh​: 1​: testme​: not found
wall​: cannot get tty name​: Inappropriate ioctl for device
                                                                               
Broadcast message from jd@​slug (somewhere) (Mon Nov 14 16​:41​:37 2016)​:         
                                                                               
hello world
                                                                               
search.pl​: can't read from "testme;wall hello world|"
" at (eval 3) line 148.

If this isn't considered significant enough to treat as a vulnerability, let me
know and I'll just include it with the other two-argument open fixes I'm working
on.

From @tonycoz

On Mon, 14 Nov 2016 07​:51​:50 -0800, john@​nixnuts.net wrote​:

I noticed this while cleaning up two-argument open usage in blead.

This obscure script uses two-argument open to read files in the search
directories. If it's used in a directory where other users can provide
files,
this will allow shell command execution.

Example​:

jd@​slug​:~/ $ echo xyzzy> 'testme;wall hello world|'
jd@​slug​:~/ $ perl win32/bin/search.pl 'Lightsey'
Useless use of a constant ("di") in void context at
win32/bin/search.pl line 2.
Useless use of a constant ("ig00") in void context at
win32/bin/search.pl line 3.
sh​: 1​: testme​: not found
wall​: cannot get tty name​: Inappropriate ioctl for device

Broadcast message from jd@​slug (somewhere) (Mon Nov 14 16​:41​:37 2016)​:

hello world

search.pl​: can't read from "testme;wall hello world|"
" at (eval 3) line 148.

If this isn't considered significant enough to treat as a
vulnerability, let me
know and I'll just include it with the other two-argument open fixes
I'm working
on.

search.pl is only installed on Win32 and you can't create files whose names contain | or >, so I don't think it's a security issue.

The real fix is probably just to remove it.

Tony

The RT System itself - Status changed from 'new' to 'open'

From @xsawyerx

On Wed, Nov 16, 2016 at 1​:03 AM, Tony Cook via RT
<perl5-security-report@​perl.org> wrote​:

On Mon, 14 Nov 2016 07​:51​:50 -0800, john@​nixnuts.net wrote​:

I noticed this while cleaning up two-argument open usage in blead.

This obscure script uses two-argument open to read files in the search
directories. If it's used in a directory where other users can provide
files,
this will allow shell command execution.

Example​:

jd@​slug​:~/ $ echo xyzzy> 'testme;wall hello world|'
jd@​slug​:~/ $ perl win32/bin/search.pl 'Lightsey'
Useless use of a constant ("di") in void context at
win32/bin/search.pl line 2.
Useless use of a constant ("ig00") in void context at
win32/bin/search.pl line 3.
sh​: 1​: testme​: not found
wall​: cannot get tty name​: Inappropriate ioctl for device

Broadcast message from jd@​slug (somewhere) (Mon Nov 14 16​:41​:37 2016)​:

hello world

search.pl​: can't read from "testme;wall hello world|"
" at (eval 3) line 148.

If this isn't considered significant enough to treat as a
vulnerability, let me
know and I'll just include it with the other two-argument open fixes
I'm working
on.

search.pl is only installed on Win32 and you can't create files whose names contain | or >, so I don't think it's a security issue.

I've been looking at it. It reports to be a find + grep, but better
(more options, faster, etc.). The last meaningful commit on it was at
2003.

Does anyone object to removing it? It could be moved onto CPAN (and
fixed), but also removed outright.

Tony, if you approve, I can email on the list plans to remove it and
ask if anyone objects or would like to move it to CPAN.

From @lightsey

On Wed, 2016-11-16 at 01​:32 -0800, Sawyer X via RT wrote​:

On Wed, Nov 16, 2016 at 1​:03 AM, Tony Cook via RT
<perl5-security-report@​perl.org> wrote​:

On Mon, 14 Nov 2016 07​:51​:50 -0800, john@​nixnuts.net wrote​:

If this isn't considered significant enough to treat as a
vulnerability, let me
know and I'll just include it with the other two-argument open fixes
I'm working
on.

search.pl is only installed on Win32 and you can't create files whose names
contain | or >, so I don't think it's a security issue.

I've been looking at it. It reports to be a find + grep, but better
(more options, faster, etc.). The last meaningful commit on it was at
2003.

Does anyone object to removing it? It could be moved onto CPAN (and
fixed), but also removed outright.

Tony, if you approve, I can email on the list plans to remove it and
ask if anyone objects or would like to move it to CPAN.

I wasn't aware that '|' is a reserved filename character on Windows. Since that
is the case, I'd agree this isn't a vulnerability.

Removal sounds like a good solution to me.

From @tonycoz

On Wed, 16 Nov 2016 01​:32​:25 -0800, xsawyerx@​gmail.com wrote​:

Tony, if you approve, I can email on the list plans to remove it and
ask if anyone objects or would like to move it to CPAN.

It's fine with me.

Tony

From @tonycoz

On Wed, 16 Nov 2016 06​:51​:08 -0800, john@​nixnuts.net wrote​:

On Wed, 2016-11-16 at 01​:32 -0800, Sawyer X via RT wrote​:

I've been looking at it. It reports to be a find + grep, but better
(more options, faster, etc.). The last meaningful commit on it was at
2003.

Does anyone object to removing it? It could be moved onto CPAN (and
fixed), but also removed outright.

Tony, if you approve, I can email on the list plans to remove it and
ask if anyone objects or would like to move it to CPAN.

I wasn't aware that '|' is a reserved filename character on Windows.
Since that
is the case, I'd agree this isn't a vulnerability.

This ticket is now public.

Removal sounds like a good solution to me.

The discussion at​:

http​://www.nntp.perl.org/group/perl.perl5.porters/2016/11/msg241072.html

concluded with removing it in 5.30.

Tony