tsclient stores user/password as clear text

Bug #296682 reported by clovepower
50
This bug affects 5 people
Affects Status Importance Assigned to Milestone
tsclient
Fix Committed
Critical
Unassigned
tsclient (Ubuntu)
Won't Fix
Wishlist
Unassigned
Hardy
Won't Fix
Wishlist
Unassigned
Lucid
Won't Fix
Wishlist
Unassigned
Maverick
Won't Fix
Wishlist
Unassigned
Natty
Won't Fix
Wishlist
Unassigned
Oneiric
Won't Fix
Wishlist
Unassigned

Bug Description

Binary package hint: tsclient

tsclient 0.150-1ubuntu1
Ubuntu 8.04.1 AMD64

If you save tsclient connection parameters as RDP file, all data is stored as plain text, including user name and password to connect to the remote server.

User names and passwords should be stored in user keyring and not made visible.

client hostname:s:
xxxxxxxx
full address:s:xxxxxxx

password:b:xxxxxxxx
username:s:xxxxxxxx

Revision history for this message
clovepower (mzattera) wrote :

Also, the very same data is stored under /home/<user>/.tsclient folder in last.tsc and mru.tsc files.

So, credentials are stored in clear text even if user is not explicitly saving an RDP file.

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :
Changed in tsclient (Ubuntu):
status: New → Confirmed
Kees Cook (kees)
Changed in tsclient (Ubuntu):
importance: Undecided → Wishlist
Revision history for this message
Alex Howells (howells) wrote :

I've also noticed that the files are created with less than perfect permissions:

    -rw-r--r-- 1 ahowells ahowells 872 2009-06-19 20:38 last.tsc
    -rw-r--r-- 1 ahowells ahowells 0 2009-06-19 20:29 mru.tsc

Perhaps it would be possible for them to start life as -rw------- or something, as well?

Revision history for this message
ap (a.p) wrote :

I just discovered this security issue on my own after deciding to inspect my "~/.tsclient/last.tsc" file and couldn't believe this hadn't been reported before. So I decided to do a google search which lead me here.

Guys, this is bad news! As mentioned by clovepower the password is stored *in the clear* even if the user doesn't save the connection settings. All that it's required is that the user enters his/her password on the tsclient window, as opposed to the remote server's login screen. Plus, "~/.tsclient/last.tsc" has world-readable permissions (as mentioned by Alex)!

I'm surprised this issue hasn't been fixed by now since it was first reported back on 11th Nov 2008. That's more than 9 months ago! How come this hasn't been fixed by now? Ubuntu Security Team? Shouldn't the importance of this bug be changed from "Wishlist" to "Medium"?

For now, I guess the only protection against this issue is to NOT enter passwords on the tsclient Logon Settings screen. Instead, users should type their credentials on the *remote server*'s login screen.

$ grep -e username -e password\:b -e address -e domain ~/.tsclient/last.tsc
domain:s:test
full address:s:ts.domain.foo:3389
password:b:mysecretpass
username:s:ap

$ ls -l ~/.tsclient/last.tsc
-rw-r--r-- 1 ap ap 873 2009-08-26 17:46 /home/ap/.tsclient/last.tsc

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 8.04.3 LTS
Release: 8.04
Codename: hardy

$ apt-cache policy tsclient
tsclient:
  Installed: 0.150-1ubuntu1
  Candidate: 0.150-1ubuntu1
  Version table:
 *** 0.150-1ubuntu1 0
        500 http://gb.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

Revision history for this message
Cyclops (rms) wrote :

While it's not using the keyring (which it should), I've added a chmod forcing 0600.
http://tsclient.svn.sourceforge.net/viewvc/tsclient/trunk/src/rdpfile.c?r1=26&r2=105&pathrev=105

Cyclops (rms)
Changed in tsclient:
status: New → Fix Committed
importance: Undecided → High
importance: High → Critical
Revision history for this message
ap (a.p) wrote :

using the keyring would be ideal, but anything other than storing the password in the clear would have been a security improvement IMHO. Hashing the password with a installation-specific salt should be trivial to implement for instance.

Revision history for this message
Cyclops (rms) wrote :

hash+salt is for storing passwords you will authenticate against (like /etc/shadow, for instance). In this case, it's the remote credentials so you don't have to type them on each connection. If it was crypt+salted how would the software know what the password is without showing it to everyone anyways?

The final solution is to use the keyring. I will have to see how that is done (or submit a patch *hint*hint*hint*) :)

Revision history for this message
ap (a.p) wrote :

Cyclops: you're correct that if hashing is used, then the user would not be able to save the password, and would have to retype it for each connection as a hash is not reversible. So yeah, hashing would *not* be a valid solution for users who would like to save their remote connection passwords in order to avoid entering them upon every remote logon.

Changed in tsclient (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

After reading the comments of this bug, I noticed that the password is in a world-readable file and am planning updates for that. Fixing those permissions will remove the security vulnerability. Upstream commented they may move to gnome-keyring in the future, but we won't diverge from upstream on this in Ubuntu, so once the security vulnerability in this bug is fixed, the Ubuntu task will be closed.

Changed in tsclient (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
importance: Wishlist → Medium
status: Triaged → In Progress
Changed in tsclient (Ubuntu Lucid):
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Jamie Strandboge (jdstrand)
Changed in tsclient (Ubuntu Maverick):
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Jamie Strandboge (jdstrand)
Changed in tsclient (Ubuntu Natty):
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Jamie Strandboge (jdstrand)
Changed in tsclient (Ubuntu Hardy):
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Jamie Strandboge (jdstrand)
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Meh, even though I was sure I tested this yesterday before sending this email, I clearly messed something up when I tested. The ~/.tsclient directory is 0700 so there is no security vulnerability after all. I tested on Hardy - Natty. Sorry for the noise.

Changed in tsclient (Ubuntu Lucid):
status: In Progress → Won't Fix
importance: Medium → Wishlist
Changed in tsclient (Ubuntu Maverick):
status: In Progress → Won't Fix
importance: Medium → Wishlist
Changed in tsclient (Ubuntu Natty):
status: In Progress → Won't Fix
importance: Medium → Wishlist
Changed in tsclient (Ubuntu Oneiric):
status: In Progress → Won't Fix
importance: Medium → Wishlist
Changed in tsclient (Ubuntu Hardy):
status: In Progress → Won't Fix
importance: Medium → Wishlist
Changed in tsclient (Ubuntu):
status: In Progress → Won't Fix
importance: Medium → Wishlist
assignee: Jamie Strandboge (jdstrand) → nobody
Changed in tsclient (Ubuntu Hardy):
assignee: Jamie Strandboge (jdstrand) → nobody
Changed in tsclient (Ubuntu Lucid):
assignee: Jamie Strandboge (jdstrand) → nobody
Changed in tsclient (Ubuntu Maverick):
assignee: Jamie Strandboge (jdstrand) → nobody
Changed in tsclient (Ubuntu Oneiric):
assignee: Jamie Strandboge (jdstrand) → nobody
Changed in tsclient (Ubuntu Natty):
assignee: Jamie Strandboge (jdstrand) → nobody
security vulnerability: yes → no
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.