Loading ...
Sorry, an error occurred while loading the content.
 

Re: security vulnerability : SMTP daemon supports EHLO

Expand Messages
  • Rich Wales
    ... As Roger Klorese pointed out, there is an advertised, fuzzy vulnerability advisory out there regarding EHLO. However, as Noel Jones indicated, EHLO is a
    Message 1 of 18 , May 3, 2011
      > During a VA scan, it's reported that my postfix server has a security
      > vulnerability : EhloCheck: SMTP daemon supports EHLO

      As Roger Klorese pointed out, there is an advertised, fuzzy vulnerability
      advisory out there regarding EHLO. However, as Noel Jones indicated, EHLO
      is a standard part of SMTP and is required for some essential security
      features -- so, IMO, anyone who demands a total disabling of EHLO is being
      paranoid and/or uninformed.

      You might want to use "smtpd_discard_ehlo_keywords" to tell your server
      not to advertise certain EHLO keywords. For example, I am currently using
      "smtpd_discard_ehlo_keywords = etrn size silent-discard" in my main.cf,
      which tells my server not to advertise the ETRN capability or my maximum
      message length limit. I also have "fast_flush_domains =" in my main.cf,
      to make sure no mail is made available for ETRN processing even if some
      client decides to try using it despite my not advertising it. See the
      page "http://www.postfix.org/ETRN_README.html" for more info about ETRN.

      I can imagine that some hackers might use the SIZE info in an EHLO response
      as an invitation to try to crash a server by sending huge messages that are
      just under the advertised maximum length -- hence the idea of omitting this
      item from the EHLO response. I'd certainly be interested in hearing other
      thoughts about EHLO-related security concerns.

      Rich Wales
      Palo Alto, CA
      richw@...
    • Roger Goh
      Ok, ok, no offence intended. Can we mitigate it somewhat like what Roger Klorese suggested, eg: restrict the info EHLO reveals or don t reveal actual hostname
      Message 2 of 18 , May 3, 2011
        Ok, ok, no offence intended.
        Can we mitigate it somewhat like what Roger Klorese suggested,
        eg: restrict the info EHLO reveals or don't reveal actual hostname :

        smtp_helo_name ($myhostname)
        Use a fictitious hostname to send in the SMTP EHLO or HELO
        command (& how do I do this?)

        & from the url http://www.postfix.org/lmtp.8.html, can I insert something
        like the following in main.cf :

        smtp_never_send_ehlo (no)
        Never send EHLO at the start of an SMTP session.



        & from the url http://www.postfix.org/postconf.5.html
        $helo_name
        The hostname given in HELO or EHLO command or empty string

        (& where & what's the syntax to set the above suggestions?)



        Roger
        On Tue, May 3, 2011 at 11:56 PM, Roger B.A. Klorese <rogerk@...> wrote:
        >
        > On May 3, 2011, at 8:49 AM, Reindl Harald wrote:
        >
        > Am 03.05.2011 17:34, schrieb Roger Goh:
        >
        > Hi,
        >
        > During a VA scan, it's reported that my postfix server has
        >
        > a security vulnerability :
        >
        >   EhloCheck: SMTP daemon supports EHLO
        >
        > where exactly is the security hole?
        >
        > you should not trust the output of every tool blind without
        > try to understand what the output means
        >
        > EHLO is a part of ESMTP
        > ____________________
        >
        > http://en.wikipedia.org/wiki/ESMTP
        > Some relatively common keywords (not all of them corresponding to commands) used today are:
        >
        >    * 8BITMIME — 8 bit data transmission, RFC 6152
        >    * ATRN — Authenticated TURN for On-Demand Mail Relay, RFC 2645
        >    * SMTP-AUTH — Authenticated SMTP, RFC 4954
        >    * CHUNKING — Chunking, RFC 3030
        >    * DSN — Delivery status notification, RFC 3461 (See Variable envelope return path)
        >    * ETRN — Extended version of remote message queue starting command TURN, RFC 1985
        >    * HELP — Supply helpful information, RFC 821
        >    * PIPELINING — Command pipelining, RFC 2920
        >    * SIZE — Message size declaration, RFC 1870
        >    * STARTTLS — Transport layer security, RFC 3207 (2002)
        >    * UTF8SMTP — Allow UTF-8 encoding in mailbox names and header fields, RFC 5336
        >
        >
        >
        > Quoting http://www.iss.net/security_center/reference/vuln/smtp-ehlo.htm
        > Note that:
        > - the SMTP standard requires it
        > - it's rated as low-risk
        > - You can restrict the info it shows
        > SMTP daemon supports EHLO (EhloCheck)
        >
        > Vuln ID:323
        > Risk Level:  LowEhloCheck
        > Platforms:IBM AIX, WindRiver BSDOS, SGI IRIX, Linux Kernel, Sun Solaris, IETF SMTP, IBM OS2, Microsoft Windows 95, Data General DG/UX, Microsoft Windows NT: 4.0, Microsoft Windows 98, SCO SCO Unix, Microsoft Windows 98SE, Microsoft Windows 2000, Microsoft Windows Me, Compaq Tru64, Microsoft Windows XP, Apple Mac OS, Microsoft Windows 2003 Server, Microsoft Windows Vista
        > Description:
        >
        > SMTP daemons that support Extended HELO (EHLO) can release information that could be useful to an attacker in performing an attack. Attackers have been known to use the EHLO command to determine configuration information on SMTP daemons.
        >
        > Remedy:
        >
        > SMTP as defined in RFC 2821 (see References) requires EHLO. Some SMTP implementations allow you to disable EHLO, but this capability is neither required nor consistent across products.
        >
        > If you are uncomfortable with the information that the Extended SMTP features can reveal, you may choose to disable EHLO on your mail server (if applicable), or switch to a mail server that allows EHLO to be disabled. Consult your mail server documentation or contact your vendor for information on whether it is possible to modify your mail server configuration to disable EHLO.
      • Roger Goh
        & from the url Roger Klorese provided, http://www.iss.net/security_center/reference/vuln/smtp-ehlo.htm it says : SMTP daemons that support Extended HELO (EHLO)
        Message 3 of 18 , May 3, 2011
          & from the url Roger Klorese provided,
          http://www.iss.net/security_center/reference/vuln/smtp-ehlo.htm

          it says :
          SMTP daemons that support Extended HELO (EHLO) can release information
          that could be useful to an attacker in performing an attack. Attackers
          have been known to use the EHLO command to determine configuration
          information on SMTP daemons.


          So what other 'vulnerable' configuration information EHLO reveals &
          how they can disabled/mitigated/fabricated ?



          Roger
        • Wietse Venema
          ... EHLO is required by the SMTP standard (RFC 5321). Wietse
          Message 4 of 18 , May 3, 2011
            Roger Goh:
            > Hi,
            >
            > During a VA scan, it's reported that my postfix server has
            > a security vulnerability :
            >
            > EhloCheck: SMTP daemon supports EHLO

            EHLO is required by the SMTP standard (RFC 5321).

            Wietse
          • Rich Wales
            ... All the configuration items you mentioned are things that affect what your Postfix will or won t do as a client talking to other servers. These
            Message 5 of 18 , May 3, 2011
              > Can we mitigate it somewhat like what Roger Klorese suggested,
              > eg: restrict the info EHLO reveals or don't reveal actual hostname :

              All the configuration items you mentioned are things that affect what
              your Postfix will or won't do as a client talking to other servers.
              These configuration options won't affect how your Postfix behaves when
              it is acting as a server responding to other clients. Configuration
              parameters with names starting with "smtp_" affect your client; things
              that affect your server have parameter names starting with "smtpd_".

              You could make your SMTP server identify itself via a pseudonym by
              defining your own "smtpd_banner" value. However, aside from violating
              SMTP standards and risking delivery problems if some client panics at
              a server banner with an unexpected host name, this really doesn't make
              much sense because the client already knows who you are (or else it
              wouldn't have tried to connect to you!).

              As for "smtp_never_send_ehlo", this tells you (as a client) not to ever
              send an EHLO to a server. It doesn't affect what your Postfix server
              will do. As far as I know (I'm sure someone will correct me if I'm
              mistaken), there isn't any way to tell Postfix not to accept EHLO or
              other extended commands at all -- nor should there be, in most people's
              opinions.

              Rich Wales
              richw@...
            • Rich Wales
              ... You may want to suppress the SIZE information (maximum size of a message that your server will accept). Some hackers might take this as a challenge and
              Message 6 of 18 , May 3, 2011
                > So what other 'vulnerable' configuration information EHLO reveals
                > & how they can disabled/mitigated/fabricated ?

                You may want to suppress the SIZE information (maximum size of a
                message that your server will accept). Some hackers might take
                this as a challenge and try to exploit it in a denial-of-service
                attack to clog up your server with huge junk messages that are
                just under your advertised size limit. Unless you have a very
                small "message_size_limit" for some unusual reason, I don't see
                any real point in explicitly advertising it.

                And unless you are intentionally using the ETRN feature, you should
                omit the ETRN keyword from your EHLO response. I believe ETRN can
                be explicitly turned off by saying "fast_flush_domains =" (with no
                value after the equals sign) in your configuration. You can read
                http://www.postfix.org/ETRN_README.html for more info about ETRN.

                "smtpd_discard_ehlo_keywords = etrn size silent-discard" should
                suppress the above two items. The "silent-discard" option tells
                Postfix not to clutter up your log file with the fact that these
                EHLO keywords are being suppressed.

                I don't believe the other keywords I see in my server's EHLO
                response (PIPELINING, VRFY, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME,
                and DSN) are exploitable, but maybe someone else out there knows of
                something.

                As Wietse pointed out, a standards-compliant SMTP implementation is
                required to implement EHLO, and some of the extended features (such
                as STARTTLS) are simply not expendable. This fact may or may not
                influence a paranoid management type who is making demands based on
                a fuzzy advisory from a security tool or a vague warning in a trade
                rag, but I'm not at all surprised that Postfix does not appear to
                have any way to disable EHLO entirely.

                Rich Wales
                richw@...
              • Victor Duchovni
                ... No, this is silly, one is better off advertising the maximum size to avoid the vast majority unnecessary partial transmission of overly large messages. An
                Message 7 of 18 , May 3, 2011
                  On Tue, May 03, 2011 at 10:00:58AM -0700, Rich Wales wrote:

                  > > So what other 'vulnerable' configuration information EHLO reveals
                  > > & how they can disabled/mitigated/fabricated ?
                  >
                  > You may want to suppress the SIZE information (maximum size of a
                  > message that your server will accept). Some hackers might take
                  > this as a challenge and try to exploit it in a denial-of-service
                  > attack to clog up your server with huge junk messages that are
                  > just under your advertised size limit. Unless you have a very
                  > small "message_size_limit" for some unusual reason, I don't see
                  > any real point in explicitly advertising it.

                  No, this is silly, one is better off advertising the maximum size to
                  avoid the vast majority unnecessary partial transmission of overly large
                  messages. An attacker can tie up SMTP server resources whether the SIZE
                  limit is known or not.

                  The vulnerability scanning tool in question is worse than useless in
                  this regard, the right answer is to turn off that scan feature, or
                  ignore it.

                  Regardless, one should not enable SMTP features one does not want to
                  offer to outside parties. Potentially ETRN, DSN, ...

                  --
                  Viktor.
                • Murray S. Kucherawy
                  ... It s hard to give a general answer, but specifically, every SMTP extension listed by EHLO has an RFC that defines it, and those each have a Security
                  Message 8 of 18 , May 3, 2011
                    > -----Original Message-----
                    > From: owner-postfix-users@... [mailto:owner-postfix-users@...] On Behalf Of Rich Wales
                    > Sent: Tuesday, May 03, 2011 9:18 AM
                    > To: postfix users
                    > Subject: Re: security vulnerability : SMTP daemon supports EHLO
                    >
                    > I can imagine that some hackers might use the SIZE info in an EHLO response
                    > as an invitation to try to crash a server by sending huge messages that are
                    > just under the advertised maximum length -- hence the idea of omitting this
                    > item from the EHLO response. I'd certainly be interested in hearing other
                    > thoughts about EHLO-related security concerns.

                    It's hard to give a general answer, but specifically, every SMTP extension listed by EHLO has an RFC that defines it, and those each have a "Security Considerations" section. So if you want to be ultra-diligent, go read them all and then turn off the ones that scare you.
                  • Rich Wales
                    ... OK. ... A followup question. If I suppress the advertising of an extended feature by listing it in smtpd_discard_ehlo_keywords, does that also disable the
                    Message 9 of 18 , May 3, 2011
                      >> You may want to suppress the SIZE information . . . .
                      >
                      > No, this is silly, one is better off advertising the maximum size
                      > to avoid the vast majority unnecessary partial transmission of
                      > overly large messages. An attacker can tie up SMTP server resources
                      > whether the SIZE limit is known or not.

                      OK.

                      > Regardless, one should not enable SMTP features one does not want to
                      > offer to outside parties. Potentially ETRN, DSN, ...

                      A followup question. If I suppress the advertising of an extended
                      feature by listing it in smtpd_discard_ehlo_keywords, does that also
                      disable the feature? Or do I have to do other things to actually
                      turn a feature off and make it unavailable even if a client tries to
                      issue a command (such as ETRN) that was not advertised in my EHLO
                      response?

                      Rich Wales
                      richw@...
                    • Victor Duchovni
                      ... Postfix will generally disable the feature. The only exception I am aware of is that PIPELINING will remain enabled when the protocol is ESMTP, even if the
                      Message 10 of 18 , May 3, 2011
                        On Tue, May 03, 2011 at 11:15:57AM -0700, Rich Wales wrote:

                        > A followup question. If I suppress the advertising of an extended
                        > feature by listing it in smtpd_discard_ehlo_keywords, does that also
                        > disable the feature? Or do I have to do other things to actually
                        > turn a feature off and make it unavailable even if a client tries to
                        > issue a command (such as ETRN) that was not advertised in my EHLO
                        > response?

                        Postfix will generally disable the feature. The only exception I am aware
                        of is that PIPELINING will remain enabled when the protocol is ESMTP,
                        even if the keyword is disabled. This is harmless.

                        --
                        Viktor.
                      • Reindl Harald
                        ... surely - a well designed client does not try to send a 30 MB attachment if the server says not more than 20 MB , i do not want to wait a minute until i
                        Message 11 of 18 , May 3, 2011
                          Am 03.05.2011 19:00, schrieb Rich Wales:
                          >> So what other 'vulnerable' configuration information EHLO reveals
                          >> & how they can disabled/mitigated/fabricated ?
                          >
                          > You may want to suppress the SIZE information (maximum size of a
                          > message that your server will accept). Some hackers might take
                          > this as a challenge and try to exploit it in a denial-of-service
                          > attack to clog up your server with huge junk messages that are
                          > just under your advertised size limit. Unless you have a very
                          > small "message_size_limit" for some unusual reason, I don't see
                          > any real point in explicitly advertising it.

                          surely - a well designed client does not try to send a 30 MB attachment
                          if the server says "not more than 20 MB", i do not want to wait a minute
                          until i get "this was too much"
                        • Ralf Hildebrandt
                          ... That is NOT a vulnerability. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin
                          Message 12 of 18 , May 4, 2011
                            * Roger Goh <gproger@...>:
                            > Hi,
                            >
                            > During a VA scan, it's reported that my postfix server has
                            > a security vulnerability :
                            >
                            > EhloCheck: SMTP daemon supports EHLO

                            That is NOT a vulnerability.

                            --
                            Ralf Hildebrandt
                            Geschäftsbereich IT | Abteilung Netzwerk
                            Charité - Universitätsmedizin Berlin
                            Campus Benjamin Franklin
                            Hindenburgdamm 30 | D-12203 Berlin
                            Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
                            ralf.hildebrandt@... | http://www.charite.de
                          Your message has been successfully submitted and would be delivered to recipients shortly.