Created attachment 28649 [details]
a1.txt

Created attachment 28650 [details]
a2.txt

From: Solar Designer <solar@openwall.com>
To: vendor-sec@lst.de
Cc: vendor-disclosure <vendor-disclosure@idefense.com>
Subject: Re: [vendor-sec] iDEFENSE Security Advisory [IDEF0866] Multiple Telnet
Client slc_add_reply() Buffer Overflow
+Vulnerability
User-Agent: Mutt/1.4.2.1i
Errors-To: vendor-sec-admin@lst.de
Date: Sat, 19 Feb 2005 22:42:46 +0300

Hi,

I've just checked the source code for our (Openwall GNU/*/Linux)
telnet client for these three vulnerabilities.  Our telnet client
and server are derived from OpenBSD 3.0, and I notice no relevant
changes in current OpenBSD.

I have to admit that, yes, the slc_add_reply() and env_opt_add()
vulnerabilities are present in the code.  The environment disclosure
isn't - thanks to the Red Hat Linux derived patch which I've applied
right after porting this code from OpenBSD (3+ years ago).  I did
e-mail Theo about that at the time, but apparently the issue appeared
to be too minor to him so OpenBSD is still vulnerable now...

As it relates to fixing these bugs, obviously bounds checking needs to
be added to the respective functions, but also it is possible and
desirable to increase the size of slc_reply[] and OPT_REPLY_SIZE to be
twice SUBBUFSIZE.  While either of these approaches (bounds checking
or increased target buffer sizes) should be sufficient to prevent the
overflow problem, I'd rather use both.

The old Red Hat Linux patch can be obtained here:

http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/telnet/

(the relevant file is telnet-3.0-rh-env.diff), -- or in Red Hat's
.src.rpm indeed, against the NetKit telnet.

--
Alexander Peslyak <solar at openwall.com>

> we got the following via vendor-sec. (not public)

Well, this bug shouldn't be visible to beta-testers ;) 

yes ;) 

 SM-Tracker-447 

From: vendor-disclosure <vendor-disclosure@idefense.com> 
To: 'Thomas Biege' <thomas@suse.de> 
Cc: vendor-disclosure <vendor-disclosure@idefense.com> 
Subject: iDEFENSE Security Advisory [IDEF0866] Multiple Telnet Buffer Overflow 
Vulnerabilities 
Date: Tue, 22 Feb 2005 11:29:09 -0500 
thread-index: AcUYzewynLXO+XWfTMmH2243WbRlBgALO5RA 
 
[-- Anhang #1 --] 
[-- Typ: text/plain, Kodierung: 7bit, GröÃe: 1,1K --] 
 
PoC code for the following issues is attached: 
 
[IDEF0866] Multiple Telnet Client slc_add_reply() Buffer Overflow 
Vulnerability 
 
[IDEF0865] Multiple Vendor Telnet Client Information Disclosure 
Vulnerability 
 
[IDEF 0867] Multiple Telnet Client env_opt_add() Buffer Overflow 
Vulnerability 
 

Created attachment 28708 [details]
envopt_telnet.py

Created attachment 28709 [details]
envsend_telnet.py

Created attachment 28710 [details]
slc_telnet.py

Thomas, are you going to cook up a patch for the bufferoverflows? It'll be a
while before I can get around to it.

At the moment I've no time. 
Maybe other folks from vendor-sec or Sebastian are/is able to do it earlier. 

Will have a look. I remember we moved the telnet program around in our packages :(
And switched from this vendor to another etc.

Created attachment 28741 [details]
SLC and env overflow fix

This fix also includes the former temp-increase fix.
I did not got the env overflow-exploit to work, but it should
be fixed from my understanding. This is for telnet-bsd-1.0.
The env leak "bug" cant easily be fixed, it is a protocol issue.
But the overflows are fixed now. Please apply and test.

Created attachment 28742 [details]
SLC and ENV overflow fix

Couldnt get to work the env overflow here either,
but fixed the same way as in 1.0. Again, the info-leak
cant be fixed.

Created attachment 28745 [details]
Me stupid. There was off-by-one still in the last fix. Use this one, it does exactly the same just without off by one.

SLC + ENV overflow fix.

Created attachment 28746 [details]
Same for telnet-1.1

SLC+ENV overflow fix. Without off-by-one.

Patch may still cause problems (see comments on vendor-sec). 
mmj, you should wait till Sebastian finalized it. :) 

So these two patches for SLES{8,9} and SuLi 8.2, 9.{0,1,2} and that's it?

Created attachment 28756 [details]
SLC+ENV overflow fix

The same as last time, but I forgot that there could
be escaping characters. Please use this one.
SLC+ENV overflow is fixed.

Created attachment 28757 [details]
SLC+ENV overflow fix for telnet-bsd-1.1

Same as last time, but I forgot that there could be
escaping characters. Please use this one.
SLC+ENV overflow fix.

Ok. It looks like this patch has been blessed by vendor-sec.
Please go ahead.

Ok, I've submitted packages for sles8, 8.2, 9.0, 9.1 and 9.2. You can submit
patchinfos now.

So, there will be no fix for the information leak, right? 

A switch to disable the option may be nice... but it's not worth the gain I 
think. 

/work/src/done/PATCHINFO/telnet.patch.* 

Date: Wed, 2 Mar 2005 15:20:06 -0500 
From: vendor-disclosure <vendor-disclosure@idefense.com>                                                                 
Cc: vendor-sec@lst.de 
Subject: RE: [vendor-sec] iDEFENSE Security Advisories - [IDEF0865], [IDEF0866] 
& [IDEF0867] Multiple telnet client vulnerabilities 
 
Jacques/Aaron, 
 
Would you be comfortable with the following timeline: 
 
March 28, 2005 
[IDEF0866] Multiple Telnet Client slc_add_reply() Buffer Overflow 
[IDEF0867] Multiple Telnet Client env_opt_add() Buffer Overflow 
 
April 25, 2005 
[IDEF0865] Multiple Vendor Telnet Client Information Disclosure 
 
Please suggest an alternate timeline if this doesn't work you. 
 
Michael 

Created attachment 32267 [details]
patch made by redhat

Created attachment 32268 [details]
patch made by solar designer

From: Solar Designer <solar@openwall.com>     
To: bugtraq@securityfocus.com 
 
FWIW, I've been using the following one-liner to trigger this overflow: 
 
perl -e 'print "\377", "\372\42\3\377\377\3\3" x 43, "\377\360"' | nc -l 23 
 
This results in 300 bytes written into the 128-byte buffer.  On Owl 
(telnet client derived from OpenBSD 3.0), the effect was that the 
escape character ('^]') stopped working.  Other than that, the client 
proceeded to work as usual.  Indeed, with the patch this effect is gone. 
 
I've also tested this against some Red Hat Linux telnet packages   
(Linux NetKit) installed on top of Owl, with the same effect. 
 
Gael Delalleau's more elaborate "exploit" (that's been available to 
affected vendors via iDEFENSE) has the same effect on our telnet 
client, but actually crashes Red Hat's telnet client builds that I've 
tested. 
 

From: "vendor-disclosure" <vendor-disclosure@idefense.com> 
 
                      All,                                                                             
                                                                                 
No major objections were raised regarding a change in the disclosure date        
for this vulnerability. Therefore, [IDEF0865] will be revised as follows:        
                                                                                 
[IDEF0865] Multiple Vendor Telnet Client Information Disclosure                  
- Public disclosure on June 14, 2005 @ 1pm EST                                   
                                                                                 
As always, I would ask that all vendors refrain from disclosing details          
related to this vulnerability in order to not adversely impact the               
remediation efforts of other vendors.                                            
                                                                                 
Regards,                                                                         
Michael Sutton                                                                   

As far as I can see at least Solar's patch includes the patch for the 
information leak (IDEF0865). Sebastian's patch-set does NOT include this fix. 
And mmj used Sebastian's patches. Therefore no reason to delay or modify our 
update as it is for now. 
Correct me if I was wrong. 

A buffer overflow was discovered in the telnet client's handling of 
the LINEMODE suboptions. By sending a specially constructed reply 
containing a large number of SLC (Set Local Character) commands, a 
remote attacker (i. e. a malicious telnet server) could execute 
arbitrary commands with the privileges of the user running the telnet 
client. (CAN-2005-0469) 
 
Michal Zalewski discovered a Denial of Service vulnerability in the 
telnet server (telnetd). A remote attacker could cause the telnetd 
process to free an invalid pointer, which caused the server process to 
crash, leading to a denial of service (inetd will disable the service 
if telnetd crashed repeatedly), or possibly the execution of arbitrary 
code with the privileges of the telnetd process (by default, 
the 'telnetd' user). Please note that the telnet server is not 
officially supported by Ubuntu, it is in the "universe" 
component. (CAN-2004-0911) 
 

CAN-2005-0468  
 
The vulnerability specifically exists in the env_opt_add() function of 
telnet.c. A buffer of a fixed size (256 bytes) is allocated to store the 
result of the processing this function performs on network input. If   
this buffer is not large enough to contain the string, the buffer is  
expanded by a further 256 bytes. This size is sufficient for most well 
formed input, as the buffer passed as input to the affected function is 
limited to the same size. However, due to the way the telnet protocol 
escapes certain characters, it is possible to increase the length of the 
output by including a large run of characters which need escaping. This 
can allow the 256 byte input buffer to expand to a maximum of 512 bytes  
in the allocated storage buffer. If, after expanding the buffer by 256  
bytes, the buffer is still not large enough to contain the input, a heap 
based buffer overflow occurs, which is exploitable on at least some 
affected platforms. 
 

please disregard comment about CAN-2004-0911, it is unrelated. 

the buffer overflow fixes have been approved now. 
 
(i had to remove the info disclosure from the patchinfo files and docu) 

we need an update for 9.3 as well 

done. Stupid me now getting it included in the release :-(

Patchinfo? 

Added Vladimir because heimdal's telnet seem to be buggy too. 

heimdal hgas a seperate bug open already., 9.3 telnet is released. 

3rd issue actually still open... bummer. :) 

reassigned to maintainer

will be released in 3 weeks

The updated packages have already been checked in since a loong time

Subject: [vendor-sec] iDEFENSE Security Advisory [IDEF0865] CERT VU# Issued
Errors-To: vendor-sec-admin@lst.de
Date: Wed, 25 May 2005 15:22:48 -0400


[IDEF0865]
Multiple Vendor Telnet Client Information Disclosure Vulnerability

All,

CERT has issued VU#800829 for this vulnerability. iDEFENSE will continue to
handle coordination of the vulnerability.

Again, please remember that the advisory is scheduled for public release on
June 14 at 1pm EST. Please submit vendor specific details no later than
Friday June 10 at 5pm EST, including the following:

1.) URLs for appropriate patches
2.) URLs for any vendor advisories
3.) A narrative vendor statement [optional]

Regards,

Michael Sutton
Director, iDEFENSE Labs


_______________________________________________
Vendor Security mailing list
Vendor Security@lst.de
https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec

Hm, thought the patch for [IDEF0865] was in the already released update. But I
was wrong.

I'll attach an patch for the information leak ASAP.

Date: Tue, 31 May 2005 00:27:16 +0400
From: Solar Designer <solar@openwall.com>
To: Thomas Biege <thomas@suse.de>
Cc: vendor-sec@lst.de
Subject: Re: [vendor-sec] iDEFENSE Security Advisory [IDEF0865] Vendor
Statements Required
User-Agent: Mutt/1.4.2.1i

On Mon, May 30, 2005 at 06:43:03PM +0200, Thomas Biege wrote:
> On Thu, May 19, 2005 at 12:02:42PM -0400, vendor-disclosure wrote:
> > I'd like to remind everyone that the following iDEFENSE security
> > advisory is scheduled for public release on June 14 at 1pm EST:
> >
> > [IDEF0865] Multiple Vendor Telnet Client Information Disclosure
> > Vulnerability
>
> Do we have an official patch for this issue?

I don't think there can be an official BSD telnet patch these days;
there can only be "official" patches for particular clones of it.

Having that said, here's ours:

http://cvsweb.openwall.com/cgi/cvsweb.cgi/~checkout~/Owl/packages/telnet/telnet-3.0-owl-env-export.diff?rev=HEAD;content-type=text%
+2Fplain

This is against OpenBSD 3.0 code, but should apply against Linux
NetKit as well.

I suggest that you consider our other telnet/telnetd patches, too:

http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/telnet/

FWIW, the vendor statement I've submitted to iDEFENSE and CERT on this
issue is as follows:

Openwall GNU/*/Linux is not vulnerable to the telnet environment
variable disclosure, and it never was due to our inclusion of the
Red Hat Linux derived patch in the very first publicly available
version of our telnet package (which was in other aspects based off
the code found in OpenBSD 3.0).  It is, however, worth noting that the
unsafe environment variable disclosure was in fact documented in the
BSD telnet client manual page.  Thus, now that this issue has been
revisited, we have reworked the environment variable restrictions
patch to have our documentation in sync with the actual behavior.

(Thus, the telnet-3.0-owl-env-export.diff is no longer based on Red
Hat's patch.)

--
/sd

I've submitted packages for SLES8, 8.2, 9.0, 9.1, 9.2, 9.3. Could someone
please write patchinfos.

SM-Tracker-1438

/work/src/done/PATCHINFO/telnet.patch.maintained
/work/src/done/PATCHINFO/telnet.patch.box

While testing the maintenance update I've tried to verify 
[IDEF0865] Multiple Vendor Telnet Client Information Disclosure
on SLES9 and I think it is still vulnerable :

gemini:~ # /suse/rd-qa/testfiles/envsend_telnet.py
Launching telnet server on 127.0.0.1... Connect with a telnet client please.
Telnet server connected by ('127.0.0.1', 1093)
We asked for $PATH and $USER, we received:
ÿú'PATHDISPLAYlocalhost:11.0USERDISPLAYlocalhost:11.0ÿð
Traceback (most recent call last):
  File "/suse/rd-qa/testfiles/envsend_telnet.py", line 103, in ?
    main()
  File "/suse/rd-qa/testfiles/envsend_telnet.py", line 92, in main
    data = conn.recv(2048)
KeyboardInterrupt

gemini:~ # telnet 127.0.0.1
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.
gemini:~ #

gemini:~ # rpm -q --changelog telnet | head
* Tue May 31 2005 - mmj@suse.de

- Add additional patch for ENV overflow [#66128]

* Thu Feb 24 2005 - mmj@suse.de

- Fix SLC+ENV overflow [#66128]

Hm,
what does "envorin list" show?

thomas@spiral:~/tmp/openssl> telnet
telnet> environ list
  _                    /usr/bin/telnet
  COLORTERM
[...]

telnet.1:

                list        List the current set of environment variables.
                            Those marked with a * will be sent automatically,
                            those marked with a + will only be sent if explic­
                            itly requested by the server, and others won't be
                            revealed to the server even if requested.

The only variables on the client side with * or + are

* DISPLAY              localhost:11.0
+ TERM                 xterm

The full list is attached.

Created attachment 39119 [details]
output of "environ list" on the client side

is public now  

The testcase look ok I think.

that is how it looks with an unpatched telnet client:

spiral:/home/thomas # ./envsend_telnet.py
Launching telnet server on 127.0.0.1... Connect with a telnet client please.
Telnet server connected by ('127.0.0.1', 35750)
We asked for $PATH and $USER, we received:
ÿú'PATH/home/thomas/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/binDISPLAYspiral.ashpool.org:0USERthomasDISPLAYspiral.ashpool.org:0ÿð


and this with a patched one:
spiral:/home/thomas # ./envsend_telnet.py
Launching telnet server on 127.0.0.1... Connect with a telnet client please.
Telnet server connected by ('127.0.0.1', 43726)
We asked for $PATH and $USER, we received:
ÿú'PATHDISPLAYspiral.ashpool.org:0USERDISPLAYspiral.ashpool.org:0ÿð


So, the patch is effective b/c it doesn't sent the value assigned to the PATH
and USER variable to the malicious server.

i think this is ready for QA approval then? 

Yes. QA approved.

packages released

CVE-2005-0488

Certain BSD-based Telnet clients, including those used on Solaris and SuSE Linux, allow remote malicious Telnet servers to read sensitive environment variables via the NEW-ENVIRON option with a SEND ENV_USERVAR command.

CVE-2005-0488: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:P/I:N/A:N)