PlRPC is a Perl module that implements IDL-free RPCs. It is intended for cross-domain applications, but it fails to achieve that goal because it uses Storable, which is known to be insecure when deserializing (thawing) untrusted data. User name and password are transmitted using Storable, so code execution can happen before authentication. The patches that exist just document the issues and are not real fixes. References: http://seclists.org/oss-sec/2014/q1/56 https://rt.cpan.org/Public/Bug/Display.html?id=90474 Commit/Patch: http://pkgs.fedoraproject.org/cgit/perl-PlRPC.git/commit/?id=b9497b8d780a54ff5be6661c5f24d70135e0bb79
Created perl-PlRPC tracking bugs for this issue: Affects: fedora-all [bug 1051110]
The actual proposed patch to upstream is here: * https://rt.cpan.org/Public/Ticket/Attachment/1293961/685696/0001-Security-notice-on-Storable-and-reply-attack.patch Based on the discussion in bug #1030572, there is no real "fix" for this as it seems that Storable deserialization is exposed prior to password-based authentication (see how AcceptUser is called in the server code). MITRE assigned CVE-2013-7284 to this issue.
(In reply to Vincent Danen from comment #2) > The actual proposed patch to upstream is here: > > * > https://rt.cpan.org/Public/Ticket/Attachment/1293961/685696/0001-Security- > notice-on-Storable-and-reply-attack.patch > > Based on the discussion in bug #1030572, there is no real "fix" for this as > it seems that Storable deserialization is exposed prior to password-based > authentication (see how AcceptUser is called in the server code). > > MITRE assigned CVE-2013-7284 to this issue. Is amending the PlRPC documentation with this patch sufficient to close this bug, or should we keep this open until a real fix in the code (extension of Storable module and utilizing it in PlRPC) will be available?
Here is Storable documentation that describes security risks of deserializing untrusted inputs using Storable: http://search.cpan.org/~ams/Storable-2.45/Storable.pm#SECURITY_WARNING The only package shipped in Red Hat Software Collections 1 and Red Hat Enterprise Linux 7 Beta is perl-DBI with DBI::Proxy / DBI::ProxyServer modules. Those modules are not used by any other package shipped as part of those products. There is an upstream bug requesting addition of security warnings to DBI documentation: https://rt.cpan.org/Public/Bug/Display.html?id=90475 It does not seem there's a way to fix without introducing incompatible protocol change by using different way to serialize data for network transfer. Alternative may be to have Storable provide a safe mode to deserialize untrusted inputs. That seems to be on the Storable upstream TODO list, but not available in current version.
Possible mitigation here is to use host based access restrictions to any service using PlRPC to ensure only trusted hosts/users have access.
(In reply to Tomas Hoger from comment #5) > The only package shipped in Red Hat Software Collections 1 and Red Hat > Enterprise Linux 7 Beta is perl-DBI with DBI::Proxy / DBI::ProxyServer > modules. Those modules are not used by any other package shipped as part of > those products. Search through Debian archive (using http://codesearch.debian.net/) also fails to find any user of PlRPC or DBI::Proxy*. Reducing impact rating based on the fact that this module does not seem to be used by any real world application.
Without PlRPC modules, DBD::Proxy* modules have to be removed. Without DBD::Proxy* modules, Bundle::DBI module, DBI's t/80proxy.t test and DBI's /usr/bin/dbiproxy tool have to be removed.
Statement: The Red Hat Security Response Team has rated this issue as having Moderate security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.