local code execution flaw in win32/bin/search.pl

p5pRT commented 7 years ago

Migrated from rt.perl.org#130100 (status was 'open')

Searchable as RT130100$

p5pRT commented 7 years ago

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.

p5pRT commented 7 years ago

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

p5pRT commented 7 years ago

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

p5pRT commented 7 years ago

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.

p5pRT commented 7 years ago

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.

p5pRT commented 7 years ago

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

p5pRT commented 7 years ago

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

Perl / perl5