If a resultset in binary protpcpl doesn't contain data
(fields equal zero) and there are no more pending
result sets we need to change the statement status to
FETCH_DONE, otherwise it will be impossible to execute
other commands until the statement was closed.
FROM_UNIXTIME() function always returns AUTO_SEC_PART_DIGITS
(value=39). In case the microsecond value was set in MYSQL_TIME,
the decimal part should be SEC_PART_DIGITS (=6).
Add fallback if CryptAcquireContext fails with ERROR_ACCESS_DENIED,
as seen in Jenkins CI.
The fallback, also suggested by https://stackoverflow.com/a/14053718/547065,
is to retry with machine-wide key container, if user-specific fails.
Follow-up patch to fix copy-paste error that causes incorrect restore of
registers in my_context_continue which can cause crashes on arm64.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
declare plugin structures using their correct type.
Fixes errors like
./libmariadb/libmariadb/ma_client_plugin.c:86:39: error: type of ‘pvio_socket_client_plugin’ does not match original declaration [-Werror=lto-type-mismatch]
./libmariadb/plugins/pvio/pvio_socket.c:141:21: note: type ‘struct MARIADB_PVIO_PLUGIN’ should match type ‘struct st_mysql_client_plugin’
Approved by: Georg Richter <georg@mariadb.com>
The non-blocking API has native (assembler) implementations for x86_64,
i386, and (with recent patch) aarch64; these implementations are the most
efficient. For other architectures, a fallback to ucontext is supported.
But ucontext is not the most efficient, and it is not available on all
platforms (it has been deprecated in POSIX). The boost::context library
provides an alternative fallback that is available on more architectures and
should be more efficient than ucontext (if still not quite as fast as the
native support).
This patch adds a CMake option -DWITH_BOOST_CONTEXT=ON that adds
boost::context as a dependency of libmariadb to provide a fallback on
non-natively supported architectures. Boost::context is preferred over
ucontext when both are available.
The option is off by default and must be explicitly enabled by the
user. This avoids introducing a C++ dependency (including dependency
on a C++ compiler and on libstdc++) unless explicitly requested by the
user (libmariadb is otherwise C-only).
Tested-by: Brad Smith <brad@comstyle.com>
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
Implement native my_context for arm64 (aarch64). This is more
efficient than ucontext, and also makes the non-blocking API available
on arm64 platforms that do not have ucontext such as OpenBSD.
Tested-by: Brad Smith <brad@comstyle.com>
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
Use SCH_CREDENTIAL structure, to support TLSv1.3
Allow TLSv1.3 starting with Windows 11 / Server 2022, which are
first Windows releases to officially support latest TLS version
There is no real renegotiation in TLSv1.3 protocol, so it is
some internal schannel thing, that makes DecryptMessage() to return
SEC_I_RENEGOTIATE, to replay a handshake step.
This pops up when TLSv1.3 is enabled.
The bug happens only when connecting with SSL with client certificates.
Apparently if client certificates are used in TLS handshake,
private keys for cert should be loaded into named persistent
container.This is because AcquireCredentialsHandle is done partically
out-of-process in lsass.exe, and lsass wants to read private keys from disk
See discussion in https://github.com/dotnet/runtime/issues/23749
Schannel has legacy behavior for ephemeral keys, not involving lsass,
and this is why it worked for us so far, however there are limitations.
It appears to only use rsa_sha1 for signature verification, and newer
OpenSSL no longer allows SHA1 for it, and this ends up in
"algorithm mismatch" message from schannel.
The above is just my understanding of how it works, because there is no
real documentation, the conclusion is based on discussion in
https://github.com/dotnet/runtime/issues/23749
The fix:
So storing the key in persistent named container evidently fixes it,
and this is what is done in this patch. Care is takes to destroy
key container after key is no longer needed, to
avoid filling %AppData%\Roaming\Microsoft\Crypto\RSA with tiny encrypted
key files. Thus the "persistency window" of the key in container on disk
is only for duration of AcquireCredentialsHandle
1) Fix check if end was reached (<= instead of <), so last parameter will
not be ignored in case it is an empty string.
2) Empty strings will be passed as NULL`in _mariadb_set_conf_option.
SSL_{read,write}'s return values == 0 signify the operation was
unsuccessful, but here it's being treated as success. Other calls of
these functions already properly checks the return value.
Signed-off-by: Josh Hunt <johunt@akamai.com>
This reverts 395641549ac7..536d9e2b9e5b, in particular:
8dffd56936 MDEV-31857 enable MYSQL_OPT_SSL_VERIFY_SERVER_CERT by default
a99570c118 MDEV-31855 SSL cert validation protocol extension
9aa15e72a7 TLS fingerprint
and related commits
These errors stem from generating self-signed certificates, and enabling
SSL + SSL certificate validation in clients.
This was done without considering Windows specifics, such as
- TCP connections by default
- non-password based plugin, auth_gssapi, in every installation
To provide some relief, consider local TCP connections to be secure
transport and skip self-signed errors for them at least.
because the default value of every option is 0
(option and option.extension are bzero-ed to reset),
tls_verify_server_cert was renamed to tls_allow_invalid_server_cert
with the default value of 0, "do not allow".
API didn't change, it's still MYSQL_OPT_SSL_VERIFY_SERVER_CERT
* extend the client auth plugin API with a new callback
* relax the plugin version check to allow load a plugin with the
same major version, even if the minor versions differ
* implement the protocol extension:
- don't abort at once if the certificate is self signed and
no CA was explicitly specified
- allow it if it passes fingerprint check
- allow it if plugin has hash_password_bin callback, password was
non-empty and the control hash matches server's
they cannot be sent by the server (ma_net_safe_read() guarantees that)
so they all should be safe and not forged
also, use existing macros to check for error ranges, they are
sufficiently parenthesized to avoid compiler warnings (errors with -Werror)
about "you might want to add parentheses here"
MariaDB Connector/C does not distinguish [application-layer error
packets](https://mariadb.com/kb/en/err_packet) that it receives prior to TLS
handshake completion from those that it receives immediately after.
(A trivially modified server built from
https://github.com/dlenski/mariadb-server/commit/demonstration_of_CONC-648_vulnerability
can easily be used to demonstrate this.)
Pre-TLS error packet received from this trivially modified server. This packet
should NOT be trusted to actually originate from the server:
$ mariadb --ssl --ssl-verify-server-cert -uUsername -pVerySecretPassword -h CONC-648.vuln.demo.server.com
ERROR 1815 (HY000): Internal error: Client will accept this error as genuine even if running with --ssl --ssl-verify-server-cert, and even though this error is sent in plaintext PRIOR TO TLS HANDSHAKE.
Post-(TLS handshake) error packet received from a normal MariaDB server upon
an attempt to connect with incorrect credentials. This error packet CAN be
trusted to actually originate from the server, assuming transitive trust in
the TLS protocol implementation and PKI-based certificate validation:
$ mariadb --ssl --ssl-verify-server-cert -uUsername -pWrongPassword -h $NORMAL_MARIADB10.6.14_SERVER
ERROR 1045 (28000): Access denied for user 'Username'@'A.B.C.D' (using password: YES)
This client behavior opens up MariaDB Connector/C clients to an extremely
straightforward [downgrade attack](https://en.wikipedia.org/wiki/Downgrade_attack).
An on-path or pervasive attacker can inject errors into MariaDB
client→server connections that are intended to be protected by TLS, and the
client has no clear mechanism to distinguish such errors from errors that
actually come from the server.
An attacker could easily use this to DOS a client, or even influence its
behavior. For example, consider a client application which is configured…
1. To use TLS with server certificate validation
(`--ssl --ssl-verify-server-cert`), and
2. To wait for a back-off period and then *retry* connection attempts if the server
responds with `ER_CON_COUNT_ERROR` ("Too many connections") from the
server, and
3. To give up and shut down if its connection attempts fail with
`ER_ACCESS_DENIED_ERROR` ("Access denied for user"), on the assumption
that this is due to an incorrect or expired password, and cannot be
resolved without human intervention.
An attacker could completely disable the retry mechanism of this application
by intercepting connection attempts and replying with
`ER_ACCESS_DENIED_ERROR` packets.
This patch modifies MariaDB Connector/C so that if the client is configured
to use TLS, error packets received prior to the completion of the TLS
handshake are untrusted, and are changed to a generic `CR_CONNECTION_ERROR`.
$ mariadb --ssl --ssl-verify-server-cert -uUsername -pVerySecretPassword -h CONC-648.vuln.demo.server.com
ERROR 2002 (HY000): Received error packet before completion of TLS handshake. The authenticity of the following error cannot be verified:
1815 - Internal error: Client will accept this error as genuine even if running with --ssl --ssl-verify-server-cert, and even though this error is sent in plaintext PRIOR TO TLS HANDSHAKE.
All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer Amazon Web
Services, Inc.
Per @vuvova in
https://github.com/mariadb-corporation/mariadb-connector-c/pull/223#issuecomment-1854720364:
> I don't think the client should accept client-side errors from the server
> at all.
If the server sends an error packet with error codes in the ranges
`CR_{MIN,MAX}_ERROR` (codes [2000, 2999]) or `CER_{MIN,MAX}_ERROR` (codes
[5000, 5999]), we will replace these with `CR_MALFORMED_PACKET`, rather than
propagating them to the client user.
Since there is no way in the ISO C standard to specify a
non-obsolescent function prototype indicating that a
function will be called with an arbitrary number (including
zero) of arguments of arbitrary types, we have to cast the
callback function in makecontext() call to avoid compiler
warnings/errors.
See also:
https://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html
schannel_certs.c - conflicting headers, include winsock2.h before windows.h,
strerror_r is now defined also with mingw
do not build mariadb_config on Windows, getopt.h is missing
