Ludwig Nussel writes: Matthias Weckbecker found that perl -e '/\6666666666/' causes perl (at least 5.8 and 5.10) to segfault on x86_64. Our perl maintainer Michael Schröder says perl treats the value as literal in one place and as group reference in another. This doesn't seem to be exploitable for anything worse than crashing perl. Would be good to have this confirmed by upstream though. Does anyone know whether perl has a security contact?
No upstream reply yet.
This does not crash 5.8.8-r5 on x86, but x86_64 it does: stat("/usr/local/lib/site_perl/5.8.8", 0x7fffdb7b4840) = -1 ENOENT (No such file or directory) stat("/usr/local/lib/site_perl/x86_64-linux", 0x7fffdb7b4840) = -1 ENOENT (No such file or directory) ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {c_iflags=0x500, c_oflags=0x5, c_cflags=0xbf, c_lflags=0x8a3b, c_line=0, c_cc="\x03\x1c\x7f\x15\x04\x00\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"}) = 0 lseek(0, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {c_iflags=0x500, c_oflags=0x5, c_cflags=0xbf, c_lflags=0x8a3b, c_line=0, c_cc="\x03\x1c\x7f\x15\x04\x00\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"}) = 0 lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {c_iflags=0x500, c_oflags=0x5, c_cflags=0xbf, c_lflags=0x8a3b, c_line=0, c_cc="\x03\x1c\x7f\x15\x04\x00\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"}) = 0 lseek(2, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) open("/dev/null", O_RDONLY) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffdb7b4790) = -1 ENOTTY (Inappropriate ioctl for device) lseek(3, 0, SEEK_CUR) = 0 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0 readlink("/proc/self/exe", "/usr/bin/perl5.8.8", 4095) = 18 close(3) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ rbu, did you ever get an answer?
restricting per request.
This bug accidently went public for a short timeframe, because there was a bug in the bugzilla template (it matched the accountname against *@gentoo.org and not against the group membership). As I do not have a @gentoo.org address, it did not show the option "Only users in all of the selected groups can view this bug:" to me; so after writing comment #2, bugzilla cleared the setting automatically and I could not see that anything was wrong. Hoffie talked to robbat2, and it's fixed for me now, thanks for the fast handling!
v5.12.2 says on x86: # perl -e '/\6666666666/' Use of octal value above 377 is deprecated in regex; marked by <-- HERE in m/\ <-- HERE 6666666666/ at -e line 1. On x86_64, I still get the segfault.
Seems valid for me on amd64 still. Has anyone actually reported this one upstream? Got a link?
(In reply to Chris Reffett from comment #6) > Seems valid for me on amd64 still. Has anyone actually reported this one > upstream? Got a link? This bug still valid on last stable (perol-5.16.3) and masked versions on 64bit systems. I have pinged perl5-security-report@perl.org about it. Waiting for answer.
Upstream said that this is fixed in 5.19.5, bugreport in upstream's bugtracker is public, so this issue is public too and i am CCing the whole Gentoo Perl team
(In reply to Sergey Popov from comment #8) > Upstream said that this is fixed in 5.19.5, bugreport in upstream's > bugtracker is public, so this issue is public too and i am CCing the whole > Gentoo Perl team Updating Summary from comment #8. Not sure what we do with 5.18 here.
(In reply to Andreas K. Hüttel from comment #9) > Updating Summary from comment #8. Not sure what we do with 5.18 here. We need to insert our fixed version. If you plan to patch the 5.18, then go ahead; otherwise we will wait for the next perl stabilization
(In reply to Agostino Sarubbo from comment #10) > (In reply to Andreas K. Hüttel from comment #9) > > > Updating Summary from comment #8. Not sure what we do with 5.18 here. > > We need to insert our fixed version. > > If you plan to patch the 5.18, then go ahead; otherwise we will wait for the > next perl stabilization The backport is nontrivial; the patch does not apply. (Yes I tried fixing it, but it's surrounded by rather complex spaghetti code.)
5.18 masked. GLSA filed.
This issue was resolved and addressed in GLSA 201507-11 at https://security.gentoo.org/glsa/201507-11 by GLSA coordinator Mikle Kolyada (Zlogene).
CVE-2013-7422 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-7422): ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. ** TEMPORARY ** Input in to perl using -e variable with a crafted input, creates a Denial of service condition in versions prior to 5.19.5.
