Bug 1030572 – perl-PlRPC: not secure across trust boundaries

Bug 1030572 - perl-PlRPC: not secure across trust boundaries

Summary:	perl-PlRPC: not secure across trust boundaries

Status:	CLOSED CURRENTRELEASE

Aliases:	None

Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	perl-PlRPC (Show other bugs)
Sub Component:
Version:	7.0
Hardware:	Unspecified Unspecified

Priority	unspecified Severity unspecified
Target Milestone:	rc
Target Release:	---
Assigned To:	perl-maint-list
QA Contact:	Martin Kyral
Docs Contact:

URL:
Whiteboard:
Keywords:	Patch, Security, SecurityTracking

Depends On:
Blocks:	1030547 1051106 CVE-2013-7284
	Show dependency tree / graph

Reported:	2013-11-14 12:23 EST by Florian Weimer
Modified:	2014-06-18 03:57 EDT (History)
CC List:	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:
Cloudforms Team:	---

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
Show Obsolete (3) Add an attachment (proposed patch, testcase, etc.)

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

Groups: 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.