Archive:KMail/Security

Warning

Much of this is very old, though the principles are still relevant. Additionally, the subject here is KMail 1 - some of these answers may not be correct for KMail 2. If you are able to update these entries, please do so

KMail: Security

Daniel Naber ([email protected]), 2002-11-14

"Security is not a state, it's a process."

This information gives an overview of (possible) security issues in a certain KDE software and how these issues are addressed by the developers. The aim should be to keep this list complete (as far as it's possible) and up to date. It can also be used as a checklist when preparing releases.

• This information is intended for all the people who are in any way involved with this software: developers, developers of libraries and components, people making packages, distributors, interested users.

• Every issue consists of a question, an explanation and an answer which is specific to KMail.

• Every claim about the code of the program should contain a reference in the form class::function() so it can easily be verified by others.

• If there are known problems/bugs that haven't been solved, yes, they do belong on the list.

• You are encouraged to expand this list. You are encouraged to define ways which help to find potential problems in large amounts of code.

• The word BUG in an entry says that this issue really needs to be fixed.

• Every answer needs a date saying when it has been verified the last time and by whom.

• This is not a TODO list where items eventually disappear once they are resolved.

External links:

• How to Write Secure Code - various links to papers, howtos etc.

• There's a program called ITS4 at http://www.cigital.com/its4/ that can be used to scan code for possible security problems. It's probably more powerful and yet easier to use than the suggested grep commands in this document. (The authors of ITS4 ask for your name and email address if you want to download the software. If you don't like that, get it at http://www.danielnaber.de/its4/).

General issues for all programs

Q How do you protect against buffer overflows?

The common buffer overflow may occur with the use of char for strings. Using QString is safe. You can check where char is used with this command:

char " *.c *.C *.cpp *.cc *.h 

With char, the use of strcpy() is often problematic. Find it with this command:

grep "strcpy" *.c *.C *.cpp *.cc *.h

grep shows there are still several (~90) occurences of char. Many of these can probably be replaced by QString. However, a test with several manipulated mails where all the common header fields had a length > 10000 showed no problems. Everything was okay with an HTML attachment that had extremely long tags and tag properties, too. (dnaber, 2002-11-13)

Q What about buffer overflows in the libraries you use?

If a library has a potential buffer overflow, an exploit would have the same impact as an exploit in the program itself.

Besides the common libraries (kde, qt, X11, ...) we use mimelib, which uses char at many places and strcpy() at two places (not counting the several strcpy() where the second argument is a constant) which seem to be okay (protocol.cpp and msgid.cpp). We also use libkdenetwork (which is also in kdenetwork). There are three occurences of strcpy(), two of which are inside comments, and the last one looks safe (in kmime_headers.cpp) (dnaber, 2002-11-14)

Q Can the program be run as root?

KMail is not supposed to be run as root. (dnaber, 2002-11-13)

Many systems prohibit the access to the root mail account via pop3 protocol.

Tip

If you want or have to read the mail of root let the mailsystem forward the mail to your user account by adding the file ~/.forward to root's home directory. The content of this file should be your email address. (Ferdinand Gassauer, 2001-03-20)

Q Do you use system() calls in a safe way?

The only vulnerability is if the string passed to system() is generated using data that comes from an email etc. OR if there is a buffer overflow or severe logic bug that allows an email to modify global variables over several passes through the execution path which eventually effects the system() call (or in the buffer overflow case, overflows a local variable and overwrites the next local variable which is used for the system() call.) Find the use of system() with this command:

egrep "system *?\(" *.c *.C *.cpp *.cc *.h

I'm planning to go through and change most of these if I can (where possible). The most dangerous system call is yet to be implemented, but it's a great feature as well and the people who will typically use such a thing will probably be someone who is at least fairly aware of the implications. I will probably put some documentation in place as a warning as well. Essentially I want to implement something like Pine's | command, where you can pipe an email to a shell command. Obviously if it does a system() call based on what's in the email it could be a problem. (George Staikos, [email protected], 2000-02-07)

The only system() calls left are the ones for file locking in kmfoldermbox.cpp (dnaber, 2002-11-14)

Q What external programs do you use?

Using external programs might become a problem if:

• they are called with system() and user-supplied input (see above)
• if we rely on their function without being able to check it
• if these programs have been compromised
• if these programs are setuid/setgid

KMail uses PGP/GnuPG to encrypt, decrypt and sign messages (code in libkdenetwork in kpgp.cpp and kpgpbase.cpp). These functions are only offered if PGP/GnuPG can be found on the system. The user can see if his message got encrypted by enabling "Show signed/encrypted text after composing". This is enabled by default. We call PGP/GnuPG with LANGUAGE=C so the output is always English. If it's not clear to PGP/GnuPG what key to use for encryption the user is offered a choice of all keys. If he doesn't choose one there's a dialog asking him whether to cancel or send the mail unencrypted. Important: Attachments are not encrypted, even if the mail is, unless crypto plugins are used.

GnuPG might be setuid in order to enable it to lock memory (in order to prevent your passphrase from being swapped out of memory).

KMail cannot check the integrity of external programs, that's beyond its scope. (dnaber, Ingo Kloecker, 2002-11-14)

Q How are saved passwords protected?

Passwords should be saved on disk only when the user explicitly says so. If the user later deactivates the function to save the password, an already saved password should disappear from the configuration files.

Passwords are saved in the KMail config file, i.e. ~/.kde/share/config/kmailrc, which has permissions 0600 when it is created, thanks to KConfig. Existing (old) configuration files get secure permissions when they are changed.

The passwords are not saved as plain text but "encrypted" with a simple scrambling algorithm - encrypting these passwords in a really secure way is impossible. Anyway, people really concerned about this should just not save their passwords on disk.

Saving passwords is off by default(kmacctexppop.cpp: mStorePasswd = FALSE and config.readNumEntry("store-passwd", FALSE)).

If you deselect the store password option, the password to that account is deleted as soon as you close the Configure Account dialog (KMAcctExpPop::writeConfig() resp. KMAcctImap::writeConfig()).

If you delete an account, the information stays in the configuration file, but the password gets removed by a hack in NetworkPage::ReceivingTab::apply().

BTW, if you want to encrypt your POP3 connection to the remote server: that's possible with ssh, the remote server just needs to run sshd, see the KMail FAQ for more information. (dnaber, 2002-11-14) (Note: this does not appear to be referring to the UserBase KMail FAQ - at this moment I can not link to the reference. Anne Wilson 2011-17-16)

Q Are temporary files used in a safe way?

One can make temporary files using KTempFile (in kdecore), which uses the secure mkstemp(). The use of mktemp() is deprecated, it's highly insecure. One should never make temp files by just open()ing them, since they could already exist and they could even be a link to something completely different. You can find some possibly incorrect uses of temp files with these commands:

grep "/tmp" *.c *.C *.cpp *.h

grep "mkstemp" *.c *.C *.cpp *.h

grep "mktmp" *.c *.C *.cpp *.h

I changed all occurences of tmp files that I found to use KTempFile. (George Staikos, [email protected]; dnaber, 2002-11-14)

Issues that are more or less KMail specific

Q What major security related features does KMail offer?

• SSL, TLS for both POP3 and IMAP
• Authentication: SMTP Auth, PLAIN, LOGIN, CRAM-MD5, DIGEST-MD5, APOP
• Integration of PGP/GnuPG
• Crypto plugins

(dnaber, 2002-11-14)

Q Can anybody view my private mail once it's on the local disk?

KMail stores all mails as plain text by default in ~/Mail. The permissions of this directory should be set to drwx------ so only you can view the contents. PGP/GnuPG encrypted mail gets decrypted every time you view it and is saved on disk as an encrypted mail again (as you got it).

If ~/Mail doesn't exist, KMail will create it with the correct permissions (KMFolderMgr::setBasePath()).

The file ~/dead.letter, which is created if KMail crashes, has correct permissions (KMComposeWin::deadLetter()). ### what about attachments, saved to disk temporary? (dnaber, 2002-11-14)

Q How do you ensure Java/Javascript and other dynamic content doesn't get executed if I don't want it?

Dynamic content should be off by default.

It's disabled in KMReaderWin::initHtmlWidget(). This is true for Java, Javascript, Plugins and the "refresh" meta tag. It's currently not even possible to turn on these features. (dnaber, 2002-11-14)

Q Is it possible to disable access to remote sites completely when (html) emails are viewed?

(i.e. for people with auto-dialin)

Yes. In the security settings you can disable loading of any external references. The default is to not load external references (see SecurityPage::GeneralTab::setup()), and to not display HTML (all places where the config key "htmlMail" is loaded) (Ingo Kloecker; dnaber 2002-11-14)

Q Can somebody set a cookie on my system by sending me an HTML mail?

Default behaviour is not to load external stuff at all (see above), so we don't need to care anymore about this. (dnaber, 2002-11-14)

Q What kind of referer and user agent information does the html widget send if remote imag(etc) are in a page?

Anybody sending you an email with remote components (images etc.) that are located on his own server can check his httpd access logs to see the date and time you read the mail. The referer (it's optional for the client to transmit it) says "where you came from".

Default behaviour is not to load external stuff at all, so we don't care anymore about a possible referer if you activate it. (dnaber, 2002-11-14)

Q How do you make sure evil attachments are not executed, except I explicitly say so?

This also includes not executing a "viewer" for some content unless the user explicitly wants it. For every attachment there should be a way to call it with a text editor to check it - even if it is associated to some viewer.

The user is asked if he wants to open the attachment. He's notified that this may be a security problem. If there's a default application for that kind of file, that application is offered. If there's none, an "Open with..." dialog is offered. The dialog also has a "Save to disk" button, which is the default one (see KMReaderWin::slotAtmOpen()) (dnaber, 2002-11-14)

Q What about the automatic return receipt?

This should be off by default, i.e. the client should not by default reply to those. If it demands return receipts in its own mails by default is not a privacy/security issue (well, at least not for the sender...).

It is off by default. Check with grep "send-receipt" *.cpp *.h, all the defaults are false. (dnaber, 2002-11-14)