[Dshield] Solaris telnet vuln solutions digest and network risks

Jim Clausing clausing at ieee.org
Wed Feb 14 04:38:34 GMT 2007


Actually, the final patches are out now.  Take a look at the bulletin, it 
has been updated 
http://sunsolve.sun.com/search/document.do?assetkey=1-26-102802-1

To quote:

5. Resolution

This issue is addressed in the following releases:

SPARC Platform

    * Solaris 10 with patch 120068-02 or later

x86 Platform

    * Solaris 10 with patch 120069-02 or later



--
Jim Clausing
GCFA, GCIA, GCIH, GCFW, GSIP, GSOC, GREM, CISSP, CCSA
GPG fingerprint = EBD0 F967 3B1C 9EA6 79AD  8939 978A 079C 8BAB F921

On or about Tue, 13 Feb 2007, Gadi Evron pontificated thusly:

> 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.
> 
> _________________________________________
> 
> SANS 2007 March 29 - April 6 in San Diego, CA offers 52 Courses
> taught by our top rated instructors plus a huge vendor tools expo.
> Register Today! http://www.sans.org/info/2501 (BROCHURECODE: ISC)
> 


More information about the list mailing list