Buffer overflow in cracklib (verified 2.8.x and 2.7). This could lead to execution of arbitrary code when not using stack smashing protection: exploited in C: FascistCheck(pwd, string_longer_than_1024_bytes); -> Speicherzugriffsfehler (core dumped) or PHP: <?PHP $foo = sprintf("%2048s", "foo"); $dictionary = crack_opendict($foo) or die('Unable to open CrackLib dictionary'); ?> -> child pid 16256 exit signal Segmentation fault (11) I also sent this to the cracklib mailing list. J
Buffer overflow in cracklib (verified 2.8.x and 2.7). This could lead to execution of arbitrary code when not using stack smashing protection: exploited in C: FascistCheck(pwd, string_longer_than_1024_bytes); -> Speicherzugriffsfehler (core dumped) or PHP: <?PHP $foo = sprintf("%2048s", "foo"); $dictionary = crack_opendict($foo) or die('Unable to open CrackLib dictionary'); ?> -> child pid 16256 exit signal Segmentation fault (11) I also sent this to the cracklib mailing list. Jürgen
Created attachment 53703 [details, diff] Patch for cracklib-2.7 sources
Created attachment 53704 [details, diff] Patch for cracklib-2.8.1 sources
Created attachment 53705 [details, diff] Patch for cracklib-2.8.1.ebuild
Created attachment 53706 [details, diff] Patch for cracklib-2.7.1-r10.ebuild
Jurgen: overflowable library functions are not generally security issues, it's up to the author to use the functions safely, and sanitise untrusted input (think about strcat, sprintf, etc glibc functions). I think we should wait and see if upstream are interested in changing this behaviour before committing any changes to the package.
Cracklib maintainer applied the patch: 2.8.2 is out: http://sourceforge.net/projects/cracklib/ But 2.8.x is still ~x86, so i think we need a new 2.7 release.
Tavis: Yes, it's up to the author to use the functions safely and sanitise untrusted input. But this bug can be exploited by "bad authors" using malicious PHP-scripts in shared hosting environments: http://sourceforge.net/mailarchive/forum.php?thread_id=6826081&forum_id=43956 j
Tavis: Yes, it's up to the author to use the functions safely and sanitise untrusted input. But this bug can be exploited by "bad authors" using malicious PHP-scripts in shared hosting environments: http://sourceforge.net/mailarchive/forum.php?thread_id=6826081&forum_id=43956 jürgen
Jurgen: being able to execute code as yourself is not a security issue. From the ChangeLog: "Not a security issue, but fix applied regardless to be better behaved in the face of bad usage." Regarding your php safe mode, I had a quick look at the extension and doesnt it include extra checks that would make your poc fail if running in safe mode? (around line 79 crack.c) regardless, i think this should be reassigned to base-system to let them know about the new version available.
This exploit is only about safe-mode. An attacker cannot gain more privileges with "safe_mode = off", because he can already run arbitary code. But whith "safe_mode = on" he could bypass safe-mode restictions. Line 79 from crack.c does only check if the dict is inside the configured basedir and has the same owner as the script. It returns True if the file is nonexistent (i have verified this and crashed the apache process).The length of dictpath isn't checked: if ((PG(safe_mode) && (!php_checkuid(dictpath, NULL, CHECKUID_CHECK_FILE_AND_DIR))) || php_check_open_basedir(dictpath TSRMLS_CC)) { return -1; } J
This exploit is only about safe-mode. An attacker cannot gain more privileges with "safe_mode = off", because he can already run arbitary code. But whith "safe_mode = on" he could bypass safe-mode restictions. Line 79 from crack.c does only check if the dict is inside the configured basedir and has the same owner as the script. It returns True if the file is nonexistent (i have verified this and crashed the apache process).The length of dictpath isn't checked: if ((PG(safe_mode) && (!php_checkuid(dictpath, NULL, CHECKUID_CHECK_FILE_AND_DIR))) || php_check_open_basedir(dictpath TSRMLS_CC)) { return -1; } Jürgen
cracklib-2.7-r11 now in portage w/patch and is stable for all also added 2.8.2 for unstable users
Issues allowing local PHP users arbitrary code execution are not considered security vulnerabilities. PHP is weak by design in this area, see upstream note at http://www.php.net/security-note.php Closing as FIXED, reopen if you disagree.
