Message-ID: <Pine.LNX.4.21.0702131923050.10319-100000@linuxbox.org>
Date: Tue, 13 Feb 2007 19:24:34 -0600 (CST)
From: Gadi Evron <ge@...uxbox.org>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Cc: funsec@...uxbox.org
Subject: Solaris telnet vuln solutions digest and network risks

A couple of updates and a summary digest of useful information shared from
all around on this vulnerability, for those of us trying to make sense of
what it means to our networks:

1. Sun released a patch (although it is not a final one). It can be found
on their site ( http://sunsolve.sun.com/tpatches - thanks to Casper Dik of
Sun, for those who have been following the discussion).

To quote: "the simplest possible fix on such short notice":
http://cvs.opensolaris.org/source/diff/onnv/onnv-gate/usr/src/cmd/cmd-inet/usr.sbin/in.telnetd.c?r2=3629&r1=2923

2. If you haven't already, I strongly recommend checking your network for
machines running telnet, and more specifcially, vulnerable to this
particular issue.

Several folks are speaking of third-party appliances running on Solaris,
as well as some back-end VoIP devices that have been confirmed as
vulnerable.

Apparently, telnet returns a different answer when this vulnerability is
used. We are not sure yet, but Noam Rathaus brought up the option that it
looks like the client responds with a "Won't Authentication Option" to the
server's "Do Authentication Option". This could perhaps be used to
actively detect the "attack".

3. If this solution is viable for you and you haven't already, ACLing
23/tcp at the border or from your user space may not be a bad idea, if it
won't kill anything. At least for now.

4. Bleeding Edge (ex Bleeding Snort) released snort signatures for this:
http://www.bleedingthreats.net/index.php/2007/02/12/solaris-remote-telnet-root-exploit-signature/

Quoting:
--------
Chris Byrd has submitted an accurate signature for the exploit.
# Submitted 2007-02-12 by Chris Byrd
alert tcp $EXTERNAL_NET any -> $HOME_NET 23 (msg:.BLEEDING-EDGE EXPLOIT
Solaris telnet USER environment
vuln.; flow:to_server,established; content: .|ff fa 27 00 00 55 53 45 52
01 2d
66|.; rawbytes; classtype:attempted-user; reference:url,riosec.com/solaris-telnet-0-day; sid:2003411; rev:1;)
--------

4. An analysis of how this vulnerability works can be found here:
http://www.com-winner.com/0day_was_the_case_that_they_gave_me.pdf

And blogs by Sun on how this happened and was fixed (thanks to Georg
Oppenberg):
http://blogs.sun.com/tpenta/entry/the_in_telnetd_vulnerability_exploit
http://blogs.sun.com/danmcd/entry/how_opensolaris_did_its_job

And a fine explanation by Casper Dik on Bugtraq:
http://seclists.org/bugtraq/2007/Feb/0205.html

5. Apparently, this is the same vulnerability in 'login' that was in AIX
in 1994:
http://www.cert.org/advisories/CA-1994-09.html
http://osvdb.org/displayvuln.php?osvdb_id=1007

6. Vulnerable systems: reports are unclear, some or all of Solaris 10. No
earlier versions of Solaris/SunOS are vulnerable.

6. Other workarounds exist. Brad Powell suggested on Full-Disclosure:

Quoting:
--------
For root login; there is a setting in /etc/default/login. If CONSOLE is
set, then root can only login on that device
i.e. "CONSOLE=/dev/ttya" means "root" can only login on ttya device. Any
other user via telnet/ssh/whatever has to login as themselves and "su" to
root.

This doesn't prevent telnet -l "-fbin", or -flp; for those accounts best
bet is to change /etc/passwd for the shell of system-account users to
/sbin/noshell or /bin/false (noshell just logs the entry and exists)

Of course disabling in.telnetd in /etc/inetd.conf (and doing a pkill -HUP
inetd) if possible is a safe bet,
but some sites are forced to use telnetd. 
--------

Background:

The original post on this, with the "exploit", can be found here:
http://www.com-winner.com/0day_was_the_case_that_they_gave_me.pdf

A bit of background:
http://blogs.securiteam.com/index.php/archives/814

And some on how corporations responded as we saw from our own client base:
http://blogs.securiteam.com/index.php/archives/819

Opinion:

Whatever my thoughts are on how silly, sad or funny this vulnerability is
(quaint really), how they use telnet (?!) and how Sun should be smacked on
the back of the head for it, I have to honestly admit Sun's response and
the level they were open to the community and industry on this without
too many PR/legal blocks getting in their way are very encouraging,
releasing information on the vulnerability, how it happened and why, a
quick beta patch and even discussing openly on mailing lists.
I am in awe. Now it is time for others to follow their example.

This one, despite its simplicity and age is going to be with us for a
while.

	Gadi Evron.

Powered by blists - more mailing lists