Likes Likes:  0
Resultaten 1 tot 2 van de 2
Geen
  1. #1
    Thomas C. Greene
    Inexcusable weakness in Kmail / GnuPG
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Inexcusable weakness in Kmail / GnuPG

    This might well affect more than Kmail on Linux, but i don't do windows so i
    wouldn't know. I'm dealing with GnuPG 0.9.5, Kmail 1.5.1, KDE 3.1.1, and
    kernel 2.4.20, all patched within the past week.

    I do hope that this problem has been discussed previously, because if i'm the
    first person to notice it, heaven help us. But if it *has* been discussed
    previously, well, we've got some useless developers designing e-mail clients.

    Here's the deal: i'm using GnuPG with Kmail, replying to an encrypted memo
    from an anonymous source, and i've naturally got my paranoia level up. Being
    a journo, i can't take any chances, so i don't keep my passphrase in memory.
    It's a small inconvenience, but i don't mind. Of course it's a bloody long
    passphrase, with plenty of special characters, numerals and spaces (or maybe
    not, lol), and i get it wrong way more than half the time (hi Feds); but i
    figure, hey, if someone wants to contact the press in confidence, they
    deserve every possible precaution.

    So i decrypt the incoming message (enter passphrase), and then i reply to it
    (enter passphrase again). After numerous tries, i'm there, because, as i
    said, i'm very much apt to forget this discombobulated passphrase, which i'm
    sure i would forget permanently if there was any serious pressure on my weak
    mind to remember it (hi again Feds).

    At this point, i'm favorably impressed with Kmail's paranoia level. Really,
    that's the kind of thing i like to see.

    So i compose my reply, and i'm just about to click the Send button, when i
    notice, quite by chance, that the reply is *not* encrypted by default, and i
    am not warned about this fact. My reply, and my entire past exchange with
    the source, is about to go out in fscking clear text!

    I confirmed this behavior by sending encrypted memos between several of my own
    e-mail accounts. You can indeed decrypt a memo and reply to it -- with
    everything going out in clear text -- without *any* warning.

    If you forward an encrypted memo as an attachment, the problem doesn't exist.
    You have to enter the passphrase to decrypt the original, before and after
    sending. Which is as it should be. If you forward it inline, there's no
    option to decrypt the memo whether you want to or n only the cyphertext is
    reproduced, and there's no prompt to decrypt it. Which sucks, but is, at
    least, not obviously insecure. (Note that these inconsistencies in behavior
    imply a basically flawed design.)

    But when you reply to an encrypted memo, there is a ludicrous snafu. (Of
    course, you don't have to decrypt a memo to reply to it, and if you fail out
    of the pw prompt, only the cyphertext of the original, and the clear text of
    the reply, will be sent -- although without any warnings or options. Which
    is not great, but not horrible.)

    However, if you reply to a decrypted memo, and enter your passphrase when
    prompted, you'll receive no warnings about the fact that everything will go
    out in clear text automatically after that point.

    Well, i'm sorry, but that just won't do. It's simply not good enough.
    Fortunately, i caught it, but what if i hadn't?

    If the Kmail team can't design a client that knows when decrypted text is
    included in a reply, and encrypt it by default, or at least throw up a
    warning, well, naive users are going to get hosed. I'm not even close to a
    naive user, and i almost got hosed -- and more to the point, my *source*
    almost got hosed.

    I hope that fellow list members will try this with their crypto product of
    choice and e-mail client of choice, and report back. Let's see how
    widespread the problem is. There's no excuse for this behavior. It can
    certainly be fixed, and, indeed, it should have been fixed ages ago --
    unless, by some freak chance, i really am the first person to notice it,
    which i very strongly doubt. I assume that this behavior has been observed
    many times in the past. So why is it still happening on a recently-patched
    system?

    While it's always good for us to be paranoid, we shouldn't *have* to be
    paranoid when using so-called "security" products. The *tool* should be
    paranoid for us, and we should be the ones telling it to slack off.

    with palpable disgust,
    tom

    ===============
    Thomas C. Greene
    Associate Editor
    The Register
    http://www.theregister.co.uk




  2. #2
    Simple Nomad
    Inexcusable weakness in Kmail / GnuPG
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Inexcusable weakness in Kmail / GnuPG


    --=-xoYiErOKtgTRa7Rlksy0
    Content-Type: text/plain
    Content-Transfer-Encoding: quoted-printable

    <snip>

    > So i compose my reply, and i'm just about to click the Send button, when =

    i=20
    > notice, quite by chance, that the reply is *not* encrypted by default, an=

    d i=20
    > am not warned about this fact. My reply, and my entire past exchange wit=

    h=20
    > the source, is about to go out in fscking clear text! =20


    Most if not all mailers are affected by certain bugs related to this. It
    "forgets" the passphrase, but does it free the variable? Does it wipe
    the variable with 0's or random data as soon as it is done with the
    passphrase, assuming it is supposed to forget it? Does it page to swap?
    Can this be prevented by running as root, which can do an mlockall()? Is
    the binary suid root to allow non-root users to mlockall()? Are
    privileges dropped? Is running suid root the best way to solve this
    problem? Is a temp file used to create the encrypted message? Is the
    temp file securely wiped? Where is the temp file written? Can simply
    encrypting/decrypting by hand and importing/exporting/cutting/pasting
    into the mail program an easier way to solve this for paranoid users?

    Most mailers fail one or more of these tests. If this hasn't been
    discussed, it should be, but it should also be discussed in the context
    of whether the system running GPG is secure or not, and how hard would
    it be to exploit the bugs. If someone can access your swap, you have all
    kinds of problems, not just the possible passphrase recovery from the
    swap itself.

    As far as the functional bugs as stated below in mailers, I'm sure there
    are others as I have seen this type of bug before -- where you are
    allowed to sent email unencrypted when you think it is encrypted --
    although for the life of me I cannot remember the mail program. IIRC I
    did report the error to the mailer's authors, but switched mailers. I
    recommend either contacting the authors, writing a patch, or switching
    mail programs.

    --=20
    - Simple Nomad ---- thegnome@nmrc.org ---- thegnome@razor.bindview.com -
    - "Patriotism means to stand by the country. It does not mean to stand -
    - by the President or any other public official." - Theodore Roosevelt -

    --=-xoYiErOKtgTRa7Rlksy0
    Content-Type: application/pgp-signature; name=signature.asc
    Content-Description: This is a digitally signed message part

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQBBy7eAJHqkvWg48R0RAiBbAJ0XqFXSZOe6EcQ/93ZtK5FJQXdmoQCfSknh
    YQeBe6ghktU2xaMm6RoFCls=
    =iTM9
    -----END PGP SIGNATURE-----

    --=-xoYiErOKtgTRa7Rlksy0--


Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics