[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    security status
From:       Daniel Naber <dnaber () mini ! gt ! owl ! de>
Date:       2000-02-07 22:09:58
[Download RAW message or body]


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

[prev in list] [next in list] [prev in thread] [next in thread]