WKS enabled for gnupg.net and gnupg.org

[Phil Pennock]

On 2016-08-31 at 19:21 +0200, Werner Koch wrote:
>   An easy way of testing the system exists for [Mutt] and Gnus users: By
>   adding the two lines
> 
>   ,----
>   | application/vnd.gnupg.wks; /usr/local/libexec/gpg-wks-client \
>   |    -v --read --send; needsterminal; description=WKS message
>   `----
> 
>   to `/etc/mailcap' Mutt will do the decryption job and then call the
>   wks-client for the protocol handling.  It can be expected that Mutt
>   users have a /usr/lib/sendmail installed which is required here.  Note
>   that `--read' is used which tells the client that the input mail has
>   already been decrypted.

Problem: I like GnuPG in part because of it's support for the concept of
privacy.  This mailcap setting is rather dangerous from that
perspective.  Fortunately mutt does not autoview by default, but that's
a thin layer of ice to be resting upon.

This command appears to be usable, with that MIME type, as a probe for
an email handler which can then reply, sending arbitrary commands via
email to arbitrary addresses.

The fingerprint: isn't verified (a FIXME), the sender: doesn't appear to
be validated as being at least in the same domain as a uid on the key.
The nonce is sent back, but that can be arbitrary text with nvc_parse()
explicitly handling continuations for multi-line data and gpg-wks-client
only checking that the nonce is long enough.

The one saving grace is that it looks like the message isn't signed?  (I
haven't read the code deeply enough to be sure).

I've commented this back out of my .mailcap as there's a rethink needed,
IMO.

At a bare minimum, any command designed to be invoked from mailcap
should respect the privacy of the reader by not communicating remotely
without positive confirmation from the user first.  gpg-wks-client
should, in this scenario, parse the message, construct something to show
the user, show it, flush existing keyboard input and prompt for
confirmation before sending data remotely.

Bonus points for ensuring that nonce can't be used for issuing arbitrary
commands for arbitrary systems via email and other forms of validation.

The approach is sane and with right tools integration this could be
valuable ("click button to register key with email server") but at
present much more is needed before this can be a template for adoption.
But hey, that's the point of the -devel list and catching these things
early, right?

Regards,
-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: </pipermail/attachments/20160901/0e9ddfd8/attachment.sig>