Bug 1005669 - (CVE-2013-4407) CVE-2013-4407 perl-HTTP-Body: remote command-injection flaw in HTTP::Body::Multipart versions 1.08 and later
CVE-2013-4407 perl-HTTP-Body: remote command-injection flaw in HTTP::Body::Mu...
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On:
  Show dependency treegraph
Reported: 2013-09-09 02:21 EDT by Murray McAllister
Modified: 2015-01-05 11:56 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
CPAN 88342 None None None Never

  None (edit)
Description Murray McAllister 2013-09-09 02:21:48 EDT
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-07 21:30:37 EDT
CVE request: http://www.openwall.com/lists/oss-security/2013/10/08/1
Comment 2 Tomas Hoger 2013-11-22 02:58:11 EST
Noting upstream bug url as comment, which makes it harder to overlook than when only noted in the External Trackers list:

Comment 3 Petr Pisar 2014-03-26 02:28:33 EDT
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.