Cool, now that we got that out, I have another questions for ya. If you've already been attacked by that damned ssh crc 32 crap, and all the memory got used up and your box was locked up and you hit the on/off switch to reboot, and it fscked when it started again and then you reboot and then logon and root can not ls, rm, mv, chown, chgrp, rpm etc (shows fatal local crc 32 in the logs) then what? Is it a root kit on that sucker or are there some corupted inode files , and how would one remove or check for that rootkit and how would one fix the bad inodes? The box is running but it seems root has no control. On Wednesday 21 November 2001 06:56 am, you wrote:

Is it nit picking time already? Didn't know that, OMG! ;)

While we're at it, if you're running SSH protocol version 2 (in any implementation) *and* a vulnerable SSH protocol 1 demon, with a fallback to V1 for compatibilty with the lame old ssh1, you're vulnerable too, congratulations.

Boris Lorenz ---

Hi, the main question is, if your SSH daemon is vulnerable. The option "Protocol 2,1" sets only the preferred version to SSH2. You're allowed to connect with SSH1 too. Cheers, Ralf

Boris Lorenz wrote:

...

Yuppa,

On 21-Nov-01 Reckhard, Tobias wrote:

...

...

...

that a flaw in the SSH1 protocol has been used to break into the

two said

...

...

^^^^^^^^^^^ ...

...

There is a remote integer overflow vulnerability in several implementations of ^^^^^^^^^^^^^^^^^^^^^^ the SSH1 protocol that allows an attacker to execute arbitrary code

with

...

...

the ^^^^^^^^^^^^^^^^^

Note the (more or less subtle) difference.

Tobias

Que...?

Is it nit picking time already? Didn't know that, OMG! ;)

While we're at it, if you're running SSH protocol version 2 (in any implementation) *and* a vulnerable SSH protocol 1 demon, with a fallback to V1 for compatibilty with the lame old ssh1, you're vulnerable too, congratulations.

Hi, so the next question is: If I run only SSH 2 daemon but with sshd_config Option "Protocol 2,1 " for compatibility - is it vulnerable? Annette Sysadmin IfM Technical University Berlin Germany

...

Boris Lorenz ---

-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

Yuppa, On 21-Nov-01 Reckhard, Tobias wrote:

...

...

that a flaw in the SSH1 protocol has been used to break into the two said ^^^^^^^^^^^ ... There is a remote integer overflow vulnerability in several implementations of ^^^^^^^^^^^^^^^^^^^^^^ the SSH1 protocol that allows an attacker to execute arbitrary code with the ^^^^^^^^^^^^^^^^^

Note the (more or less subtle) difference.

Tobias

Que...? Is it nit picking time already? Didn't know that, OMG! ;) While we're at it, if you're running SSH protocol version 2 (in any implementation) *and* a vulnerable SSH protocol 1 demon, with a fallback to V1 for compatibilty with the lame old ssh1, you're vulnerable too, congratulations. Boris Lorenz ---

On Wed, 21 Nov 2001, Annette Jaekel wrote:

Hi, so the next question is: If I run only SSH 2 daemon but with sshd_config Option "Protocol 2,1 " for compatibility - is it vulnerable? Annette Sysadmin IfM Technical University Berlin Germany

It sure is. The cracker will connect pretending not to be able to do protocol 2, and your system will obligingly pull out the (vulnerable) protocol 1 for her. Bear

Yo phil & others, On 21-Nov-01 Annette Jaekel wrote:

Boris Lorenz wrote:

...

Yuppa,

On 21-Nov-01 Reckhard, Tobias wrote:

...

...

...

that a flaw in the SSH1 protocol has been used to break into the two said ^^^^^^^^^^^ ... There is a remote integer overflow vulnerability in several implementations of ^^^^^^^^^^^^^^^^^^^^^^ the SSH1 protocol that allows an attacker to execute arbitrary code with the ^^^^^^^^^^^^^^^^^

Note the (more or less subtle) difference.

Tobias

Que...?

Is it nit picking time already? Didn't know that, OMG! ;)

While we're at it, if you're running SSH protocol version 2 (in any implementation) *and* a vulnerable SSH protocol 1 demon, with a fallback to V1 for compatibilty with the lame old ssh1, you're vulnerable too, congratulations.

sorry phil, I can't quote your original message, since my pine decidet to be a naughty piece of bytes, and ate your posting... So, from the top of my head, your problem was that you had suffered from a crc32 compensation attack, and now seem to have no control over the system anymore, not even if logged in as root. Well, let's separate two things here: First, there's the crc32 attack, which exploits vulnerable implementations of the SSH1 protocol, by overflowing the variable space of a 16bit integer, which should have been a 32bit integer. The result of this attack is a (remote) root compromise, since most (all?) installations of sshd (1+2) run as root. Second, it's up to the imagination/skill of the attacker(s) what to do next. Typically, a rootkit will be installed, which trojanizes several binutils, installs backdoors and whatnot. WHICH rootkit (if any) is active on your system is a matter of further analysis. Finally, most attackers will try to clean the logs of any suspicious entries. The SuSE security FAQ at http://www.susesecurity.com/faq provides you with a good starting point for your investigations. In short: 1.) Secure the scene 2.) Take the system offline 3.) Backup any logfiles, configs and other essential stuff 4.) Take a quick first look into all of your logs 5.) Check for rootkits, e. g. with chkrootkit from http://www.chkrootkit.org 6.) Create an image of the cracked fs (e. g. with "dd"), and let the Coroner's Toolkit (TCT) utils inspect it (get TCT from http://www.fish.com/forensics ) 7.) Look for "anomalities", which may include: - strange log entries in messages, maillog, wtmp, lastlog, warn, etc. - Unusual entries in .bashrc/.profile/.login in home dirs - hidden files/directories - unknown directories in /dev, /var, /home, /usr, /opt, /mnt, etc. - unknown users in /etc/passwd or /etc/shadow - strange entries in /etc/crontab, or user's crontabs - setgid/setuid files - network interfaces in promiscuous mode (sniffers) - ... TCT is a toolkit for forensic examinations ("WHO made WHAT, WHEN, and WHY"). It collects any information it can find about a file system, and provides a basis for further investigations, which comes in handy if your regular system logs are insufficient. Beware, some TCT tools (namely unrm/Lazarus) run for several hours, and need lots of disk space. While TCT runs, read all its docs, and the additional info about the art of forensic examination on www.fish.com/forensics. It's not about learning this technique in one day, but a good place to start. After the data collection is completed, browse the Coroner logs for said anomalities. TCT also creates md5 checksums for every file, which could be compared to known-clean files of the same SuSE distro. If any of you crc32 victims need additional info, you may as well drop me a private mail. Boris Lorenz ---