User: Password:
|
|
Subscribe / Log in / New account

GnuPG signed message spoofing vulnerability

GnuPG signed message spoofing vulnerability

Posted Mar 8, 2007 9:57 UTC (Thu) by evgeny (guest, #774)
Parent article: GnuPG signed message spoofing vulnerability

If GPG were written in a good style (here meaning separating the application and the core C API, with the latter being installed alongside the exec), most of clients would use that API directly, with such kinds of spoofing impossible. And the wrappers like GPGME (which internally calls the gpg executable) wouldn't be needed.


(Log in to post comments)

GnuPG signed message spoofing vulnerability

Posted Mar 8, 2007 10:01 UTC (Thu) by evgeny (guest, #774) [Link]

Just noticed this in the gpg FAQ:

> 4.16) Can't we have a gpg library?
>
> This has been frequently requested. However, the current viewpoint of the GnuPG maintainers is that this would lead to several security issues [...]

?!

GnuPG signed message spoofing vulnerability

Posted Mar 8, 2007 18:32 UTC (Thu) by kingdon (guest, #4526) [Link]

Well, the FAQ doesn't elaborate, but it is generally good security practice to try to isolate different components, so that bugs or compromises in one would not tend to affect the others. For example, the way postfix is broken into several executables, or the way it is widely considered to be bad to have a GUI application setuid.

Now, in the GPG context it isn't quite as clear-cut, since GPG isn't setuid, but still, the number of possible couplings (including undesired ones) between a library and its caller are greater than between an executable and its caller.

GnuPG _is_ setuid

Posted Mar 8, 2007 22:00 UTC (Thu) by ballombe (subscriber, #9523) [Link]

GPGP is setuid to be able to lock memory pages from being swapped to disk.

GnuPG _is_ setuid

Posted Mar 10, 2007 14:31 UTC (Sat) by evgeny (guest, #774) [Link]

There is no need to worry about memory pages not being swapped to disk when verifying a signed message against a _public_ key...

GnuPG _is_ setuid

Posted Mar 11, 2007 17:51 UTC (Sun) by ekj (guest, #1524) [Link]

True. But the very same users (be they people or mail-programs) that want to verify the integrity of a message using a public key frequently also wants to sign a message using a secret key.

True, true, one *could* do the former with a C-library, and the latter by piping to a setuid-executable, but most developers would probably consider the two funcitons related and prefer they both be accesses by the same mechanism.

GnuPG _is_ setuid

Posted Mar 11, 2007 21:40 UTC (Sun) by evgeny (guest, #774) [Link]

Well, such functions may have e.g. insecure_ prefix added, and/or put into a separate header file so one makes an educated decision when using them.

In general, though, the locked-to-RAM pages are more or less a fiction. With the VM stuff entering our life, what an OS believes is RAM might actually be a swap in the host. Ditto for software/hardware suspend etc. All in all, I prefer a clean API over a mess with potential marginal extra security through the locked pages (and much less marginal chances of get screwed because of potential bugs in gpg being run setuid). Not to mention that e.g. ssh doesn't use mlock so ... why would one worry about gpg specifically?

GnuPG _is_ setuid

Posted Mar 12, 2007 10:34 UTC (Mon) by ekj (guest, #1524) [Link]

True. There are good arguments in favour of just dropping whatever trickery requires setuid at the moment, in which case a library is unproblematic. I'm just saying, aslong as you *DO* want memory-locking, you're going to need an external app for atleast those parts. And if so, that external app may aswell do verification too, not only signing.

GnuPG _is_ setuid

Posted Mar 16, 2007 12:28 UTC (Fri) by robbe (subscriber, #16131) [Link]

If you use your private key on a remote host (virtual or not) there are
more practical attack vectors. But best practise is to have the private
key only on a device in front of you -- in this case leakage to swap is a
concern. But suid-to-root is a stupid hack, better solutions are:
(a) allow mlock() for non-root users (I had a trivial kernel patch for
this ten years ago)
(b) no swap
(c) encrypted swap (what I use today)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds