A remote command-injection flaw was reported in HTTP::Body::Multipart versions 1.08 and later[1]. An attacker able to upload files to a service that uses HTTP::Body::Multipart could execute commands on the server. Fedora and EPEL ship perl-HTTP-Body 1.07 and are not affected by this flaw. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721634
CVE request: http://www.openwall.com/lists/oss-security/2013/10/08/1
Noting upstream bug url as comment, which makes it harder to overlook than when only noted in the External Trackers list: http://rt.cpan.org/Public/Bug/Display.html?id=88342
Upstream made the regular expression matching extensions configurable with the these two commits: commit 29a092ff5f959987f75b018cfedf4555ae495598 Author: Torsten Raudssus <torsten> Date: Fri Dec 6 09:05:32 2013 -0500 Added RT88342 related test (found parsing bug in that way), tighten some oth er tests lib/HTTP/Body/MultiPart.pm | 5 ++- t/08multipart-suffix.t | 10 +++--- t/09rt88342.t | 70 ++++++++++++++++++++++++++++++++++++++++ t/data/multipart/015-content.dat | 19 +++++++++++ t/data/multipart/015-headers.pml | 5 +++ 5 files changed, 103 insertions(+), 6 deletions(-) commit 15f5ddbf624d18a71b01f87bd20d1f5a7780162d Author: Torsten Raudssus <torsten> Date: Fri Dec 6 09:19:41 2013 -0500 Hups, forgot to set content length t/data/multipart/015-headers.pml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) These changes are included in version 1.18. These changes do not fix the issue. But they allow change the expression by a caller. There is also an example of safer expression: +our $basename_regexp = qr/[^.]+(\.[^\\\/]+)$/; +#our $basename_regexp = qr/(\.\w+(?:\.\w+)*)$/; that can be adopted by distributors. At the end, I want to say the the original issue reporter proclamation: > Previously, the tempname was always alphanumeric. No special chars. So we > could use it directly in commands like: > my $info = `identify -format "%m" $filename 2>&1`; is flawed by design. Using `` (backticks substitution) with unknown variables is considered as a bad and insecure habit regardless of HTTP::Body::MultiPart implementation.