xlockmore - serious security issue

[Andrew Pantyukhin]

On 6/14/06, Simon L. Nielsen <simon at freebsd.org> wrote:
> On 2006.06.13 18:51:48 +0400, Andrew Pantyukhin wrote:
> > On 6/13/06, Anish Mistry <amistry at am-productions.biz> wrote:
> > >On Tuesday 13 June 2006 07:54, Andrew Pantyukhin wrote:
> > >> On 6/13/06, Anton Berezin <tobez at tobez.org> wrote:
> > >> > On Tue, Jun 13, 2006 at 03:18:16PM +0400, Andrew Pantyukhin wrote:
> > >> > > The problem is that xlockmore exits all by itself when
> > >> > > left alone for a couple of days. It works all right overnight,
> > >> > > but when left for the weekend, it almost certainly fails. I
> > >> > > just come to work and see that my workstation is unlocked,
> > >> > > what a surprise.
> [...]
> > >I just stick with a blank screen and works fine for several weeks at a
> > >time.  I found some of the GL screensavers to cause problems.
> >
> > Ask me - we should mark this port forbidden and/or make
> > and entry in vuxml until we resolve this issue. Let's make
> > blank screen the default behavior or something. To leave
> > this as is is unacceptable.
>
> FORBIDDEN and a VuXML entry seems in a way a bit overkill to me seems
> a bit overkill to me, since it's not really a vulnerability, but I'm
> open to input.
>
> As mentioned by others, xlockmore is fundamentally flawed
> wrt. guaranteeing that the screen stays locked in that the
> screensavers code can kill the lock, which it should not be able to
> happen.
>
> Has anyone contacted the xlockmore author for comment on this issue?
>
> One thing we could do right now is to add a message at install time
> warning that xlockmore might unlock the screen (a bit like the Pine
> warning).

High time we settled on something.

Now that we had this discussion, I only use the swarm
mode and never had any problems with it. But what
about those who still don't know about the issues?
I've been in situations where accidental unlocking
was unacceptable. In most cases unlocking implies
immediate root access to the local machine (which
is also possible, but more complicated, with plain
physical access), but more importantly - decrypted
auth info in RAM, such as ssh keys. This is a major
security breach. IMHO, we can't overestimate it.

I'm quite sure an ignorable/overlookable message is
not enough. A user must fully understand all the
implications of this software being used. If it's
fundamentally flawed, let's forbid/remove it _until_
the author has a statement for us, not after that.