Okay, I won't send this to the list for every small change, it can now also be found online at: http://www.gt.owl.de/~dnaber/kde/kmail-security.html I took some of your comments as answers. Please look at all the new/changed issues (date == 2000-02-07) and comment if necessary. Thanks Daniel KDE security status: KMail Daniel Naber ([1]dnaber@mini.gt.owl.de), 2000-02-07 The latest version of this document can be found at [2]http://www.gt.owl.de/~dnaber/kde/kmail-security.html "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 issues consists of a question, an explanation and an answer which is specific to this program. * 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. * This is not a TODO list where items eventually disappear once they are resolved. * 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. * Every answer needs a date saying when it has been verified the last time and by whom. 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: grep -E "char\*|char " *.c *.C *.cpp *.cc *.h | grep -v "const char" - | less With char, the use of strcpy() is often problematic. Find it with this command: grep "strcpy" *.c *.C *.cpp *.cc *.h A: grep shows there are still several (~ 30-40) uses of char. Many of these can probably be replaced by QString. There's one function in kmreaderwin.cpp using strcpy() that should be reviewed. However, a test with an manipulated mail where all the common header fields had a length > 4000 showed no problems. (dnaber, 2000-02-06) 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. A: Besides the common libraries (kde, qt, jpeg, png, X11) we are using mimelib, which uses char at many places and strcpy() at two places that we should inspect (not counting the several strcpy() where the second argument is a constant). Other libs?? (dnaber, 2000-02-04) Q: Can the program be run using setuid root? A: KMail is not supposed to be run setuid root. (dnaber, 2000-02-06) 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: grep "system" *.c *.C *.cpp *.cc *.h A: 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, staikos@0wned.org, 2000-02-07) 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 A: KMail uses PGP to encrypt, decrypt and sign messages. These functions are only offered if PGP can be found on the system. We have to rely on PGP without being able to really check the result. The user can see if his messages got "encrypted" in some way if he looks in his sent mail folder. If it's not clear to PGP 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 wheter to cancel or send unencrypted. (Everything in kpgp.cpp) The same applies to GnuPG (??). KMail doesn't use external programs that are expected to run setuid/setgid. KMail cannot check the integrity of external programs, that's beyond its scope. (dnaber, 2000-02-07) 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 dissappear from the configuration files. A: Passwords are saved in the KMail config file, i.e. ~/.kde/share/config/kmailrc. They are not saved as plain text but "encrypted" with a simple scrambling algorithm - encrypting these passwords in a really secure way is impossible. So to protect your passwords you should set the permissions of kmailrc to -rw------- or at least one of .kde/share/config to -rwx------. We still need a way to make this secure by default. Anyway, people really concerned about this should not save their passwords on disk. Saving passwords is off by default (kmacctpop.cpp: mStorePasswd = FALSE;, BUT kmacctpop.cpp: mStorePasswd = config.readNumEntry("store-passwd", TRUE); -- that should be set to FALSE, shouldn't it? And there's readBoolEntry() which suits better... If you deselect the "store password" option, the password to that account is deleted as soon as you close the "Configure Account" dialog (KMAccountSettings::accept()). If you delete an account, the information (including the password) stays in the configuration file (this is a bug). 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 an sshd. (dnaber, 2000-02-07) 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 A:I changed all occurences of tmp files that I found to use KTempFile EXCEPT for the ones in main.cpp. These are probably still a problem but there is a fair amount of code that needs to be reviewed and/or reworked there. (George Staikos, staikos@0wned.org, 2000-02-07) In main.cpp/writePid() the lockfile just get's deleted. Isn't that a case for KTEmpFile, too? (dnaber, 2000-02-07) Issues that are more or less KMail specific (new) Q: Can nobody view my private mail once it's on the local disk? A: KMail stores all mails as plain text in ~/Mail. The permissions of this directory should be set to drwx------ so nobody can view the contents. The only exception is PGP encrypted mail (applies to GnuPG as well, I guess?) -- it gets decrypted every time you view it and is saved on disk as an encrypted mail (as you got it). (dnaber, 2000-02-07) Q: What kind of referer and user agent information does the html widget send if remote images (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". A: The last time we checked (2000-01-28) the user agent had this value: "kio_http ($Revision: 1.85 $); Supports MD5-Digest; Supports gzip encoding; Supports SSL/HTTPS". The referer was not set. We think these values don't reveal any private information. (dnaber, 2000-02-06) Q: How do you ensure Java/Javascript doesn't get executed if I don't want it? Java/Javascript should be off by default. A: Currently JavaScript is not supported or support is not enabled in the HTML widget. I currently cannot test java, my test applet doesn't work in konqueror. (dnaber, 2000-02-06). Q: Is it possible to disable access to remote sites completely when (html) emails are viewed? (i.e. for people with auto-dialin) A: The KHTML guys should comment on this. (dnaber, 2000-02-06) 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. A: The current implementation is *dangerous*. A single click on an attached shell script will execute it. I accidentally clicked on a shell script attached to bugtraq the other day which was a proof-of-concept exploit! (George Staikos, staikos@0wned.org, 2000-02-07) _________________________________________________________________ References 1. mailto:dnaber@mini.gt.owl.de 2. http://www.gt.owl.de/~dnaber/kde/kmail-security.html