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 <andreasconectiva.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 <mlnetuse.de>
Writeup: Brian Hatch <bristunnel.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 <mlnetuse.de>
  and reported to the Stunnel mailing list on 18 Dec 2001.
  Here follows the original mail:

---------------------------------------------------------------------
To: stunnel-usersmirt.net
Date: Tue, 18 Dec 2001 15:26:25 +0100
From: Matthias Lange <mlnetuse.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

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjwz/H0ACgkQbHrkO1vvTcqLIwCgzLmdUw0qwSqPBdh/WsY4ls0B 78wAnRURrOY04U69ZIjzhRPlPrwrsjnk =cCa1 -----END PGP SIGNATURE-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]