Bug 1030572 - perl-PlRPC: not secure across trust boundaries
perl-PlRPC: not secure across trust boundaries
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: perl-PlRPC (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: perl-maint-list
Martin Kyral
: Patch, Security, SecurityTracking
Depends On:
Blocks: 1030547 1051106 CVE-2013-7284
  Show dependency treegraph
 
Reported: 2013-11-14 12:23 EST by Florian Weimer
Modified: 2014-06-18 03:57 EDT (History)
3 users (show)

See Also:
Fixed In Version: perl-PlRPC-0.2020-13.el7
Doc Type: Bug Fix
Doc Text:
Cause: Reading documentation. Consequence: Documentation does not warn on use of insecure Storable Perl module and possible reply attacks. Fix: RPC::PlServer documentation has been amended with notice about use of insecure Storable Perl module and possibility of reply attack. An external authentication mechanism is recommended now. Result: Documentation warns users about possible security flaws in the PlRPC server.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-12 04:01:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Proposed documentation fix (2.60 KB, patch)
2013-11-18 06:33 EST, Petr Pisar
no flags Details | Diff
Proposed documentation fix 2 (1.53 KB, patch)
2013-11-18 07:57 EST, Petr Pisar
no flags Details | Diff
Proposed documentation fix 2 (1.53 KB, patch)
2013-11-18 07:59 EST, Petr Pisar
no flags Details | Diff
Proposed documentation fix 2 (3.75 KB, patch)
2013-11-26 08:01 EST, Petr Pisar
no flags Details | Diff


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

  None (edit)
Description Florian Weimer 2013-11-14 12:23:00 EST
The transport layer uses messages encoded with Storable.  Storable is not secure across trust boundaries, see the warning that upstream added in Version 2.45.  We should at least add a strong warning that PlRPC is equally unsafe.

In addition, the instructions are overly optimistic.  We don't seem to ship any really strong ciphers, and the API of the Crypt:: modules is not really a good match for authenticated encryption modes.  (Unauthenticated tend to be vulnerable to all kinds of attacks.)  There appears to be zero reply protection.  Additionally, compression is enabled unconditionally, which can reveal message contents, especially in conjunction with chosen-ciphertext attacks.
Comment 4 Petr Pisar 2013-11-18 06:33:34 EST
Created attachment 825551 [details]
Proposed documentation fix

This has been posted to the upstream for a review.
Comment 5 Florian Weimer 2013-11-18 06:38:57 EST
(In reply to Petr Pisar from comment #4)
> Created attachment 825551 [details]
> Proposed documentation fix
> 
> This has been posted to the upstream for a review.

It seems that Storable deserialization is exposed prior to password-based authentication (see how AcceptUser is called in the server code).  I think the warning should mention that.  It's probably best to replace the entire "SECURITY" section with a clear warning that you absolutely have to use an external authentication mechanism.
Comment 6 Petr Pisar 2013-11-18 07:43:24 EST
You are right. However the decryption is done before deserialization. So I guess if somebody wants to use a password for authentication, he will use encryption too. And that turns into two-step authentication as drafted in the SECURITY/Protection against untrusted users/Encryption paragraph:

I recommend two phase encryption: The first phase is the login phase,
where to use a host based key. As soon as the user has authorized, you
should switch to a user based key. See the DBI::ProxyServer for an example.

I will improve the text.
Comment 7 Petr Pisar 2013-11-18 07:57:11 EST
Created attachment 825588 [details]
Proposed documentation fix 2

Updated documentation.
Comment 8 Petr Pisar 2013-11-18 07:59:39 EST
Created attachment 825589 [details]
Proposed documentation fix 2

Correct README conversion.
Comment 9 Petr Pisar 2013-11-26 08:01:27 EST
Created attachment 829254 [details]
Proposed documentation fix 2

I attached wrong patch. This one is correct.
Comment 12 Vincent Danen 2014-01-09 17:23:10 EST
Adding security keywords since this, or part of it anyways, has received a CVE.

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