After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 388374 - Possible man-in-the-middle password disclosure
Possible man-in-the-middle password disclosure
Status: RESOLVED DUPLICATE of bug 342144
Product: gnome-keyring
Classification: Core
Component: prompting
Other All
: Normal minor
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Reported: 2006-12-21 19:33 UTC by Patryk Zawadzki
Modified: 2007-03-19 02:32 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16

Description Patryk Zawadzki 2006-12-21 19:33:26 UTC
Please describe the problem:
When the "allow access to keyring secret" popup appears, it displays an application-provided title and the executable path. The latter however is useless for apps launched via shebang scripts. For example a Python script shows:

App Foo (/usr/bin/python)

A malicious script could exploit this to attempt a man-in-the-middle attack, providing the same name as the application that normally accesses the secrets (written in the same interpreted language).

Not sure if you consider this a bug really, just reporting it for completness.

Also - is it possible that in such situations the application is identified as /usr/bin/python (or perl or whatever)? I mean, will it even ask if another app identified as /usr/bin/python tries to access a secret that was previously available to the first app? (Did not check the code yet so this might be pure nonsense as I'm sitting here with flu and fever)

Steps to reproduce:

Actual results:

Expected results:

Does this happen every time?

Other information:
Comment 1 Stef Walter 2007-03-19 02:32:51 UTC
A valid (although tough to solve) problem. Already been reported though....

*** This bug has been marked as a duplicate of 342144 ***