Uploaded image for project: 'MariaDB Connector/C'
  1. MariaDB Connector/C
  2. CONC-654

Client improperly sends identifying information in plaintext prior to TLS handshake

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • None
    • None
    • None

    Description

      ... and, furthermore, the server requires that information to be sent in plaintext, and irreversibly updates its assessment of the client capabilities for this connection based on it (see MDEV-31585).

      Spinning this off from my comment on CONC-648. (Like CONC-648, this is another TLS-related vulnerability.)

      As I showed there, MariaDB clients including Connector/C send a great deal of identifying information about themselves in plaintext in the initial "login request" packet, even when they subsequently switch to TLS, and then resend a login request packet over the TLS channel:

      This information includes the client capability bits, the client's MAX_ALLOWED_PACKET size, and the client's charset.

      Copying from there:

      This makes MariaDB client-server connections an exploitable and target-rich environment for pervasive MITM attackers. A government agency could, for example, fingerprint the plaintext client+server greeting packets to determine the exact versions, pull out the ones that appear to be from interesting parts of the world based on the plaintext preferred client charset, and manipulate them in various ways with MITM and downgrade attacks using this vulnerability, as well as the long-known MDEV-28634... and all of that without needing to actually do any TLS cracking.

      For all I know, the NSA or CSIC or GCHQ or יחידה 8200 or the Chinese/Iranian/Indian/Russian/$COUNTRY equivalents have already figured this out themselves, and have been MITM'ing MariaDB connections on the Internet at massive scale for years.

      Attachments

        1. screenshot-1.png
          screenshot-1.png
          107 kB
        2. screenshot-2.png
          screenshot-2.png
          82 kB
        3. screenshot-3.png
          screenshot-3.png
          146 kB

        Issue Links

          Activity

            dlenski Daniel Lenski (Inactive) created issue -
            dlenski Daniel Lenski (Inactive) made changes -
            Field Original Value New Value
            dlenski Daniel Lenski (Inactive) made changes -
            dlenski Daniel Lenski (Inactive) made changes -
            Attachment screenshot-1.png [ 70781 ]
            dlenski Daniel Lenski (Inactive) made changes -
            Attachment screenshot-2.png [ 70782 ]
            dlenski Daniel Lenski (Inactive) made changes -
            Summary Client improperly sends identifying information in plaintext prior TLS handshake Client improperly sends identifying information in plaintext prior to TLS handshake
            dlenski Daniel Lenski (Inactive) made changes -
            Description ... and, furthermore, the server {color:red}trusts that information{color} and irreversibly updates its assessment of the client capabilities for this connection: (*todo MDEV-????*)

            Spinning this off from my [comment|https://jira.mariadb.org/browse/CONC-648?focusedCommentId=263365#comment-263365] on CONC-648. (Like CONC-648, this is another TLS-related vulnerability.)

            As I showed there, MariaDB clients including Connector/C, send a great deal of identifying information about themselves {color:red}in plaintext{color} in the initial "login request" packet, even if they subsequently switch to TLS:
            !https://jira.mariadb.org/secure/attachment/70760/screenshot-1.png!

            This information includes the client capability bits, the client's {{MAX_ALLOWED_PACKET}} size, and the client's *charset*.

            Copying from there:

            {quote}This makes MariaDB client-server connections an _extraordinarily_ exploitable and target-rich environment for pervasive MITM attackers. A government agency could, for example, fingerprint the plaintext client+server greeting packets to determine the exact versions, pull out the ones that appear to be from interesting parts of the world based on the plaintext [preferred client charset|https://mariadb.com/kb/en/supported-character-sets-and-collations], and manipulate them in various ways with MITM and downgrade attacks using this vulnerability, as well as the long-known MDEV-28634... and all of that without needing to actually do any TLS cracking.

            For all I know, the NSA or CSIC or GCHQ or יחידה 8200 or the Chinese/Iranian/Indian/Russian/$COUNTRY equivalents have already figured this out themselves, and have been MITM'ing MariaDB connections on the Internet at massive scale for years.{quote}
            ... and, furthermore, the server {color:red}requires that information to be sent in plaintext{color}, and irreversibly updates its assessment of the client capabilities for this connection based on it: todo MDEV-31585

            Spinning this off from my [comment|https://jira.mariadb.org/browse/CONC-648?focusedCommentId=263365#comment-263365] on CONC-648. (Like CONC-648, this is another TLS-related vulnerability.)

            As I showed there, MariaDB clients including Connector/C, send a great deal of identifying information about themselves {color:red}in plaintext{color} in the initial "login request" packet, even if they subsequently switch to TLS:
            !https://jira.mariadb.org/secure/attachment/70760/screenshot-1.png!

            This information includes the client capability bits, the client's {{MAX_ALLOWED_PACKET}} size, and the client's *charset*.

            Copying from there:

            {quote}This makes MariaDB client-server connections an _extraordinarily_ exploitable and target-rich environment for pervasive MITM attackers. A government agency could, for example, fingerprint the plaintext client+server greeting packets to determine the exact versions, pull out the ones that appear to be from interesting parts of the world based on the plaintext [preferred client charset|https://mariadb.com/kb/en/supported-character-sets-and-collations], and manipulate them in various ways with MITM and downgrade attacks using this vulnerability, as well as the long-known MDEV-28634... and all of that without needing to actually do any TLS cracking.

            For all I know, the NSA or CSIC or GCHQ or יחידה 8200 or the Chinese/Iranian/Indian/Russian/$COUNTRY equivalents have already figured this out themselves, and have been MITM'ing MariaDB connections on the Internet at massive scale for years.{quote}
            dlenski Daniel Lenski (Inactive) made changes -
            Description ... and, furthermore, the server {color:red}requires that information to be sent in plaintext{color}, and irreversibly updates its assessment of the client capabilities for this connection based on it: todo MDEV-31585

            Spinning this off from my [comment|https://jira.mariadb.org/browse/CONC-648?focusedCommentId=263365#comment-263365] on CONC-648. (Like CONC-648, this is another TLS-related vulnerability.)

            As I showed there, MariaDB clients including Connector/C, send a great deal of identifying information about themselves {color:red}in plaintext{color} in the initial "login request" packet, even if they subsequently switch to TLS:
            !https://jira.mariadb.org/secure/attachment/70760/screenshot-1.png!

            This information includes the client capability bits, the client's {{MAX_ALLOWED_PACKET}} size, and the client's *charset*.

            Copying from there:

            {quote}This makes MariaDB client-server connections an _extraordinarily_ exploitable and target-rich environment for pervasive MITM attackers. A government agency could, for example, fingerprint the plaintext client+server greeting packets to determine the exact versions, pull out the ones that appear to be from interesting parts of the world based on the plaintext [preferred client charset|https://mariadb.com/kb/en/supported-character-sets-and-collations], and manipulate them in various ways with MITM and downgrade attacks using this vulnerability, as well as the long-known MDEV-28634... and all of that without needing to actually do any TLS cracking.

            For all I know, the NSA or CSIC or GCHQ or יחידה 8200 or the Chinese/Iranian/Indian/Russian/$COUNTRY equivalents have already figured this out themselves, and have been MITM'ing MariaDB connections on the Internet at massive scale for years.{quote}
            ... and, furthermore, the server {color:red}requires that information to be sent in plaintext{color}, and irreversibly updates its assessment of the client capabilities for this connection based on it (see MDEV-31585).

            Spinning this off from my [comment|https://jira.mariadb.org/browse/CONC-648?focusedCommentId=263365#comment-263365] on CONC-648. (Like CONC-648, this is another TLS-related vulnerability.)

            As I showed there, MariaDB clients including Connector/C send a great deal of identifying information about themselves {color:red}in plaintext{color} in the initial "login request" packet, even when they subsequently switch to TLS, and then resend a login request packet over the TLS channel:
            !https://jira.mariadb.org/secure/attachment/70760/screenshot-1.png!

            This information includes the client capability bits, the client's {{MAX_ALLOWED_PACKET}} size, and the client's *charset*.

            Copying from there:

            {quote}This makes MariaDB client-server connections an _extraordinarily_ exploitable and target-rich environment for pervasive MITM attackers. A government agency could, for example, fingerprint the plaintext client+server greeting packets to determine the exact versions, pull out the ones that appear to be from interesting parts of the world based on the plaintext [preferred client charset|https://mariadb.com/kb/en/supported-character-sets-and-collations], and manipulate them in various ways with MITM and downgrade attacks using this vulnerability, as well as the long-known MDEV-28634... and all of that without needing to actually do any TLS cracking.

            For all I know, the NSA or CSIC or GCHQ or יחידה 8200 or the Chinese/Iranian/Indian/Russian/$COUNTRY equivalents have already figured this out themselves, and have been MITM'ing MariaDB connections on the Internet at massive scale for years.{quote}
            dlenski Daniel Lenski (Inactive) made changes -
            Description ... and, furthermore, the server {color:red}requires that information to be sent in plaintext{color}, and irreversibly updates its assessment of the client capabilities for this connection based on it (see MDEV-31585).

            Spinning this off from my [comment|https://jira.mariadb.org/browse/CONC-648?focusedCommentId=263365#comment-263365] on CONC-648. (Like CONC-648, this is another TLS-related vulnerability.)

            As I showed there, MariaDB clients including Connector/C send a great deal of identifying information about themselves {color:red}in plaintext{color} in the initial "login request" packet, even when they subsequently switch to TLS, and then resend a login request packet over the TLS channel:
            !https://jira.mariadb.org/secure/attachment/70760/screenshot-1.png!

            This information includes the client capability bits, the client's {{MAX_ALLOWED_PACKET}} size, and the client's *charset*.

            Copying from there:

            {quote}This makes MariaDB client-server connections an _extraordinarily_ exploitable and target-rich environment for pervasive MITM attackers. A government agency could, for example, fingerprint the plaintext client+server greeting packets to determine the exact versions, pull out the ones that appear to be from interesting parts of the world based on the plaintext [preferred client charset|https://mariadb.com/kb/en/supported-character-sets-and-collations], and manipulate them in various ways with MITM and downgrade attacks using this vulnerability, as well as the long-known MDEV-28634... and all of that without needing to actually do any TLS cracking.

            For all I know, the NSA or CSIC or GCHQ or יחידה 8200 or the Chinese/Iranian/Indian/Russian/$COUNTRY equivalents have already figured this out themselves, and have been MITM'ing MariaDB connections on the Internet at massive scale for years.{quote}
            ... and, furthermore, the server {color:red}requires that information to be sent in plaintext{color}, and irreversibly updates its assessment of the client capabilities for this connection based on it (see MDEV-31585).

            Spinning this off from my [comment|https://jira.mariadb.org/browse/CONC-648?focusedCommentId=263365#comment-263365] on CONC-648. (Like CONC-648, this is another TLS-related vulnerability.)

            As I showed there, MariaDB clients including Connector/C send a great deal of identifying information about themselves {color:red}in plaintext{color} in the initial "login request" packet, even when they subsequently switch to TLS, and then resend a login request packet over the TLS channel:
            !https://jira.mariadb.org/secure/attachment/70760/screenshot-1.png!

            This information includes the client capability bits, the client's {{MAX_ALLOWED_PACKET}} size, and the client's *charset*.

            Copying from there:

            {quote}This makes MariaDB client-server connections an exploitable and target-rich environment for pervasive MITM attackers. A government agency could, for example, fingerprint the plaintext client+server greeting packets to determine the exact versions, pull out the ones that appear to be from interesting parts of the world based on the plaintext [preferred client charset|https://mariadb.com/kb/en/supported-character-sets-and-collations], and manipulate them in various ways with MITM and downgrade attacks using this vulnerability, as well as the long-known MDEV-28634... and all of that without needing to actually do any TLS cracking.

            For all I know, the NSA or CSIC or GCHQ or יחידה 8200 or the Chinese/Iranian/Indian/Russian/$COUNTRY equivalents have already figured this out themselves, and have been MITM'ing MariaDB connections on the Internet at massive scale for years.{quote}
            dlenski Daniel Lenski (Inactive) made changes -
            dlenski Daniel Lenski (Inactive) made changes -
            dlenski Daniel Lenski (Inactive) made changes -
            Attachment screenshot-3.png [ 70844 ]
            dlenski Daniel Lenski (Inactive) made changes -

            People

              georg Georg Richter
              dlenski Daniel Lenski (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.