An update on the Solaris telnet vulnerability [LWN.net]

From:		Gadi Evron <ge-AT-linuxbox.org>
To:		bugtraq-AT-securityfocus.com, full-disclosure-AT-lists.grok.org.uk
Subject:		Solaris telnet vuln solutions digest and network risks
Date:		Tue, 13 Feb 2007 19:24:34 -0600 (CST)
Cc:		funsec-AT-linuxbox.org
Archive-link:		Article, Thread

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...

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/solar...

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_gav...

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

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_gav...

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.

(Log in to post comments)

An update on the Solaris telnet vulnerability

Posted Feb 14, 2007 22:58 UTC (Wed) by tpenta (guest, #43348) [Link]

Thank you for your kind words.

Just a few other notes.

As of Solaris 10 update 3 (11/06), telnet (indeed most network) services are installed turned off by default.

As the engineer who did the patch building and the blogging etc, I have to disagree about the CEO comment. Over the past few years Sun has not only been becoming more transparent from the outside, but also in the inside and lots of fences are coming down. We all want the company to succeed. No-one likes bad press. If this had happened prior to Scott's stepping down, but still relatively recently, I would have reacted exactly the same way and I think we would have responded just as quickly.

alan.

An update on the Solaris telnet vulnerability

Posted Feb 15, 2007 1:41 UTC (Thu) by smoogen (subscriber, #97) [Link]

I am glad that you would have. My view sadly comes from 17 years of experience of having seen anything "new and good" Sun invented quickly replaced by Scott's management team into something that lawyers loved and buyers were abused.

The list is long, and something that every Solaris evangelist needs to be aware of to understand why they get such pushback from old-timers these days. It basically goes like: Sun's engineers invent something or build something that is fun for people to play/work with. Then Sun's management tries to lock in buyers by making all kinds of propietary rules and gagging the engineers from helping any community (which in the 1990's were customers as they had bought the hardware and software from Sun). Then Sun saw its market share drop, changed its tactics, and then let some new invention out the door. But within a year, it seemed the lawyers and controllers were back on top and whatever new invention (SunView, Java, etc) was mired in licensing.

Since Scott "retired" though there has been a real change in attitude. It may have been there before he left.. but those of us who had been burnt over and over again may have thought it was just another "ploy" to get back customers that would be quickly rescinded.

An update on the Solaris telnet vulnerability

Posted Feb 18, 2007 16:05 UTC (Sun) by const-g (subscriber, #5006) [Link]

Everybody is talking about tenetd bug while the real problem is that (even!) undocumented (-f) backdoor in login program. Why put it in the first place (except for a goof backdoor)? And why use lousy and lossy getopt strings parsing (-fxx, -f xx , -f=xx are all the same). I never use getopt() in my programs. You cannot simply envision and filter out possible combinations. And what if a next shared library upgrade will introduce a new bug parsing in getopt?

I think for security reasons arguments parsing code must be made static to a program code and not depend on external config file that can modify parsing.

I do not trust getopt and use my approach to argument parsing where "-f xx", "-f=", and "-fxx" are all different. This results in much shorter code for argument parsing, too.

Dump use of getopt in secutiry sensitive apps and close -f hole in login. It is only a matter of time when another application proves to be vulnerable because of this. Good luck that sshd is configured to use pam by default. But it can be configured to use login, too.