(Not speaking for Debian at all.) "Dr. MacQuigg" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://www.mit.edu/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]