[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-05-01 15:19:29
[Download RAW message or body]

Hi,

here's an update of the security paper. Please, everyone, mail updates or 
ideas.

Regards
 Daniel

i
                          KDE security status: KMail
                                       
   Daniel Naber ([1]dnaber@mini.gt.owl.de), 2000-05-01
   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.
     * 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.
       
   External links:
     * [3]How to Write Secure Code - various links to papers, howtos etc.
     * There's a program at called ITS4 at [4]www.rstcorp.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 [5]mini.gt.owl.de/~dnaber/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:
   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 > 10000 showed no problems. Everything was okay with an HTML
   attachment that had extremly long tags and tag properties, too.
   (dnaber, 2000-05-01)
   
   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 (Code in
   kpgp.cpp and kpgpbase.cpp). 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)
   
   If more than one version of PGP/GnuPG is installed, KMail prefers PGP5
   over GnuPG and it prefers GnuPG oder PGP2 (Kpgp::checkForPGP()). Maybe
   we should give the user better feedback about that.
   
   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-13)
   
   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, which has permissions 0600 when it is
   created, thanks to KConfig. Exisiting (old) configuration files get
   secure permissions when they are changed. Still there's some script
   that runs whenever KDE is updated, perhaps this could chmod() the old
   files, too? (dnaber; Harri Porten, porten@tu-harburg.de, 2000-04-23)
   
   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 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? (should be fixed - check)
   
   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 small 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-08)
   
   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 (there are no uses of temp files
   anymore?? dnaber, 2000-05-01). 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)
   
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).
   
   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 (MComposeWin::deadLetter()) (dnaber, 2000-05-01)
   
   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 the user agent had this value:
   "Konqueror ($Revision: 1.129 $); Supports gzip encoding".
   The referer was not set. We think these values don't reveal any
   private information. (dnaber, 2000-05-01)
   
   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 complete, but when it's ready it will
   be off by default. (Harri Porten, porten@tu-harburg.de, 2000-02-13)
   
   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. But you can disable HTML
   mail at all (Settings/Appearance/Layout). (dnaber, 2000-05-01)
   
   Q: Can somebody set a cookie on my system by sending me an HTML mail?
   
   A: The KHTML guys should comment on this. (dnaber, 2000-05-01)
   
   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: (BUG) 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)
   
   Q: What about the automatic return receipt?
   This should be off by default.
   
   A: A patch is in the works that lets it default to off
   (ConfigureDialog::setupMiscPage()). (dnaber, 2000-05-01)
     _________________________________________________________________

References

   1. mailto:dnaber@mini.gt.owl.de
   2. http://www.gt.owl.de/~dnaber/kde/kmail-security.html
   3. http://www.shmoo.com/securecode/
   4. http://www.rstcorp.com/its4/
   5. http://mini.gt.owl.de/~dnaber/its4/

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