Bug 3099 - when used in URI, (https://USERNAME:MYPASSWORD@mailserver/home/USERNAME/Calendar), password stored in plain text
: when used in URI, (https://USERNAME:MYPASSWORD@mailserver/home/USERNAME/Calen...
Status: RESOLVED FIXED
Product: Claws Mail
Classification: Unclassified
Component: Plugins/vCalendar
: 3.9.3
: PC Linux
: P3 enhancement
Assigned To: users
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-06 09:04 CET by Tomas Radej
Modified: 2016-08-08 11:00 CEST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Radej 2014-03-06 09:04:55 CET
Hi.

I am concerned about the fact that the Claws vCalendar plugin stores username and password to an authenticated address in plain text. There is currently no way around it that I can see. This seriously, seriously insecure and prevents me from using this plugin at all.

Can you please implement the option to type in the username and password every time Claws starts, such as the main application allows with e-mail accounts?

Thank you, Tomas Radej
Comment 1 Ricardo Mones 2014-03-06 10:20:35 CET
There's several layers of security before reaching your vcalendar password: your home/office walls and door, your computer BIOS password, your disk encryption password, your system account password, and an (optional) encrypted filesystem loop-mounted on .claws-mail for storing Claws Mail config.

If you have all of these correctly set with strong (and different) passwords (which I presume since you're concerned about security) I don't see why this is so seriously insecure.

Said that I agree that not storing it in plain text would be a nice feature to have, so setting it as enhancement.
Comment 2 Tomas Radej 2014-03-10 11:37:56 CET
What about any process, running with the current user ID, being able to access each and every file in the .claws-mail folder? Simple grep -R reveals numerous occurrences of the password in files in that folder.

Futhermore - by default, .claws-mail, and everything in it, is readable to anyone on the computer.

This indeed is a major security flaw, not an enhancement. Please, treat is as such.
Comment 3 Tomas Radej 2014-03-10 14:36:49 CET
Correction, the ~/.claws-mail directory is not visible to everyone, but that does not invalidate the general argument.
Comment 4 Michal Karm Babacek 2014-03-10 16:06:58 CET
"DO keep your passwords secret. Putting them into a file on your computer, e-mailing them to others, or writing them on a piece of paper in your desk is tantamount to giving them away." -- Bruce Schneier, Password Advice, August 10, 2009
Comment 5 Ricardo Mones 2014-03-10 16:23:35 CET
Not sure if you had read my initial comment or not. AFAIK "any process, running with the current user ID" is by definition all the processes run by you. Don't see why Claws Mail should protect your .claws-mail dir from your processes, unless you share your account password with somebody else.

As explained you can have your .claws-mail stored in a encrypted volume (or loop-back mounted filesystem), only password mounted when you run Claws Mail, umounted afterwards. Your current user ID visitors would only see an empty .claws-mail (unless you're running Claws Mail at the same time, of course).

You can also use SELinux to restrict access to your .claws-mail to claws-mail binary only, for example. And also this combined with the above.

So, even if you share your password, there's workarounds to avoid others seeing that password. Not without some effort, of course.
Comment 6 Jan Kriho 2014-03-10 17:44:47 CET
(In reply to comment #5)
> So, even if you share your password, there's workarounds to avoid others
> seeing that password. Not without some effort, of course.

However, the best way to secure a password is not to store it anywhere, as requested in the second paragraph of the original bugreport:

> > Can you please implement the option to type in the username and password
> > every time Claws starts, such as the main application allows with e-mail
> > accounts?

Regards,

Jan Kriho
Comment 7 Ricardo Mones 2014-03-10 18:35:50 CET
> However, the best way to secure a password is not to store it anywhere,
> as requested in the second paragraph of the original bugreport

Sure, that's why I marked it as enhancement.
Comment 8 Tomas Radej 2014-03-11 10:13:29 CET
I can not deny being disappointed to see that the creators of a program handling most personal information of its users approach basic security as an enhancement, rather than a priority. However, I am not going to put more pressure on you as I don't think it will be constructive.

Much luck to you in your future endeavours.

Tomas Radej
Comment 9 Ricardo Mones 2014-03-11 10:52:08 CET
> I can not deny being disappointed to see that the creators of a program 
> handling most personal information of its users approach basic security 
> as an enhancement, rather than a priority. However, I am not going to put
> more pressure on you as I don't think it will be constructive.

Since you don't have any argument now the problem is our attitude towards your bug, that you try to extrapolate to our attitude towards security?

Nice try, but not.

> Much luck to you in your future endeavours.

We love you too, thanks for reporting.
Comment 10 Tomas Radej 2014-03-11 12:46:29 CET
I have plenty of arguments. I just didn't feel like going on, but I can give you a sample all right.

*) A program running under my UID might very well be malicious. Every year, guys at #pwn2own find a couple of ways to hijack a browser. Let alone the JVM. We've all been there. Presuming user apps are benign is just *plain wrong*. This problem sort of can be worked out with SELinux, as you suggested, but read on.

*) SELinux currently works only with some distros, and is a sort of a pain to configure, at least in Debian, where I tried it. In a related problem, you need a root password to do it. The user may not have it.

*) Your approach delegates security of your application to other applications, and is, by default, opt-in. If you see nothing wrong with that, I can't really argue with you, because we are not operating on the same level.

Are more arguments required?
Comment 11 Jan Kriho 2014-03-11 12:59:54 CET
(In reply to comment #7)
> > However, the best way to secure a password is not to store it anywhere,
> > as requested in the second paragraph of the original bugreport
> 
> Sure, that's why I marked it as enhancement.

I agree with you that storing paswords encrypted is a nice-to-have enhancement. However I still consider requiring user to store his password (and only offering it to do unencrypted) a security bug.
Comment 12 Paul 2014-03-11 13:17:51 CET
But, can I point out, amongst all the hyperbole, that the password is not stored in plain text?
Comment 13 Tomas Radej 2014-03-11 13:40:31 CET
(In reply to comment #12)
> But, can I point out, amongst all the hyperbole, that the password is not
> stored in plain text?

Is it not?

[tradej@localhost .claws-mail]$ grep -R MYPASSWORD
Binary file imapcache/mailserver/tradej/fedora/devel/.claws_cache matches
folderlist.xml:        <folderitem use_cal_view="1" uri="https://USERNAME:MYPASSWORD@mailserver/home/USERNAME/Calendar" last_seen="0" order="0" watched="0" ignore="0" locked="0" forwarded="0" replied="0" total="0" marked="0" unreadmarked="0" unread="0" new="0" mtime="0" sort_type="ascending" sort_key="date" hidereadthreads="0" hidedelmsgs="0" hidereadmsgs="0" threaded="1" thread_collapsed="0" collapsed="0" path=".Calendar" name="Calendar" type="normal" />
Comment 14 Jan Kriho 2014-03-11 13:44:35 CET
(In reply to comment #13)

I'd also be concerned about storing the password in the cache:

> [tradej@localhost .claws-mail]$ grep -R MYPASSWORD
> Binary file imapcache/mailserver/tradej/fedora/devel/.claws_cache matches
Comment 15 Paul 2014-03-11 13:49:17 CET
In the vCalendar prefs we can see the option `export_freebusy_pass`. Since this is where it asks for a password I presumed that you meant here.
Comment 16 Paul 2014-03-11 13:51:28 CET
(In reply to comment #14)
> (In reply to comment #13)
> 
> I'd also be concerned about storing the password in the cache:
> 
> > [tradej@localhost .claws-mail]$ grep -R MYPASSWORD
> > Binary file imapcache/mailserver/tradej/fedora/devel/.claws_cache matches

Aren't we talking about the vCalendar plugin here?
Comment 17 Tomas Radej 2014-03-11 13:57:40 CET
(In reply to comment #16)
> (In reply to comment #14)
> > (In reply to comment #13)
> > 
> > I'd also be concerned about storing the password in the cache:
> > 
> > > [tradej@localhost .claws-mail]$ grep -R MYPASSWORD
> > > Binary file imapcache/mailserver/tradej/fedora/devel/.claws_cache matches
> 
> Aren't we talking about the vCalendar plugin here?

We are. Apparently, the plugin stores the URI there as it stands. The moment the calendar gets deleted, the entry disappears (not true for the cache, obviously).
Comment 18 Paul 2014-03-11 13:58:30 CET
(In reply to comment #14)
> (In reply to comment #13)
> 
> I'd also be concerned about storing the password in the cache:
> 
> > [tradej@localhost .claws-mail]$ grep -R MYPASSWORD
> > Binary file imapcache/mailserver/tradej/fedora/devel/.claws_cache matches


It's not stored in the cache
Comment 19 Paul 2014-03-11 14:03:28 CET
(In reply to comment #17)

> We are. Apparently, the plugin stores the URI there as it stands. The moment
> the calendar gets deleted, the entry disappears (not true for the cache,
> obviously).

So you are saying that your vcalendar password is stored in your imap account's cache??
Comment 20 Tomas Radej 2014-03-11 14:06:17 CET
(In reply to comment #19)
> (In reply to comment #17)
> 
> > We are. Apparently, the plugin stores the URI there as it stands. The moment
> > the calendar gets deleted, the entry disappears (not true for the cache,
> > obviously).
> 
> So you are saying that your vcalendar password is stored in your imap
> account's cache??

The vCalendar password is stored in the URI (because it's not currently possible any other way), and I have no other interpretation for the grep match other than it's indeed stored there.
Comment 21 Paul 2014-03-11 14:12:03 CET
(In reply to comment #20)

> The vCalendar password is stored in the URI (because it's not currently
> possible any other way)

OK, good. Then it's a feature request.
Comment 22 Henri Salo 2014-03-12 07:52:24 CET
CVE request: http://www.openwall.com/lists/oss-security/2014/03/10/7
Comment 23 Paul 2014-03-12 08:26:27 CET
(In reply to comment #22)
> CVE request: http://www.openwall.com/lists/oss-security/2014/03/10/7

Thank you, Henri Salo, for the absolute overkill.

I wonder, have you reported, say, firefox for storing bookmarks in exactly the same manner. Or perhaps postgresql, filezilla, and a large number of other apps too?? Oh, of course, you have, I don't need to ask.
Comment 24 Henri Salo 2014-03-12 08:32:27 CET
I did not create the request. I just added the link here so that people reading this bug report are aware of it. And no, I have not reported similar issues if I remember correctly nor have I requested CVEs for such issues.

You should reply to that oss-security mailing list thread if you think this issue is not security related / critical enough and does not needs CVE.

I have not used time to investigate this issue (yet). I'm just making sure security vulnerabilities are fixed in Debian distro if such are fixed from Claws Mail upstream project.

Thank you for your efforts.
Comment 25 Paul 2014-03-12 08:34:57 CET
(In reply to comment #24)

Then I apologise for the accusation and aim it instead at the anonymous submitter.
Comment 26 Michael Schwendt 2014-03-12 10:25:46 CET
It's certainly not an anonymous submitter.
Comment 27 Paul 2014-03-13 09:51:40 CET
(In reply to comment #26)
> It's certainly not an anonymous submitter.

http://www.openwall.com/lists/oss-security/2014/03/12/1
Comment 28 Tomas Radej 2014-03-13 16:23:07 CET
I wasn't going to comment further on the matter, but I have to.

<rant>

While the CVE might indeed be an overkill, I do not agree with this being a hack. You may very well claim that you don't support this feature of the HTTP protocol, but I say that every program that can query a HTTP URL can by definition support HTTP authentication. If you don't agree with this interpretation, fine. Let me just point out that even the bloody Internet Explorer 5 stripped the credentials off the entry in History.

</rant>
Comment 29 Klaus Kusche 2014-08-10 21:34:18 CEST
Another vote for this one.
This is my central LDAP password at our university.
It allows to modify all my student's grades,
it allows to register students as present or absent,
it allows to read and send my mail,
it allows to change my web presence,
it allows to hook up to our WLAN in my name etc.
And it allows to change my password!

Claws is the only program storing it in clear text,
there is no other clear text copy of that password on any of my disks.
Comment 30 Klaus Kusche 2014-08-11 12:42:00 CEST
May I suggest to use a master password as a fix (like thunderbird, firefox 
and some other programs do) to encrypt all passwords on disk, 
and to decrypt them when claws is started?!

Clear-text passwords on disk are a major problem!
(among other problems, this implies clear text passwords on backups -ugh!).
Comment 31 Andrej Kacian 2016-08-08 11:00:49 CEST
vCalendar plugin now stores its passwords in encrypted form.