Bug 1005669 (CVE-2013-4407) - CVE-2013-4407 perl-HTTP-Body: remote command-injection flaw in HTTP::Body::Multipart versions 1.08 and later
Summary: CVE-2013-4407 perl-HTTP-Body: remote command-injection flaw in HTTP::Body::Mu...
Keywords:
Status: NEW
Alias: CVE-2013-4407
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-09 06:21 UTC by Murray McAllister
Modified: 2020-07-24 22:35 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
CPAN 88342 None None None Never

Description Murray McAllister 2013-09-09 06:21:48 UTC
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

Comment 1 Murray McAllister 2013-10-08 01:30:37 UTC
CVE request: http://www.openwall.com/lists/oss-security/2013/10/08/1

Comment 2 Tomas Hoger 2013-11-22 07:58:11 UTC
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

Comment 3 Petr Pisar 2014-03-26 06:28:33 UTC
Upstream made the regular expression matching extensions configurable with the these two commits:

commit 29a092ff5f959987f75b018cfedf4555ae495598
Author: Torsten Raudssus <torsten@raudss.us>
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@raudss.us>
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.


Note You need to log in before you can comment on or make changes to this bug.