The versions listed in the original advisory were wrong.
Stunnel versions prior to 3.15 did not contain any smtp
client negotiation code, only server code which is not
vulnerable. The buggy smtp, pop, and nntp client code
wasn't added until version 3.15, not 3.3 as I originally
reported.
Versions prior to 3.15 are not vulnerable. The misdiagnosis
was caused by an abundance of migranes, illness, and vomitting
in my household which is luckily starting to abate.
Thanks to Andreas Hasenack <andreas@conectiva.com.br> for
noticing my error.
Below is an update of the original advisory. Only the version
numbers have changed.
-----------------------------------------------------------------
Update Date: 2-Jan-2002
Original Release Date: 22-Dec-2001
Package: stunnel
Versions: stunnel-3.15 => stunnel-3.21c
Problem type: format string bugs
Exploit script: none currently known
Severity: high
Network-accessible: yes
Discovery: Matthias Lange <ml@netuse.de>
Writeup: Brian Hatch <bri@stunnel.org>
Summary: Malicious servers could potentially run code as
the owner of the Stunnel process when using
Stunnel's protocol negotiation feature in client
mode.
Description:
Stunnel is an SSL wrapper able to act as an SSL client or server,
enabling non-SSL aware applications and servers to utilize SSL encryption.
In addition to the ability to perform as simple SSL encryption/decryption
engine, Stunnel can negotiate SSL with several other protocols, such as
SMTP's "STARTTLS" option, using the '-n protocolname' flag. Doing so
requires that Stunnel watch the initial protocol handshake before
beginning the SSL session.
There are format string bugs in each of the smtp, pop, and nntp
client negotiations as supplied with Stunnel versions 3.15 up to 3.21c.
No exploit is currently known, but the bugs are likely exploitable.
It's Christmas, I don't have time to fool around coding an exploit,
I need to wrap presents....
Impact:
If you use Stunnel with the '-n smtp', '-n pop', '-n nntp' options
in client mode ('-c'), a malicous server could abuse the format
string bug to run arbitrary code as the owner of the Stunnel
process. The user that runs Stunnel depends on how you start
Stunnel. It may or may not be root -- you will need to check
how you invoke Stunnel to be sure.
There is no vulnerability unless you are invoking Stunnel with
the '-n smtp', '-n pop', or '-n nntp' options in client mode.
There are no format string bugs in Stunnel when run as an SSL
server.
Mitigating factors:
If you start Stunnel as root but have it change userid to some other
user using the '-s username' option, the Stunnel process will be
running as 'username' instead of root when this bug is triggered.
If this is the case, the attacker can still trick your Stunnel process
into running code as 'username', but not as root.
When possible, we suggest running Stunnel as a non-root user
whenever possible, either using the '-s' option or starting it
as a non-privileged user.
Solution:
* Upgrade to Stunnel-3.22, which is not vulnerable to these bugs
or
* Apply the following patch to your version of Stunnel and recompile:
http://www.stunnel.org/patches/desc/formatbug_ml.html
For more information about Stunnel, consult the folowing pages:
http://stunnel.mirt.net/ # Official Stunnel home page
http://www.stunnel.org/ # Stunnel.org: FAQ/Distribution/Etc
Discovery:
These bugs were found by Matthias Lange <ml@netuse.de>
and reported to the Stunnel mailing list on 18 Dec 2001.
Here follows the original mail:
---------------------------------------------------------------------
To: stunnel-users@mirt.net
Date: Tue, 18 Dec 2001 15:26:25 +0100
From: Matthias Lange <ml@netuse.de>
Subject: stunnel client security patch
Hi,
I found a format string bug in stunnel.
In some occasions, fdprintf is used without a
format parameter. Fortunately, the errors are
only in the smtp and pop3 client implementations,
so "ordinary" servers are not affected.
I succeeded to crash stunnel with the following setup:
Acting as a mail server:
$ netcat -p 252525 -l
Acting as a mail client:
$ stunnel -c -n smtp -r localhost:252525
When the connection is established, I send a string like
"%s%s%s%s%s%s%s%s%s%s%s%s" from the netcat to the stunnel.
Then the stunnel performs: fdprintf(c->local_wfd,"%s%s%s%s..."),
prints out a lot of garbage, possibly with a segmentation fault.
I have attached a patch for stunnel-3.21c.
Greetings
Matthias Lange
--
Matthias Lange, BSc
NetUSE AG Dr.-Hell-StraBe Fon: +49 431 38643500
http://www.netuse.de/ D-24107 Kiel, Germany Fax: +49 431 38643599
---------------------------------------------------------------------
--
Brian Hatch Why is the
Systems and third hand on
Security Engineer a watch called
www.hackinglinuxexposed.com the second hand?
Every message PGP signed
Attachment:
pgp00063.pgp
Description: PGP signature
