[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Security flaw in klock (fwd)
From:       Martin Jones <mjones () powerup ! com ! au>
Date:       1999-06-24 11:23:15
[Download RAW message or body]

Martin Jones wrote:
> 
> Here's a patch.  I haven't managed to reproduce the bug since
> applying it.  I had much trouble reproducing the bug before
> applying this patch, so could someone who can reproduce it
> reliably please test this.

Sorry for replying to my own post.  Here's what was happening:

1. A timer is set to delete the passwd entry dialog after
   a period of inactivity (5secs).
2. When the user hits enter a program is run (kcheckpass) to
   determine whether a valid password was entered.
3. While klock is waiting for kcheckpass to complete it calls
   QApplication::processEvents().

So if the timer is triggered while we are waiting for
kcheckpass to complete, the dialog is deleted.  When
kcheckpass completes, we continue on but the dialog has
been deleted from under us -> crash.

This is easier to replicate if kcheckpassis slow on your
particular machine.  I can replicate this bug very easily
by adding a sleep(2) to kcheckpass.  I am applying this
patch to the 1.1 and head branches.

Martin.


> 
> -------------------------------- cut -----------------------
> diff -u -r1.13.4.2 saver.cpp
> --- saver.cpp   1999/05/28 09:37:28 1.13.4.2
> +++ saver.cpp   1999/06/24 10:42:34
> @@ -151,6 +151,7 @@
> break;
> 
> case Key_Return:
> +            timer.stop();
> waitForAuthentication = true;
> if ( tryPassword() )
> emit passOk();
> -------------------------------- cut -----------------------
> 
> > ----- Forwarded message from Matt Wilson <msw@redhat.com> -----
> > 
> > Message-ID: <19990623190903.I6066@devserv.devel.redhat.com>
> > Date: Wed, 23 Jun 1999 19:09:03 -0400
> > From: Matt Wilson <msw@redhat.com>
> > To: BUGTRAQ@netspace.org
> > Cc: Maurizio Paolini <paolini@DMF.BS.UNICATT.IT>, ettrich@kde.org
> > Subject: Re: Security flaw in klock
> > References: <199906230823.KAA28861@gauss.dmf.bs.unicatt.it>
> > Mime-Version: 1.0
> > Content-Type: text/plain; charset=us-ascii
> > X-Mailer: Mutt 0.91.1
> > In-Reply-To: <199906230823.KAA28861@gauss.dmf.bs.unicatt.it>; from Maurizio Paolini on Wed, Jun 23, \
> >                 1999 at 10:23:26AM +0200
> > Status: RO
> > Content-Length: 1840
> > Lines: 53
> > 
> > I've confirmed this race.  Here's the fullproof method to recreate the
> > problem:
> > 
> > 1)  Run klock.
> > 2)  Hit <enter> at the first password prompt.  klock says, "Failed".
> > 3)  Watch closely and count the number of times the cursor blinks.
> > On my system, from the time you hit enter till the dialog disappears
> > you'll have 10-11 blinks.
> > 4)  On or just after the 10th blink (just as the dialog would disappear),
> > hit <enter>.
> > 5)  Poof - klock segfaults and access is granted.
> > 
> > It may take a few tries, but I've gotten to where I can hit the
> > race every time.
> > 
> > I am able to reproduce this in the KDE RPMS that shipped in Red Hat
> > Linux 6.0 and the updated RPMS released a few days ago.
> > 
> > Digging into source now (*grumble*, yet another KDE update)...
> > 
> > Matt Wilson
> > msw@redhat.com
> > 
> > On Wed, Jun 23, 1999 at 10:23:26AM +0200, Maurizio Paolini wrote:
> > > Hello,
> > > this is my first post to this list, so please forgive me if this
> > > is off topic or badly formulated.
> > > 
> > > It seems to me that anyone can take control of a local kde session
> > > locked with klock (the default locking mechanism of kde).
> > > 
> > > This was discovered by my 7 years old son, who was just trying
> > > to gain control of my session by typing randomly on the keyboard, and
> > > it just involves the "backspace" key and the "enter" key, and perhaps
> > > the "caps lock" key.
> > > 
> > > It actually takes a few tries, and I don't know of a precise sequence
> > > of keys.  What I do is
> > > 
> > > 1. wait for the "enter password" message.
> > > 2. press the "caps lock" once or twice.
> > > 3. press the "backspace" six times with different timings each try.
> > > 4. press the enter key.
> > > 
> > > After a few tries (usually five to ten...) klock dies with no message.
> > > 
> > > If this is confirmed by someone else it seems to be a serious
> > > flaw of klock (or a backdoor?)
> > > 
> > > Thank you,
> > > 
> > > Maurizio Paolini
> > LocalWords:  klock
> > 
> > ----- End forwarded message -----

-- 
Martin Jones
mjones@kde.org


[prev in list] [next in list] [prev in thread] [next in thread]