Bug 676252 (CVE-2011-1595)

Summary: CVE-2011-1595 rdesktop remote file access
Product: [Other] Security Response Reporter: Henrik Andersson <hean01>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: aca21, astrand, bressers, mjc, noamr, security-response-team, vdanen
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-01 08:46:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 698407, 698408, 698411, 698412, 698413    
Bug Blocks:    
Attachments:
Description Flags
PoC for the reported security vulnerability
none
Patch which will go into 1.7.0
none
Corrected patch which will go into 1.7.0 none

Description Henrik Andersson 2011-02-09 08:27:21 UTC
Hi, we (Cendio) have been shared information about a security vulnerability 
and have verified it in code that this is possible.

We don't have time to investigate further nor producing a patch and want
some help on that point.

Report:

"The vulnerability is a Directory Traversal vulnerability which affects
an rDesktop client (I believe other products that use the same code will
have the same issue), which will allow someone connecting to a
compromised server (RDP server) or via a MITM vulnerability to access
any file he desires on the user's computer.

The vulnerability allows writing, reading and listing the content of the
directories, all transparently.

The vulnerability requires the user to share "something" on his end
(rDesktop end), and from that point when he connects to the compromised
server, the server will have full access to his computer - of course
depending on what permissions he has - those are the areas of the
computer he can reach."


Regards.
Henrik Andersson (Cendio AB)
henrik.andersson

Comment 2 Vincent Danen 2011-02-09 20:29:53 UTC
Do you have an easy means of reproducing this so that we can try to see exactly what is going on?  The report is a little vague on details.  A clear reproducer would really assist us here (how the connection is established, how you "share" something, and what the server has to do in order to get at the client).

Comment 3 Henrik Andersson 2011-02-10 07:28:55 UTC
As i did a minor investigation of the source just to validate the report and the found one problem in source file disk.c which handles the disk io requests. 

static RD_NTSTATUS
disk_create(uint32 device_id, uint32 accessmask, uint32 sharemode, uint32 create_disposition,
	    uint32 flags_and_attributes, char *filename, RD_NTHANDLE * phandle)

path =  g_rdpdr_device[device_id].local_path + filename

if local_path is "/media/usbdevice" and filename requested is "../../tmp/anyfile"
and the user have access to file /tmp/anyfile he will be opening a file outside the local_path, there is no sanity/validation on constructed filename to create/open.

I'm unshure of the best way to lockdown this problem, validating path with some stringmagics, using chroot() jail of the operation itself or any other to me unknown way to lock this down.

The reporter of this vulnerability mention that he had some patch files for xrdp project for making it into a working PoC, i'll request them and attach them to this bug.

Comment 4 Henrik Andersson 2011-02-10 07:47:20 UTC
Establishing a connection and mount a local folder to cdrom drive:

rdesktop -r disk=cdrom:/media/usbdevice xxx.xxx.xxx.xxx

the server side must be a compromised RDP server or a via MITM vulnerability that actually send file open request with relative path in filename request to the client.

Comment 5 Josh Bressers 2011-02-11 18:51:41 UTC
Any word on a reproducer? From looking at the code, this is probably a problem. The hard part will be fixing it properly (which is where a reproducer will be useful).

Thanks.

Comment 6 Henrik Andersson 2011-02-14 09:06:43 UTC
Created attachment 478588 [details]
PoC for the reported security vulnerability

Comment 7 Josh Bressers 2011-02-14 15:47:08 UTC
The PoC works perfectly, thanks.

Comment 9 Josh Bressers 2011-02-14 16:05:00 UTC
Henrik,

From your initial report, I presume you won't mind if Red Hat takes over coordination of this issue. I'll want to engage upstream along with other vendors.

Do you wish to be involved (cc'd on the mails)?

Who should I credit as the discoverer?

Have you told anyone else (this will dictate how long we can keep the issue private)?

Once I have your acks, I'll start dealing with this.

Thanks.

Comment 10 Henrik Andersson 2011-02-15 06:53:32 UTC
Hi Josh,

We woudln't mind if Red Hat takes over coordination of this issue due to we (Cendio) dont have time to investigate further nor having the knowledge to handle / coordinate this kind of situation.

I'm a committer upstream of rdesktop project and would be the your contact and the responsible from rdesktop side for handling this issue.

I'll contact the reporter of this issue for the crediting question.

Cendio got this report in confidence and we have not told anyone else about 
this issue and i'm pretty sure that the reporter has handled this information
carefully from what i can read between the lines in his mails.

Regards,
Henrik Andersson (Cendio)

Comment 11 Josh Bressers 2011-02-16 20:57:29 UTC
Has upstream developed a patch for this yet?

Comment 12 Henrik Andersson 2011-02-21 08:00:00 UTC
Im sorry for the late response, as i mention in the earlier post we 
do not have a patch for this issue nor the time/knowledge to create a
patch for this issue.

/Henrik

Comment 13 Peter Åstrand 2011-04-14 12:30:09 UTC
Hi. I'm the new rdesktop maintainer. I will try to come up with a fix. The original discover is Noam Rathaus <noamr>. 

Can you tell us in which order we should do things? We are planning to release a new version of rdesktop, 1.7.0, in a near future. Is it ok if the fix for this problem is included in that release?

Comment 14 Tomas Hoger 2011-04-15 07:18:04 UTC
Peter, I'm not sure if you intended to ask anyone specific...  I think you as a current upstream maintainer should pick the approach that works the best for you, be it fixing as part of 1.7.0, or doing a separate security release with just this fix after 1.7.0.

Comment 15 Peter Åstrand 2011-04-15 07:33:53 UTC
In that case, we will include the fix in 1.7.0. Do you want access to the patch  before we commit it to the public Subversion repository, do a public release etc?

Comment 16 Tomas Hoger 2011-04-15 07:42:44 UTC
Feel free to attach it here if it's not a problem for you.  Thank you!

Comment 17 Peter Åstrand 2011-04-18 07:19:57 UTC
Created attachment 492815 [details]
Patch which will go into 1.7.0

I plan to release 1.7.0 later tonight or early tomorrow.

Comment 18 Peter Åstrand 2011-04-18 10:12:34 UTC
Created attachment 492845 [details]
Corrected patch which will go into 1.7.0

Comment 19 Peter Åstrand 2011-04-18 12:34:55 UTC
1.7.0 has now been released.

Comment 20 Josh Bressers 2011-04-20 19:05:03 UTC
This is now public.

Comment 21 Noam Rathaus 2011-04-20 19:16:18 UTC
Please provide credit to:
Anonymous contributor working with the SecuriTeam Secure Disclosure program.

Comment 23 Josh Bressers 2011-04-20 20:26:31 UTC
Created rdesktop tracking bugs for this issue

Affects: fedora-all [bug 698413]

Comment 24 Tomas Hoger 2011-04-21 12:55:46 UTC
1.7.0 release announcement:
  http://sourceforge.net/mailarchive/message.php?msg_id=27376554

Comment 25 errata-xmlrpc 2011-05-11 22:08:04 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5
  Red Hat Enterprise Linux 6

Via RHSA-2011:0506 https://rhn.redhat.com/errata/RHSA-2011-0506.html

Comment 26 Murray McAllister 2011-10-04 06:42:43 UTC
Acknowledgements:

Red Hat would like to thank Cendio AB for reporting this issue. Cendio AB acknowledges an anonymous contributor working with the SecuriTeam Secure Disclosure program as the original reporter.