| |||||||||||||
GnuPG signed message spoofing vulnerabilityGnuPG signed message spoofing vulnerabilityPosted Mar 8, 2007 10:01 UTC (Thu) by evgeny (guest, #774)In reply to: GnuPG signed message spoofing vulnerability by evgeny Parent article: GnuPG signed message spoofing vulnerability
Just noticed this in the gpg FAQ:
> 4.16) Can't we have a gpg library?
?!
(Log in to post comments)
GnuPG signed message spoofing vulnerability Posted Mar 8, 2007 18:32 UTC (Thu) by kingdon (subscriber, #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 (guest, #16131) [Link] If you use your private key on a remote host (virtual or not) there aremore 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)
|
|||||||||||||