[Bug 668591] Re: opencryptoki module crashes in firefox due to due to symbol conflict between trousers and libselinux
Bug Watch Updater
668591 at bugs.launchpad.net
Thu Oct 26 22:08:31 UTC 2017
Launchpad has imported 22 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=464042.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2008-09-26T01:27:08+00:00 David wrote:
After working around the problem in bug #464037, I still have problems
getting the OpenSSL TPM engine to work...
Starting program: /usr/bin/openssl s_client -connect vpntest:332 -cert /home/dwmw2/cert.pem -key /home/dwmw2/cert.pem -keyform engine -engine tpm -crlf
[Thread debugging using libthread_db enabled]
[New Thread 0x7f68fa0247a0 (LWP 28806)]
engine "tpm" set.
SRK authorization:
Program received signal SIGSEGV, Segmentation fault.
0x0000003728883b7f in memcpy () from /lib64/libc.so.6
(gdb) bt
#0 0x0000003728883b7f in memcpy () from /lib64/libc.so.6
#1 0x00000000008c3442 in Trspi_UnloadBlob (offset=0x7fff02043610,
size=1819239265, from=0x0, to=0x5fdc <Address 0x5fdc out of bounds>)
at /usr/include/bits/string3.h:52
#2 0x00000000008c58f1 in Trspi_UnloadBlob_KEY_PARMS (offset=0x7fff02043610,
blob=0x7fff02043720 "Bag Attributes\n localKeyID: 01 00 00 00 \n Microsoft CSP Name: Microsoft Enhanced Cryptographic Provider v1.0\n friendlyName: 4b158d80b5c95de9bdfbae54ed0877ed_4cd35c06-4849-425c-9237-bc97ca4385"...,
keyParms=0x7fff020435b0) at trousers.c:528
#3 0x00000000008c665b in Trspi_UnloadBlob_KEY (offset=0x7fff02043610,
blob=0x7fff02043720 "Bag Attributes\n localKeyID: 01 00 00 00 \n Microsoft CSP Name: Microsoft Enhanced Cryptographic Provider v1.0\n friendlyName: 4b158d80b5c95de9bdfbae54ed0877ed_4cd35c06-4849-425c-9237-bc97ca4385"...,
key=0x7fff020435a0) at trousers.c:623
#4 0x00000000008b0749 in UnloadBlob_TSS_KEY (offset=0x7fff02043610,
blob=0x7fff02043720 "Bag Attributes\n localKeyID: 01 00 00 00 \n Microsoft CSP Name: Microsoft Enhanced Cryptographic Provider v1.0\n friendlyName: 4b158d80b5c95de9bdfbae54ed0877ed_4cd35c06-4849-425c-9237-bc97ca4385"...,
key=0x7fff020435a0) at tsp_key.c:64
#5 0x00000000008a42a3 in Tspi_Context_LoadKeyByBlob (tspContext=3221225473,
hUnwrappingKey=3221225477, ulBlobLength=4096,
rgbBlobData=0x7fff02043720 "Bag Attributes\n localKeyID: 01 00 00 00 \n Microsoft CSP Name: Microsoft Enhanced Cryptographic Provider v1.0\n friend---Type <return> to continue, or q <return> to quit---
lyName: 4b158d80b5c95de9bdfbae54ed0877ed_4cd35c06-4849-425c-9237-bc97ca4385"..., phKey=0x7fff02044720) at tspi_key.c:457
#6 0x0000000000113653 in tpm_engine_load_key ()
from /usr/lib64/openssl/engines/libtpm.so
#7 0x0000003732c9ffc8 in ENGINE_load_private_key () from /lib64/libcrypto.so.7
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/0
------------------------------------------------------------------------
On 2008-09-26T01:56:05+00:00 David wrote:
In Trspi_UnloadBlob_KEY_PARMS(), keyParms->parmSize seems to be set to a very large number. When I enter the function, it's set to 0x48dc1426. After the call to Trspi_UnloadBlob_UINT32(offset, &keyParms->parmSize, blob);
it gets set to 0x6c6f6361. On this machine, a malloc of that size succeeds, and we then try an insanely-large memcpy.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/1
------------------------------------------------------------------------
On 2008-09-26T06:27:02+00:00 David wrote:
Oh, running it with -cert test.key instead of pointing it at a text PEM
file makes it stop segfaulting. It's just not doing _any_ validation on
its input.
Still a little confused... I can use 'create_tpm_key' to put a key into
the TPM, but I'm still left with a key on my file system. Isn't that
supposed to be in the TPM, while I only have the certificate on the file
system?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/2
------------------------------------------------------------------------
On 2008-09-26T20:58:03+00:00 Rajiv wrote:
Hi David,
We are still investigating the first issue. About the second question,
your key isn't in a plain form on your filesystem, it's wrapped by
another one in a way you'll always need a key located inside the TPM in
order to decrypt the ones stored out of it.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/3
------------------------------------------------------------------------
On 2008-09-27T00:42:04+00:00 David wrote:
OK, thanks. By the 'first issue' do you mean the segfault in
context_free(). That's purely a libselinux bug (bug #464037) -- it's
polluting the namespace, and you're calling _its_ function when you mean
to call your own. You can work around the bug by renaming your
context_free() function.
What I'm trying to do is just the equivalent of
curl_easy_setopt(curl, CURPOPT_SSLCERT, "/home/dwmw2/cert.pem");
...except that obviously I want the key to be stored in the TPM. Is that
possible?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/4
------------------------------------------------------------------------
On 2008-09-28T07:31:52+00:00 David wrote:
OK, now I think I have my application working, at least using TPM-
emulator. I applied the following patches to Trousers:
http://david.woodhou.se/trousers-0.3.1-workaround-selinux-namespace-pollution.patch
http://david.woodhou.se/trousers-0.3.1-use-tpm-emu.patch
http://david.woodhou.se/trousers-0.3.1-reuseaddr.patch
I also applied this patch to the openssl TPM engine from CVS, so that it would let me wrap an existing certificate rather than failing:
http://david.woodhou.se/tpmengine-fix-wrap.patch
I think I can now use my VPN client to connect using the certificate in the TPM:
http://git.infradead.org/users/dwmw2/anyconnect.git?a=commitdiff;h=d460790a
Now, it seems that I'm limited to having the 'key' and the certificate
in separate files. Is there any way to store them in the same PEM file?
And please can we have the openssl TPM engine shipped in Fedora?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/5
------------------------------------------------------------------------
On 2008-10-01T13:58:01+00:00 Rajiv wrote:
Thanks for the patches regarding the namespace conflict and the miss of
-w option, I'll commit the fixes.
The only pending question here is the one regarding the key storage. The
method used in create_tpm_key is, as we see, storing it in the
filesystem, encrypted so it cannot be directly read. To avoid
cryptanalysis, one can use the persistent storage inside the chip, by
registering the key with an id (UUID) inside it, and loading it later,
as done with the SRK key, using that id. This second method isn't
available in create_tpm_key.c, but it's possible to be implemented using
the TSS functions.
Regarding shipping it in Fedora, sure, if you need anything else from me
to make the request accomplished, please let me know.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/6
------------------------------------------------------------------------
On 2008-10-01T15:37:32+00:00 David wrote:
For bonus points, we should have something like the ---BEGIN TSS KEY
BLOB--- part in the PEM file, which can contain _either_ a UUID or the
encrypted blob.
In the absence of that, how would I go about using the engine with a key
stored inside the chip? Or listing the keys which are stored there?
Under Windows, a 3-year client certificate for our VPN has been stored
in the chip. It would be nice to be able to use that under Linux instead
of the 2-day certificates they're currently giving us for testing
purposes. :)
Strangely, key access in Windows only works if the TPM is marked as
_disabled_ in the BIOS. (Thinkpad T61)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/7
------------------------------------------------------------------------
On 2008-10-27T21:50:33+00:00 IBM wrote:
Making Rajiv the owner on our end.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/8
------------------------------------------------------------------------
On 2008-10-29T16:51:05+00:00 IBM wrote:
(In reply to comment #7)
> ------- Comment From dwmw2 at infradead.org 2008-10-01 11:37:32 EDT-------
> For bonus points, we should have something like the ---BEGIN TSS KEY BLOB---
> part in the PEM file, which can contain _either_ a UUID or the encrypted blob.
>
But, I can't see what are the disadvantages of using (in this context) a
wrapped key instead of a key inside the tpm, if you can have virtually
unlimited space available in the host machine?
> In the absence of that, how would I go about using the engine with a key stored
> inside the chip? Or listing the keys which are stored there?
Without this, from what I know, it's impossible. To list the keys inside
the tpm, you could use ps_inspect to parse your /var/lib/tpm/system.data
>
> Under Windows, a 3-year client certificate for our VPN has been stored in the
> chip. It would be nice to be able to use that under Linux instead of the 2-day
> certificates they're currently giving us for testing purposes. :)
I'll check this out.
>
> Strangely, key access in Windows only works if the TPM is marked as _disabled_
> in the BIOS. (Thinkpad T61)
>
In Windows, as far as I know, there isn't a TSS compliant API
implemented, but a TBS. It provides a limited set of resources, like key
slots, authentication slots, so that it's possible to manage keys with
it, but not necessarily take profit of its trusted computing
capabilities. Since this API is more like an core interface to the
device, I assume it only counts on TPM commands that doesn't require an
owner flag set, so can be used when disabled.
I cannot assure there isn't a TSS compliant API implemented "now", it's
just what I last read about Windows status on TC. :-)
David's patch that fix this is already upstream.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/9
------------------------------------------------------------------------
On 2008-11-17T20:00:42+00:00 IBM wrote:
Created attachment 323791
Upstream patch
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/10
------------------------------------------------------------------------
On 2008-12-16T23:08:14+00:00 David wrote:
Did we ship Fedora 10 with this still broken?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/11
------------------------------------------------------------------------
On 2008-12-16T23:32:58+00:00 David wrote:
Looks like we did. I've committed the fix and built packages for F-10
and rawhide.
If you approve, please push the F-10 update and also build for F-9.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/12
------------------------------------------------------------------------
On 2009-05-14T00:09:47+00:00 Milos wrote:
(In reply to comment #12)
> Looks like we did. I've committed the fix and built packages for F-10 and
> rawhide.
>
> If you approve, please push the F-10 update and also build for F-9.
...will do that.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/13
------------------------------------------------------------------------
On 2009-05-14T00:10:53+00:00 Milos wrote:
P.S: David, if you'd like to comaintain the package, you're welcome of
course!
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/14
------------------------------------------------------------------------
On 2009-05-14T21:27:55+00:00 Fedora wrote:
trousers-0.3.1-10.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/trousers-0.3.1-10.fc9
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/15
------------------------------------------------------------------------
On 2009-05-14T21:30:11+00:00 Fedora wrote:
trousers-0.3.1-14.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/trousers-0.3.1-14.fc10
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/16
------------------------------------------------------------------------
On 2009-05-15T23:28:49+00:00 Fedora wrote:
trousers-0.3.1-14.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update trousers'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-4999
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/17
------------------------------------------------------------------------
On 2009-05-15T23:33:07+00:00 Fedora wrote:
trousers-0.3.1-10.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing-newkey update trousers'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-5029
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/18
------------------------------------------------------------------------
On 2009-06-10T02:48:49+00:00 Bug wrote:
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/19
------------------------------------------------------------------------
On 2009-06-16T01:26:20+00:00 Fedora wrote:
trousers-0.3.1-10.fc9 has been pushed to the Fedora 9 stable repository.
If problems still persist, please make note of it in this bug report.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/20
------------------------------------------------------------------------
On 2009-06-16T02:36:15+00:00 Fedora wrote:
trousers-0.3.1-14.fc10 has been pushed to the Fedora 10 stable
repository. If problems still persist, please make note of it in this
bug report.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/comments/21
** Changed in: trousers (Fedora)
Status: Unknown => Fix Released
** Changed in: trousers (Fedora)
Importance: Unknown => Medium
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to trousers in Ubuntu.
https://bugs.launchpad.net/bugs/668591
Title:
opencryptoki module crashes in firefox due to due to symbol conflict
between trousers and libselinux
Status in trousers package in Ubuntu:
Fix Released
Status in trousers package in Debian:
Fix Released
Status in trousers package in Fedora:
Fix Released
Bug description:
Binary package hint: trousers
When using the opencryptoki module with firefox (which is not directly
possible right now, I should file a different bug about that), the
browser crashes during shutdown. This is due to the fact that both
libtspi and libselinux define a function called context_close(), and
they get mixed up (when libtspi calls context_close, libselinux's
version of that function is used instead)
This was fixed in debian in 0.3.1-10, and upstream at some point
(certainly by maverick's 0.3.5)
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: libtspi1 0.3.1-7ubuntu4
ProcVersionSignature: Ubuntu 2.6.32-25.45-generic 2.6.32.21+drm33.7
Uname: Linux 2.6.32-25-generic x86_64
NonfreeKernelModules: openafs
Architecture: amd64
Date: Fri Oct 29 19:31:31 2010
ProcEnviron:
PATH=(custom, user)
LANG=en_US.utf8
SHELL=/bin/zsh
SourcePackage: trousers
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/668591/+subscriptions
More information about the foundations-bugs
mailing list