Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TLS security issue: tls.verify is not validating host subject alternative name #8072

Closed
JSchy65 opened this issue Oct 20, 2023 · 5 comments · Fixed by #8934
Closed

TLS security issue: tls.verify is not validating host subject alternative name #8072

JSchy65 opened this issue Oct 20, 2023 · 5 comments · Fixed by #8934

Comments

@JSchy65
Copy link

JSchy65 commented Oct 20, 2023

Bug Report

If tls.verify is set to on on the client side, the servers's subject alternative name (SAN) will still not be validated.

fluent-Bit Version 2.1.10
Ubuntu 22.04.2 LTS

Reproduction

The client establishs a connection with the host other.fluent-backoffice.de but get a certificate presented by the host with the SAN my.fluent-backoffice.de. It is obvious, that this names not match.

You find all necessary certificates and keys for reproduction in the zip file attached to this issue.

Excerpt from server's certificate data:

X509v3 Subject Alternative Name:
    DNS:my.fluent-backoffice.de

Fluent Bit configuration on client site:

[SERVICE]
    flush 1
    log_level debug

[INPUT]
    name  dummy
    dummy {"message": "custom dummy message"}

[OUTPUT]
    name   forward
    match  *
    host          other.fluent-backoffice.de
    port          24224
    tls           on
    tls.verify    on
    tls.debug     4
    tls.ca_file   /etc/fluent-bit/fluent-root.crt
    tls.crt_file  /etc/fluent-bit/fluent-client.crt
    tls.key_file  /etc/fluent-bit/fluent-client.key

/etc/hosts on client site:

92.168.55.11   other.fluent-backoffice.de

Fluent Bit configuration on server site:

[SERVICE]
    flush 1
    log_level debug

[INPUT]
    name   forward
    listen 0.0.0.0
    port   24224
    tls             on
    tls.verify      on
    tls.debug       4
    tls.ca_file     /etc/fluent-bit/fluent-root.crt
    tls.crt_file    /etc/fluent-bit/fluent-backoffice.crt
    tls.key_file    /etc/fluent-bit/fluent-backoffice.key

[OUTPUT]
    name stdout
    match *

Expected behaviour

If, like in that case, the host presents a certificat not matching the name of the host called by the client, the host name validation must fail and the TLS connection must not be established. Because of tls.debug is set to 4, in the client's site Fluent Bit log, there should be [debug] and/or [error] messages saying something like "host name validation failed".

Actual behaviour

The connection is established without any error. No error or debug message occurs in the client's or host's log. tls.debug 4 does not generate any tls [debug] message at all I think.

Countercheck

Checked with curl, if the expected behavour will occur:

curl https://other.fluent-backoffice.de:24224 --cacert /etc/fluent-bit/fluent-root.crt --cert /etc/fluent-bit/fluent-client.crt --key /etc/fluent-bit/fluent-client.key -v

You will get that messages:

* Server certificate:
*  subject: CN=fluent-backoffice
*  start date: Oct 19 15:47:01 2023 GMT
*  expire date: Dec  5 15:47:01 2033 GMT
*  subjectAltName does not match other.fluent-backoffice.de
* SSL: no alternative certificate subject name matches target host name 'other.fluent-backoffice.de'
* Closing connection 0

That means, that curl validates the host's certificate as expected. It detects, that the name in the hosts's certificate doesn't match the host called by the client. With curl, all is fine.

Now change the /etc/hosts to verify what happens, if the name in the host's certificate matches the name of the host called:

92.168.55.11   my.fluent-backoffice.de

Also in the client.config, change the host to:

host my.fluent-backoffice.de

After restarting Fluent-Bit, it works as expected. The tls connection is established and messages are successfully send from the client to the server.

curl also works as expected:

curl https://my.fluent-backoffice.de:24224 --cacert /etc/fluent-bit/fluent-root.crt --cert /etc/fluent-bit/fluent-client.crt --key /etc/fluent-bit/fluent-client.key -v

Now you will get the messages:

* Server certificate:
*  subject: CN=fluent-backoffice
*  start date: Oct 19 15:47:01 2023 GMT
*  expire date: Dec  5 15:47:01 2033 GMT
*  subjectAltName: host "my.fluent-backoffice.de" matched cert's "my.fluent-backoffice.de"
*  issuer: CN=fluent-root
*  SSL certificate verify ok

Unqualified guess about the cause

flb_ouput.c line 871:

else if (prop_key_check("tls.verify", k, len) == 0 && tmp) {
        ins->tls_verify = flb_utils_bool(tmp);
        flb_sds_destroy(tmp);
    }
    else if (prop_key_check("tls.debug", k, len) == 0 && tmp) {
        ins->tls_debug = atoi(tmp);
        flb_sds_destroy(tmp);
    }

tls.verify and tls.debug are the only two parameters in that code block, where a check against tmp is done. Is something wrong here ??

Please add the correct hostname validation to Fluent Bit.

necessary-certs.zip

Copy link
Contributor

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days. Maintainers can add the exempt-stale label.

@github-actions github-actions bot added the Stale label Jan 20, 2024
@JSchy65
Copy link
Author

JSchy65 commented Jan 24, 2024

Because there was no reaction on this issue since Oct. 20. and because in my oppinion it is critical, I placed it as a security vulnerability now:

https://github.com/fluent/fluent-bit/security/advisories/GHSA-rvxv-vp29-qf2h

@github-actions github-actions bot removed the Stale label Jan 26, 2024
Copy link
Contributor

github-actions bot commented May 1, 2024

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days. Maintainers can add the exempt-stale label.

@github-actions github-actions bot added the Stale label May 1, 2024
Copy link
Contributor

github-actions bot commented May 7, 2024

This issue was closed because it has been stalled for 5 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 7, 2024
@edsiper edsiper reopened this May 22, 2024
@edsiper
Copy link
Member

edsiper commented May 22, 2024

re-opening and assigning to @cosmo0920 for triagging

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants