Red Hat Bugzilla – Full Text Bug Listing
|Summary:||CVE-2011-1595 rdesktop remote file access|
|Product:||[Other] Security Response||Reporter:||Henrik Andersson <hean01>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||aca21, astrand, bressers, mjc, noamr, security-response-team, vdanen|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-08-01 04:46:46 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||698407, 698408, 698411, 698412, 698413|
Description Henrik Andersson 2011-02-09 03:27:21 EST
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) email@example.com
Comment 2 Vincent Danen 2011-02-09 15:29:53 EST
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 02:28:55 EST
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 02:47:20 EST
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 13:51:41 EST
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 04:06:43 EST
Created attachment 478588 [details] PoC for the reported security vulnerability
Comment 7 Josh Bressers 2011-02-14 10:47:08 EST
The PoC works perfectly, thanks.
Comment 9 Josh Bressers 2011-02-14 11:05:00 EST
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 01:53:32 EST
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 15:57:29 EST
Has upstream developed a patch for this yet?
Comment 12 Henrik Andersson 2011-02-21 03:00:00 EST
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 08:30:09 EDT
Hi. I'm the new rdesktop maintainer. I will try to come up with a fix. The original discover is Noam Rathaus <firstname.lastname@example.org>. 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 03:18:04 EDT
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 03:33:53 EDT
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 03:42:44 EDT
Feel free to attach it here if it's not a problem for you. Thank you!
Comment 17 Peter Åstrand 2011-04-18 03:19:57 EDT
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 06:12:34 EDT
Created attachment 492845 [details] Corrected patch which will go into 1.7.0
Comment 19 Peter Åstrand 2011-04-18 08:34:55 EDT
1.7.0 has now been released.
Comment 20 Josh Bressers 2011-04-20 15:05:03 EDT
This is now public.
Comment 21 Noam Rathaus 2011-04-20 15:16:18 EDT
Please provide credit to: Anonymous contributor working with the SecuriTeam Secure Disclosure program.
Comment 23 Josh Bressers 2011-04-20 16:26:31 EDT
Created rdesktop tracking bugs for this issue Affects: fedora-all [bug 698413]
Comment 24 Tomas Hoger 2011-04-21 08:55:46 EDT
1.7.0 release announcement: http://sourceforge.net/mailarchive/message.php?msg_id=27376554
Comment 25 errata-xmlrpc 2011-05-11 18:08:04 EDT
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 02:42:43 EDT
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.