Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1975623 (ALPACA, CVE-2021-3618) - CVE-2021-3618 ALPACA: Application Layer Protocol Confusion - Analyzing and Mitigating Cracks in TLS Authentication
Summary: CVE-2021-3618 ALPACA: Application Layer Protocol Confusion - Analyzing and Mi...
Keywords:
Status: NEW
Alias: ALPACA, CVE-2021-3618
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody
QA Contact:
URL:
Whiteboard:
Depends On: 1980043 1975646 1975647 1975648 1975650 1975651 1975652 1975653 1975744 1975745 1975746 1975747 1975749 1977146 1977147 1980042 2175896 2175929
Blocks: 1975822 1986789
TreeView+ depends on / blocked
 
Reported: 2021-06-24 05:18 UTC by Huzaifa S. Sidhpurwala
Modified: 2023-12-01 13:42 UTC (History)
44 users (show)

Fixed In Version: vsftpd 3.0.4, nginx 1.21.0, sendmail 8.17
Doc Type: If docs needed, set a value
Doc Text:
ALPACA is an application layer protocol content confusion attack, exploiting TLS servers implementing different protocols but using compatible certificates, such as multi-domain or wildcard certificates. A MiTM attacker having access to victim's traffic at the TCP/IP layer can redirect traffic from one subdomain to another, resulting in a valid TLS session. This breaks the authentication of TLS and cross-protocol attacks may be possible where the behavior of one protocol service may compromise the other at the application layer.
Clone Of:
Environment:
Last Closed:
Embargoed:
yozone: needinfo+


Attachments (Terms of Use)

Description Huzaifa S. Sidhpurwala 2021-06-24 05:18:10 UTC
As per the researchers:

ALPACA is an application layer protocol content confusion attack, exploiting TLS servers implementing different protocols but using compatible certificates, such as multi-domain or wildcard certificates. Attackers can redirect traffic from one subdomain to another, resulting in a valid TLS session. This breaks the authentication of TLS and cross-protocol attacks may be possible where the behavior of one protocol service may compromise the other at the application layer.

Comment 2 Huzaifa S. Sidhpurwala 2021-06-24 06:11:28 UTC
Analysis:

The generic attack requires a MitM attacker that can intercept and divert the victim's traffic at the TCP/IP layer.The attacker needs to have some way of intercepting and modifying the data sent from the victim’s browser to the web server. This is difficult on the Internet, but can be a plausible attacker model on the local network. The more dangerous variation of this attack requires the victim to use Microsoft Internet explorer and therefore Linux users are generally not vulnerable to them.

How the attack works: 

The ALPACA attack is only possible because TLS does not protect the source or destination IP and port address of the TCP connection. As is stated in the TLS RFC, TLS is application layer independent. However, this gap in protection gives the attacker the flexibility to redirect traffic from one server to another, making the cross-protocol attack possible.

Basic idea behind application layer cross-protocol attacks on HTTPS. A MitM attacker leads the victim to an attacker-controlled website that triggers a cross-origin HTTPS request with a specially crafted FTP payload.  The attacker then redirects the request to an FTP server that has a certificate compatible with the web server. The attack either (1) uploads a secret cookie to FTP, or (2) downloads a stored malicious JavaScript file from FTP, or (3) reflects malicious JavaScript contained in the request. In case (2) and (3), the JavaScript code is executed in the context of the targeted web service.

Conditions required for the attack to work:

1. As per mentioned above you need a MiTM atack who can divert victim's traffic at the TCP/IP layer and therefore the only plausible attack model is on the local network.

2. If you are hosting several TLS-enabled application servers on the same hostname, or if you use multi-domain certificates, or if you use wild-card certificates, you may be vulnerable to the general confusion attack.

Comment 3 Huzaifa S. Sidhpurwala 2021-06-24 06:57:55 UTC
Created vsftpd tracking bugs for this issue:

Affects: fedora-all [bug 1975648]

Comment 5 Huzaifa S. Sidhpurwala 2021-06-24 07:01:33 UTC
vsftpd:

This issue was fixed in v3.0.4 via the following changes:

- Close the control connection after 10 unknown commands pre-login.
- Reject any TLS ALPN advertisement that's not 'ftp'.
- Add ssl_sni_hostname option to require a match on incoming SNI hostname.

Comment 6 Huzaifa S. Sidhpurwala 2021-06-24 07:06:41 UTC
Created dovecot tracking bugs for this issue:

Affects: fedora-all [bug 1975652]


Created exim tracking bugs for this issue:

Affects: fedora-all [bug 1975653]


Created nginx tracking bugs for this issue:

Affects: fedora-all [bug 1975651]


Created sendmail tracking bugs for this issue:

Affects: fedora-all [bug 1975650]

Comment 7 Huzaifa S. Sidhpurwala 2021-06-24 07:50:26 UTC
nginx:

Fixed in v1.21.0 via the following commit: http://hg.nginx.org/nginx/rev/ec1071830799

Comment 12 Huzaifa S. Sidhpurwala 2021-06-24 14:56:39 UTC
Postfix:

As per the researcher: 
Postfix implements a detection for HTTP requests as well as HTTP headers.  As soon as a command contains an HTTP status line or a key-value pair separated by a colon, the server will immediately terminate the connection. Therefore it is resistant to this attack.

Comment 13 Huzaifa S. Sidhpurwala 2021-06-29 05:11:36 UTC
Sendmail:

"Sendmail only detects HTTP requests at the very start of a connection. If STARTTLS is used, the first command inside the connection can bensent by the attacker, bypassing the detection"
Sendmail fixed a bug to detect HTTP requests when STARTTLS is used in 8.16

As per the release notes:

	SECURITY: If sendmail tried to reuse an SMTP session which had
		already been closed by the server, then the connection
		cache could have invalid information about the session.
		One possible consequence was that STARTTLS was not
		used even if offered.  This problem has been fixed
		by clearing out all relevant status information
		when a closed session is encountered.

Comment 15 Huzaifa S. Sidhpurwala 2021-06-29 05:15:57 UTC
Dovecot:

POP3.All POP3 servers were tolerant towards HTTP request and header lines.Dovecot POP3 implements a counter that resets after valid commands.   However,  with only three  consecutive  errors allowed, and the restrictions of the POP3 protocol, it seems highly unlikely that an attacker can bypass the error limit by inserting attacker-controlled header lines to reset the counter.As for reflection,  Dovecot POP3 allows XSS reflection only post-authentication using an unknown command. For all other POP3 servers we could not find any reflection vectors.

Therefore dovecot is not affected.

Comment 19 Tapas Jena 2021-07-07 16:44:25 UTC
Analysis is complete for Ansible and it was found that Ansible is using the vulnerable version of nginx i.e. v1.16.1. Required trackers have been created.

Comment 37 Satish B 2023-11-03 00:09:28 UTC
Hello @huzaifas, if I do not use wildcard certificates or multi-domain certificates but certificates that are valid wrt CA but not valid wrt hostname verification, is this issue applicable?

Comment 38 Huzaifa S. Sidhpurwala 2023-11-14 07:49:28 UTC
(In reply to Satish B from comment #37)
> Hello @huzaifas, if I do not use wildcard certificates or multi-domain
> certificates but certificates that are valid wrt CA but not valid wrt
> hostname verification, is this issue applicable?

If you are a Red Hat customers, I would urge you to please contact Red Hat support.

Thank you


Note You need to log in before you can comment on or make changes to this bug.