Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 116822 - app-crypt/pinentry: local privilege escalation
Summary: app-crypt/pinentry: local privilege escalation
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B2 [glsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-26 16:01 UTC by Tavis Ormandy (RETIRED)
Modified: 2006-03-24 04:12 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tavis Ormandy (RETIRED) gentoo-dev 2005-12-26 16:01:41 UTC
from pinentry-0.7.2.ebuild:
58 for x in curses qt
59 do
60  [ -f ${D}/usr/bin/pinentry-${x} ] && fperms +s /usr/bin/pinentry-${x}
61 done

I think the developer meant u+s, this needlessly gives users the ability to read and overwrite files with gid 0 (also, is giving a qt application suid root a great idea? an strace suggests it reads numerous configuration files, i'm sure a local root could be found in this package).

# cat secret-file
secret
$ echo > secret-file
-bash: secret-file: Permission denied
$ ls -l secret-file
-rw-rw----  1 root root 7 Dec 26 23:57 secret-file
$ pinentry-curses 
OK Your orders please
OPTION ttyname=secret-file
OK
OPTION ttytype=dumb
OK
GETPIN
^C
# cat secret-file
...
Comment 1 Thierry Carrez (RETIRED) gentoo-dev 2005-12-27 02:57:12 UTC
swegener please comment/fix.
Comment 2 Sven Wegener gentoo-dev 2005-12-27 05:03:14 UTC
I added a -r2 with the fperms call fixed. For the general suid problem, I'd like
to mention that pinentry drops the privileges very early, directly after locking
the memory.
Comment 3 Thierry Carrez (RETIRED) gentoo-dev 2005-12-27 06:25:05 UTC
Thx Sven.
Should we call for stableization on the -r2 ?
Comment 4 Thierry Carrez (RETIRED) gentoo-dev 2005-12-28 07:50:16 UTC
Bah, let's do it.
Target KEYWORDS=KEYWORDS="alpha amd64 ia64 ~mips ppc sparc x86"
Comment 5 Simon Stelling (RETIRED) gentoo-dev 2005-12-28 08:13:41 UTC
amd64 stable
Comment 6 Gustavo Zacarias (RETIRED) gentoo-dev 2005-12-28 09:09:43 UTC
sparc stable.
Comment 7 Mark Loeser (RETIRED) gentoo-dev 2005-12-28 14:18:08 UTC
x86 stable
Comment 8 Tobias Scherbaum (RETIRED) gentoo-dev 2005-12-29 11:57:22 UTC
ppc stable
Comment 9 Fernando J. Pereda (RETIRED) gentoo-dev 2005-12-30 07:44:31 UTC
Stable on alpha now.

Cheers,
Ferdy
Comment 10 Thierry Carrez (RETIRED) gentoo-dev 2006-01-03 07:03:59 UTC
Thx everyone.
GLSA 200601-01
ia64 should mark stable to benefit from GLSA
Comment 11 Werner Koch 2006-01-04 11:33:58 UTC
Folks,

it seems that you did not understand what pinentry is doing.  It is designed to make sure that passpharses are entered as securely as possible.  For Gtk+ we even wrote a new secure entry widget to make use of non-swappable memory (in gpg parlance "secure memory").  When using Linux the required mlock() will only succeed for euid==0.  Thus pinentry allocates the memory right at startup and then drops the privileges.

So for extra security it makes actually sense to install it suid(root). However this is not my descision and the same rationale used to install gpg suid(root) should be applied here.  If gentoo installs Linux with an encrypted swap, there is no need to install it suid(root) but in other cases one might want to do it.

Note, that the whole secure memory business is limited by the IPC mechanism used:  The passphrases is eventually passed trough pipe buffers; we expect that they are soon reused and zeroed out.
Comment 12 Tavis Ormandy (RETIRED) gentoo-dev 2006-01-04 12:04:43 UTC
Hey werner, the bug was that the ebuild incorrectly set the sgid bit, we still install pinentry with the suid bit set. This was a bug in our ebuild, not with pinentry btw :)