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
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).
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.
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.
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.
Created attachment 478588 [details] PoC for the reported security vulnerability
The PoC works perfectly, thanks.
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.
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)
Has upstream developed a patch for this yet?
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
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?
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.
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?
Feel free to attach it here if it's not a problem for you. Thank you!
Created attachment 492815 [details] Patch which will go into 1.7.0 I plan to release 1.7.0 later tonight or early tomorrow.
Created attachment 492845 [details] Corrected patch which will go into 1.7.0
1.7.0 has now been released.
This is now public.
Please provide credit to: Anonymous contributor working with the SecuriTeam Secure Disclosure program.
Created rdesktop tracking bugs for this issue Affects: fedora-all [bug 698413]
1.7.0 release announcement: http://sourceforge.net/mailarchive/message.php?msg_id=27376554
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
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.