Re: Debian Investigation Report after Server Compromises
(Not speaking for Debian at all.)
"Dr. MacQuigg" <macquigg@ece.arizona.edu> writes:
> 1) What is a "sniffed password", and how do they know the attacker
> used a password that was "sniffed", rather than just stolen out of
> someone's notebook?
It sounds like someone's personal machine got broken into, and a
keystroke logger installed. Then they did something like upload a
package and typed their password on the Debian machines, and the
attacker was able to capture the username and password.
> 2) Was the breakin done remotely, or by someone with physical access
> to the machine or network? I thought that "sniffing" required
> physical access to a network over which unencrypted data was being
> transferred. Are the remote logins to Debian servers unencrypted?
I think there's only ssh. (So if you broke into the machine and
installed a compromised ssh binary, that could work to steal a
password too.) "Captured password" might be more correct than
"sniffed". But I haven't heard anything that suggests the attacker
had physical access to anything.
> 3) How does an attacker with a user-level password gain root
> access?
In this case, there was a bug in the kernel that let a user process do
pretty much anything it wanted to, assuming I understand its
implications correctly.
> I understand you can call system services that have root access, and
> provide bad data in those calls that will cause buffer overflows,
> maybe even a machine crash, but how does a buffer overflow allow root
> access? I know there is a deep technical explanation for this, but
> I'm hoping someone can explain it in simple terms, or maybe point me
> to a good article or book chapter.
The usual way this happens is that you have a daemon running as root.
Somewhere there's data being read, and past the end of the data is a
pointer saying where the function should go when it returns. So a
typical buffer overflow attack knows where it expects to be in memory,
and overwrites a fixed-length buffer with more than the expected
amount of data, rewriting the return pointer to point to some code
that also lives on the stack; when the read_input() function returns,
instead of returning to its normal caller, it returns to the attack
code, which is now running as root.
(But note that this is different from the exploit used to gain root on
the Debian servers; there are multiple sorts of vulnerabilities and
therefore multiple exploits.)
--
David Maze dmaze@mit.edu http://www.mit.edu/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
Reply to: