-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move . to the end of the library search path #368
Comments
The current directory should be completely removed from the search path. Putting the current directory at the end of the path doesn't help if an application tries to load a library that might not exist on every system. Windows made the same mistake: http://www.google.com/search?q=windows+dll+hijack+vulnerability |
Can someone open up a branch and prepare a patch? |
There is a design decision about that? And a deprecation notice? The coding job is the minor part of the issue, IMO. |
Replying to NotFound:
cotto, Could you evaluate the design decision (if any) to be made here? Thanks. kid51 |
Design decision: pick one of the three:
|
I am +1 for #3, i.e. remove . from the default search path. This removes an entire class of security vulnerabilities. As long as we give a code snippet of how HLL authors can add . to the default search path, this shouldn't be a big issue. |
Looking in the cwd as a last resort sounds like a sane default. +1. |
Can we resolve this and make it part of 3.3 ? I think it is important. I am fine with putting . at the end of our search path. |
I would like to take this ticket but, obviously, there is still no general consensus. My opinion is that it should be removed all together from the search path. Placing the current working directory at the end of the search path does help protect against Trojans somewhat, but not completely. |
Replying to soh_cah_toa: soh_cah_toa, Thanks for the submission. But I have to ask: Are there any tests we should write to demonstrate what this patch does and that it does what we want it to? I would be reluctant to apply it otherwise. kid51 |
Yeah, cotto mentioned the same thing a few days ago. Unfortunately, I'm still new to the whole unit testing thing and would need some guidance on that part. I'll make it a point to talk to you guys about it tomorrow afternoon. |
2245 byte attachment from soh-cah-toa index 2bb9e13..b3758b9 100644
--- a/src/library.c
+++ b/src/library.c
@@ -155,8 +155,6 @@ parrot_init_library_paths(PARROT_INTERP)
if (!STRING_IS_NULL(envvar) && !STRING_IS_EMPTY(envvar))
VTABLE_push_string(interp, paths, envvar);
}
- entry = CONST_STRING(interp, "./");
- VTABLE_push_string(interp, paths, entry);
/\* define library paths */
paths = Parrot_pmc_new(interp, enum_class_ResizableStringArray);
@@ -168,15 +166,11 @@ parrot_init_library_paths(PARROT_INTERP)
if (!STRING_IS_NULL(envvar) && !STRING_IS_EMPTY(envvar))
VTABLE_push_string(interp, paths, envvar);
}
- entry = CONST_STRING(interp, "./");
- VTABLE_push_string(interp, paths, entry);
/\* define languages paths */
paths = Parrot_pmc_new(interp, enum_class_ResizableStringArray);
VTABLE_set_pmc_keyed_int(interp, lib_paths,
PARROT_LIB_PATH_LANG, paths);
- entry = CONST_STRING(interp, "./");
- VTABLE_push_string(interp, paths, entry);
/\* define dynext paths */
paths = Parrot_pmc_new(interp, enum_class_ResizableStringArray);
diff --git a/t/library/lib_search_path.t b/t/library/lib_search_path.t
new file mode 100644
index 0000000..62c3cca
--- /dev/null
+++ b/t/library/lib_search_path.t
@@ -0,0 +1,43 @@
+#!./parrot
+# Copyright (C) 2011 Parrot Foundation.
+
+=head1 NAME
+
+t/library/lib_search_path.t - testing for proper search path precedence
+
+=head1 SYNOPSIS
+
+This test program verifies that Parrot searches for libraries in the
+proper order.
+
+=head1 AUTHOR
+
+Kevin Polulak (a.k.a. soh_cah_toa) kpolulak@gmail.com
+
+=cut
+
+.const string TESTS = 2
+
+.sub 'main' :main
- .include 'test_more.pir'
+
- .local pmc lib
- .local pmc lib_cwd
+
- plan(TESTS)
+
- # Verify current working directory isn't searched
- lib_cwd = loadlib 'lib_search_path.t'
- is(lib_cwd, '', 'Verify current working directory not searched')
+
- # Verify runtime/parrot/dynext is searched
- lib = loadlib 'osutils.pir'
- isnt(lib, '', 'Verify runtime/parrot/dynext is searched')
+.end
+
+# Local Variables:
+# mode: pir
+# fill-column: 100
+# End:
+# vim: expandtab shiftwidth=4 ft=pir:
+
|
Patch incudes both the changes and tests. |
Patch applied in https://github.com/parrot/parrot/tree/tt1589_library_path Deprecation data, wiki pages and possibly some docs still need to get modified. |
Replying to dukeleto:
dukeleto, soh_cah_toa: Which of you can take care of those items? Thank you very much. kid51 |
Replying to jkeenan:
Repeat question. |
… paths Add examples/pir/libpaths.pir to show the various deficiences of our current library search paths. Duplicates, installed paths mixed up with temp. build paths.
Currently tests 1-4 fails because of duplicates. Only works on slash eq "/"
Works ok with the next commit to fix the duplicate call to Parrot_lib_update_paths_from_config_hash.
Remove the duplicate call to Parrot_lib_update_paths_from_config_hash() from Parrot_api_set_configuration_hash(). 1. 0 Parrot_lib_update_paths_from_config_hash (interp=0x412050) at src/library.c:214 1 0x00007ffff7ab8d35 in Parrot_gbl_set_config_hash_interpreter (interp=0x412050) at src/global_setup.c:131 2 0x00007ffff7ab8c54 in Parrot_set_config_hash_pmc (interp=0x412050, config=PMC<Hash> = {...}) at src/global_setup.c:98 3 0x00007ffff7a99aca in Parrot_api_set_configuration_hash (interp_pmc=0x4dcb00, confighash=0x4e9a18) at src/embed/api.c:506 4 0x0000000000402713 in Parrot_set_config_hash (interp_pmc=0x4dcb00) at src/parrot_config.c:3870 5 0x000000000040175c in main (argc=2, argv=0x7fffffffe6b8) at frontend/parrot2/main.c:151 2. 0 Parrot_lib_update_paths_from_config_hash (interp=0x412050) at src/library.c:214 1 0x00007ffff7a99ad9 in Parrot_api_set_configuration_hash (interp_pmc=0x4dcb00, confighash=0x4e9a18) at src/embed/api.c:507 2 0x0000000000402713 in Parrot_set_config_hash (interp_pmc=0x4dcb00) at src/parrot_config.c:3870 3 0x000000000040175c in main (argc=2, argv=0x7fffffffe6b8) at frontend/parrot2/main.c:151 Parrot_set_config_hash_pmc already calls Parrot_lib_update_paths_from_config_hash, no need to call it again.
… paths Add examples/pir/libpaths.pir to show the various deficiences of our current library search paths. Duplicates, installed paths mixed up with temp. build paths.
Currently tests 1-4 fails because of duplicates. Only works on slash eq "/"
Works ok with the next commit to fix the duplicate call to Parrot_lib_update_paths_from_config_hash.
Remove the duplicate call to Parrot_lib_update_paths_from_config_hash() from Parrot_api_set_configuration_hash(). 1. 0 Parrot_lib_update_paths_from_config_hash (interp=0x412050) at src/library.c:214 1 0x00007ffff7ab8d35 in Parrot_gbl_set_config_hash_interpreter (interp=0x412050) at src/global_setup.c:131 2 0x00007ffff7ab8c54 in Parrot_set_config_hash_pmc (interp=0x412050, config=PMC<Hash> = {...}) at src/global_setup.c:98 3 0x00007ffff7a99aca in Parrot_api_set_configuration_hash (interp_pmc=0x4dcb00, confighash=0x4e9a18) at src/embed/api.c:506 4 0x0000000000402713 in Parrot_set_config_hash (interp_pmc=0x4dcb00) at src/parrot_config.c:3870 5 0x000000000040175c in main (argc=2, argv=0x7fffffffe6b8) at frontend/parrot2/main.c:151 2. 0 Parrot_lib_update_paths_from_config_hash (interp=0x412050) at src/library.c:214 1 0x00007ffff7a99ad9 in Parrot_api_set_configuration_hash (interp_pmc=0x4dcb00, confighash=0x4e9a18) at src/embed/api.c:507 2 0x0000000000402713 in Parrot_set_config_hash (interp_pmc=0x4dcb00) at src/parrot_config.c:3870 3 0x000000000040175c in main (argc=2, argv=0x7fffffffe6b8) at frontend/parrot2/main.c:151 Parrot_set_config_hash_pmc already calls Parrot_lib_update_paths_from_config_hash, no need to call it again.
Here's a snippet of strace output after I accidentally ran parrot-nqp in a directory with a Regex.pbc file:
Parrot has taken Regex.pbc in the current directory before even checking for it in the standard libraries. The same behavior occurs with all other Parrot-based programs which use installed libraries. This provides an attack vector against Parrot users:
It's probably best to follow Perl 5's example here:
With the current directory at the end, installed programs which use only installed libraries will never be tricked into running code in the current directory. Hopefully it is not too common for installed programs to reference nonexistant libraries.
Originally http://trac.parrot.org/parrot/ticket/1589
The text was updated successfully, but these errors were encountered: