Bug 752022 (CVE-2011-4129)
Summary: | CVE-2011-4129 libsocialweb: Untrusted connection to Twitter without user's approval upon service start via dbus | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Sandu Adrian <dexter> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | unspecified | CC: | antillon.maurizio, henrik, jlieskov, jskeoch, mads, mclasen, mschmidt, pasteur, pbrobinson, pingou, rob, vdanen |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-01-06 16:04:26 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 752459 | ||
Bug Blocks: |
Description
Sandu Adrian
2011-11-08 11:13:37 UTC
I would rate this as a security issue by two aspects: * It's a hidden Twitter "bug" that gives Twitter information on every successful Fedora 16 user login to gnome shell in default installation. Without any consent given by the user or any indication that any such notification is taking place. * no verification of the SSL connection is attempted, leaving the exchange wide-open to mitm attacks which I suspect may open up for possible twitter session theft if there is an twitter network account. In addition there is a separate minor bug where the twitter client apparently forgets to close the connection, leaving it in CLOSE_WAIT state until logout. Example data sent to api.twitter.com, extracted by a trivial mitm attack using openssl s_server with a dummy self-signed certificate for a completely different service and iptables nat to redirect the traffic there: GET /friends/ids.xml?screen%5Fname= HTTP/1.1 Host: api.twitter.com Authorization: OAuth realm="", oauth_nonce="3721916599", oauth_consumer_key="7MXEzcmLr0ro5buVLd37Dw", oauth_signature="nEWrwNMAnzn8OqtBw5L5ZbKXyXY%3D", oauth_version="1.0", oauth_timestamp="1320754869", oauth_signature_method="HMAC-SHA1" Connection: Keep-Alive A temporary workaround is to chmod 0 /usr/lib64/libsocialweb/services/libtwitter.so to prevent the twitter client from loading. libsocialweb doesn't run on its own, it gets started by something else via dbus on request. Looking through the deps on a standard gnome-desktop I suspect this is folks as its the only thing that links against it directly. Whether this is then requested by something that then uses folks such as gnome-contacts, gnome-online-accounts or empathy one of the gnome team would need to confirm fact remains that the twitter service is doing a unasked and silent transaction with twitter each time it gets started with no obvious way to disable. looking at the code it seems it tries to avoid this by cheking for a NULL API key, but for some reason it still tries even when there is no twitter account configured. (empty but not NULL? or is there some default public api key?) service/twitter/twitter.c line 512 (In reply to comment #1) > I would rate this as a security issue by two aspects: > > * It's a hidden Twitter "bug" that gives Twitter information on every > successful Fedora 16 user login to gnome shell in default installation. Without > any consent given by the user or any indication that any such notification is > taking place. > > * no verification of the SSL connection is attempted, leaving the exchange > wide-open to mitm attacks which I suspect may open up for possible twitter > session theft if there is an twitter network account. This truly is a security issue. It's a very bad programming custom to open untrusted remote connection without user's approval by default (upon service start). I have stolen this bug to be a 'Security Response' product one. Thank you for notifying us about this. This issue affects the version of the libsocialweb package, as shipped with Fedora release of 14, 15, and 16. Please schedule an update (once final upstream patch known). CVE request: [1] http://www.openwall.com/lists/oss-security/2011/11/09/3 Created libsocialweb tracking bugs for this issue Affects: fedora-all [bug 752459] This issue was assigned the name CVE-2011-4129. Hi, thanks for bringing this to my attention. As Henrik highlighted there are two issues: * A bug where the views will try and fetch content from the web service even if they aren't configured. I fixed this for twitter in: http://git.gnome.org/browse/libsocialweb/commit/?id=8982cf504cf3767761fe85d9558beab3d9da5bec and http://git.gnome.org/browse/libsocialweb/commit/?id=0086bfbfc07345438123a87957e0bc12226e2b94 Many of the backends were derived from twitter so also need an audit to check if they have correct behavior - i'll do that and fix those today and make a new release. * Secondly we should enforce that the SSL certificate is valid - i've done that by fixing librest: https://bugzilla.gnome.org/show_bug.cgi?id=663783 I'll be making a new librest release today too. There is a new librest release that forces trusted certificates - http://ftp.gnome.org/pub/GNOME/sources/rest/0.7/rest-0.7.12.tar.xz > Many of the backends were derived from twitter so also need an audit to check
> if they have correct behavior - i'll do that and fix those today and make a new
> release.
Hi Rob, do you have status on a updated libsocialweb?
Peter, I just uploaded a 0.25.20 to the gnome servers - should be a available in a few minutes. (In reply to comment #13) > Peter, I just uploaded a 0.25.20 to the gnome servers - should be a available > in a few minutes. Rob: thanks, much appreciated rest-0.7.12-1.fc16, libsocialweb-0.25.20-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. rest-0.7.12-1.fc15, libsocialweb-0.25.20-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. All fixed |