#
1.5 |
|
15-Feb-2023 |
afresh1 |
Fix merge issues, remove excess files - match perl-5.36.0 dist
OK bluhm@ a good time naddy@
|
Revision tags: OPENBSD_6_5_BASE OPENBSD_6_6_BASE OPENBSD_6_7_BASE OPENBSD_6_8_BASE OPENBSD_6_9_BASE OPENBSD_7_0_BASE OPENBSD_7_1_BASE OPENBSD_7_2_BASE
|
#
1.4 |
|
13-Feb-2019 |
afresh1 |
Fix merge issues, remove excess files - match perl-5.28.1 dist
looking good sthen@, Great! bluhm@
|
Revision tags: OPENBSD_6_1_BASE OPENBSD_6_2_BASE OPENBSD_6_3_BASE OPENBSD_6_4_BASE
|
#
1.3 |
|
05-Feb-2017 |
afresh1 |
Fix merge issues, remove excess files - match perl-5.24.1 dist
|
Revision tags: OPENBSD_6_0_BASE
|
#
1.2 |
|
25-Jul-2016 |
afresh1 |
Patch perl CVE-2016-1238
The problem relates to Perl 5 ("perl") loading modules from the includes directory array ("@INC") in which the last element is the current directory ("."). That means that, when "perl" wants to load a module (during first compilation or during lazy loading of a module in run-time), perl will look for the module in the current directory at the end, since '.' is the last include directory in its array of include directories to seek. The issue is with requiring libraries that are in "." but are not otherwise installed.
The major problem with this behavior is that it unexpectedly puts a user at risk whenever they execute any Perl scripts from a directory that is writable by other accounts on the system. For instance, if a user is logged in as root and changes directory into /tmp or an account's home directory, it is possible to now run any shell commands that are written in C, Python or Ruby without fear.
The same isn't true for any shell commands that are written in Perl, since a significant proportion of Perl scripts will execute code in the current working directory whenever they are run. For example, if a user on a shared system creates the file /tmp/Pod/Perldoc/Toterm.pm, and then I log in as root, change directory to /tmp, and run "perldoc perlrun", it will execute the code they have placed in the file.
ok deraadt@
|
#
1.1 |
|
24-Sep-2010 |
millert |
branches: 1.1.1; Initial revision
|
#
1.4 |
|
13-Feb-2019 |
afresh1 |
Fix merge issues, remove excess files - match perl-5.28.1 dist
looking good sthen@, Great! bluhm@
|
Revision tags: OPENBSD_6_1_BASE OPENBSD_6_2_BASE OPENBSD_6_3_BASE OPENBSD_6_4_BASE
|
#
1.3 |
|
05-Feb-2017 |
afresh1 |
Fix merge issues, remove excess files - match perl-5.24.1 dist
|
Revision tags: OPENBSD_6_0_BASE
|
#
1.2 |
|
25-Jul-2016 |
afresh1 |
Patch perl CVE-2016-1238
The problem relates to Perl 5 ("perl") loading modules from the includes directory array ("@INC") in which the last element is the current directory ("."). That means that, when "perl" wants to load a module (during first compilation or during lazy loading of a module in run-time), perl will look for the module in the current directory at the end, since '.' is the last include directory in its array of include directories to seek. The issue is with requiring libraries that are in "." but are not otherwise installed.
The major problem with this behavior is that it unexpectedly puts a user at risk whenever they execute any Perl scripts from a directory that is writable by other accounts on the system. For instance, if a user is logged in as root and changes directory into /tmp or an account's home directory, it is possible to now run any shell commands that are written in C, Python or Ruby without fear.
The same isn't true for any shell commands that are written in Perl, since a significant proportion of Perl scripts will execute code in the current working directory whenever they are run. For example, if a user on a shared system creates the file /tmp/Pod/Perldoc/Toterm.pm, and then I log in as root, change directory to /tmp, and run "perldoc perlrun", it will execute the code they have placed in the file.
ok deraadt@
|
#
1.1 |
|
24-Sep-2010 |
millert |
branches: 1.1.1; Initial revision
|
Revision tags: OPENBSD_6_1_BASE OPENBSD_6_2_BASE
|
#
1.3 |
|
05-Feb-2017 |
afresh1 |
Fix merge issues, remove excess files - match perl-5.24.1 dist
|
Revision tags: OPENBSD_6_0_BASE
|
#
1.2 |
|
25-Jul-2016 |
afresh1 |
Patch perl CVE-2016-1238
The problem relates to Perl 5 ("perl") loading modules from the includes directory array ("@INC") in which the last element is the current directory ("."). That means that, when "perl" wants to load a module (during first compilation or during lazy loading of a module in run-time), perl will look for the module in the current directory at the end, since '.' is the last include directory in its array of include directories to seek. The issue is with requiring libraries that are in "." but are not otherwise installed.
The major problem with this behavior is that it unexpectedly puts a user at risk whenever they execute any Perl scripts from a directory that is writable by other accounts on the system. For instance, if a user is logged in as root and changes directory into /tmp or an account's home directory, it is possible to now run any shell commands that are written in C, Python or Ruby without fear.
The same isn't true for any shell commands that are written in Perl, since a significant proportion of Perl scripts will execute code in the current working directory whenever they are run. For example, if a user on a shared system creates the file /tmp/Pod/Perldoc/Toterm.pm, and then I log in as root, change directory to /tmp, and run "perldoc perlrun", it will execute the code they have placed in the file.
ok deraadt@
|
#
1.1 |
|
24-Sep-2010 |
millert |
branches: 1.1.1; Initial revision
|