Menu
▾
▴
#159 kdesktop_lock can be unlocked by scim
open-accepted
5
2011-08-17
2009-01-05
No
It is possible to unlock kdesktop_lock on systems with configured scim without entering a password. This makes it possible to access data of other users or access random locked PCs (best place to start such an attack would be in some asian countries).
The system was configure as described in http://ubuntuforums.org/showthread.php?p=2704098 but with japanese tables. You must be sure that scim is enabled (for example by pressing ctrl+space and entering some test data. Then start kdesktop_lock manually by calling `kdesktop_lock --forcelock` and move your mouse/press some key to start the password dialog. Just press cancel and move your mouse or press something on you keyboard again. This should crash kdesktop_lock and enable access to the desktop.
It was tested on different systems and it could reproduced on all.
This problem is also known by upstream kdesktop but marked it as invalid because kdesktop isn't maintained anymore (instead they thing everybody should use kde 4 stuff). http://bugs.kde.org/show_bug.cgi?id=149512
Only workaround seems to disable scim and stop to write in a foreign language with complex characters... which is not acceptable.
see also http://bugs.debian.org/510851 for downstream bug report
skim version is 1.4.5
scim-qtimm is 0.9.4
scim-tables-ja is 0.5.8
kdesktop is 3.5.9
--- System information. ---
Architecture: i386
Kernel: Linux 2.6.26-1
Debian Release: 5.0
500 unstable ftp.de.debian.org
500 testing debian.netcologne.de
--- Package information. ---
Depends (Version) | Installed
========================================-+-=====================
kdelibs4c2a (>= 4:3.5.9) | 4:3.5.10.dfsg.1-1
libc6 (>= 2.7-1) | 2.7-16
libgcc1 (>= 1:4.1.1) | 1:4.3.2-1.1
libgl1-mesa-glx | 7.2-1
OR libgl1 |
libglu1-mesa | 7.0.3-7
OR libglu1 |
libkonq4 (>= 4:3.5.9) | 4:3.5.9.dfsg.1-6
libqt3-mt (>= 3:3.3.8b) | 3:3.3.8b-5
libstdc++6 (>= 4.1.1) | 4.3.2-1.1
libx11-6 | 2:1.1.5-2
libxau6 | 1:1.0.3-3
libxcursor1 (>> 1.1.2) | 1:1.1.9-1
libxext6 | 2:1.0.4-1
libxss1 | 1:1.1.3-1
libxxf86misc1 | 1:1.0.1-3
kdebase-bin (= 4:3.5.9.dfsg.1-6) | 4:3.5.9.dfsg.1-6
kdeeject | 4:3.5.9.dfsg.1-6
Could you give me the backtrace.
Please ask how to do that the maintainer of that package.
Maybe, there are debuginfo packages for them somewhere.
After installing them, you can get the backtrace by following steps.
1. Login and prepare for the test.
2. Move to a virtual console by pressing Ctrl-Alt-F2.
3. Login CUI environment, and get the pid of kdesktop_lock. (ps -A | grep kdesktop_lock)
4. Launch GnuDebugger and hook SCIM process. (gdb kdesktop_lock <pid of kdesktop_lock>)
5. Press c to continue, and return to X by pressing Ctrl-Alt-F7.
6. Cause the problem and return to the virtual console again.
7. The debugger must suspended for some exception. You can get the backtrace by pressing 'b'.
Backtrace is in the kde bug, patch to fix the problem is in the debian bug
Debian include this patch to fix the problem: http://patch-tracking.debian.net/patch/series/view/scim-qtimm/0.9.4-4/20_reset-frontend-data.dpatch
Where is discussion for this patch?
I cannot import your patch file without checking it.
It's not "mine". Zhe Su <zsu@novell.com> from Novell created that one:
References for that patch are:
https://bugzilla.novell.com/show_bug.cgi?id=206547
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510851
https://bugs.launchpad.net/ubuntu/+source/scim-qtimm/+bug/145906
http://support.novell.com/techcenter/psdb/4aa8b9487cca8ccf8cada6013098419c.html
https://bugs.kde.org/show_bug.cgi?id=141974
https://bugs.kde.org/show_bug.cgi?id=150138
...
Or what kind of discussion do you mean?
Okay, now I see. :)
I'll import this patch for this developing cycle.
what is the status here? Can this ticket be closed?