Ubuntu
gstm package

Pressing cancel on gaskpass dialog should return non-zero error.

Bug #276517 reported by Trochee
2
Affects Status Importance Assigned to Milestone
gstm (Ubuntu)
Fix Released
Low
Ryan Niebur

Bug Description

Binary package hint: gstm

gaskpass (the utility within the gstm distribution) does not return non-zero error code when the user presses cancel.

A user presented with a gaskpass prompt might expect that pressing cancel would deny access. from x11-ssh-askpass(1x) [note especially the final sentence]:

> Pressing the ‘OK’ button accepts the pass-phrase (even if it is empty), which is printed on the standard output,
> and the dialog exits with a status of zero (success). Pressing the ‘Cancel’ button discards the pass-phrase,
> and the dialog exits with non-zero status.

The failure to exit with non-zero status is a serious problem, because dialogs (e.g. the session-multiplexing prompts) that are not really asking for passwords are confused by having "ok" and "cancel" have the same behavior. In the session-multiplexing environment, a user's intention to deny access to the multiplexed session could be ignored and access granted anyway.

Related branches

lp:debian/squeeze/gstm
Revision history for this message
Trochee (trochee) wrote :

related bug: https://bugs.launchpad.net/ubuntu/+source/gstm/+bug/276534
suggests a drop-in patch that would resolve this issue for security concerns as well.

Revision history for this message
Trochee (trochee) wrote :

On reflection the patch suggested there would only partially resolve the security concerns -- the only client application (gstm) would no longer use gaskpass but gaskpass would still be installed. A further fix would actually remove gaskpass from the system or fix the behavior identified here (and several other behaviors mentioned as gaskpass bugs within gstm).

Revision history for this message
Ryan Niebur (ryan52) wrote :

Hello,

Really, this is not a "security" problem, and I don't really see how it could be. however, it should be fixed, and I will work on this. This bug is trivial to fix, so I will just fix it as opposed to removing gaskpass.

Thanks for the bug report,
Ryan

Changed in gstm:
assignee: nobody → ryan52
status: New → In Progress
Nathan Handler (nhandler)
Changed in gstm:
importance: Undecided → Low
Revision history for this message
Trochee (trochee) wrote :

why *not* remove gaskpass ? It's AFAICT completely outside the mission of gSTM and a perfectly good replacement exists for it (using ssh_askpass, as suggested elsewhere).

having a separate and relatively untested codebase that does something security-related (bugs in code that asks for passwords is totally a security concern, I'm sorry to disagree) just seems like asking for trouble, when there's a well-tested and widely-used equivalent available with a minor code change (that I've already submitted) on a different gstm bug (https://bugs.launchpad.net/ubuntu/+source/gstm/+bug/276534) as mentioned above.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gstm - 1.2-7

---------------
gstm (1.2-7) unstable; urgency=low

  * Remove gaskpass. gaskpass is just another ssh askpass program, and
    doesn't do anything special. It does not grab focus, which means
    that key loggers can listen in on what you type, aiui. Seeing as how
    it is just reinventing the wheel, I see no reason to keep it around.
    (Fixes LP: #276530, #276517, #276525, #276529, #276534)
  * Do not explicitly set the ssh timeout, as that causes problems on
    slow networks. (Fixes LP: #293240)

 -- Ubuntu Archive Auto-Sync <email address hidden> Mon, 24 Nov 2008 09:48:55 +0000

Changed in gstm:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.