Community
Participate
Working Groups
The vertx-proton library used by the AMQP adapter fails to reject transfers exceeding the configured max-message-size. This allows an attacker to upload a message of unlimited size to the AMQP adapter using multiple transfers that each are within the configured max-framw-size limit. The vertx-proton library assembles the individual transfers into the final message in-memory. Thus the adapter is susceptible to its memory resources being exploited, eventually leading to an OOM exception.
Committers, FMPOV this is a very serious issue as it can easily be exploited by a client and can be used for a very simple DoS attack on the AMQP adapter. The underlying issue in vertx-proton [1] has been fixed in Vert.x 3.9.3. FMPOV we need to provide bugfix releases for all supported Hono versions and file a corresponding CVE. Kai [1] https://github.com/vert-x3/vertx-proton/issues/57
I've added the other PL, Dejan, in CC. There's some help regarding how we resolve vulnerabilities in the handbook. https://www.eclipse.org/projects/handbook/#vulnerability
Kai, Wayne, I agree we need to treat this as security vulnerability and follow the suggested procedure.
I agree on the suggested approach. Regarding the supported Hono versions: That would be down to Hono 1.0, right? Or which versions do we still consider supported? (Hono 1.0 still uses vert.x 3.7.1, so there are some more changes involved there, but still not too many, I guess.)
(In reply to Carsten Lohmann from comment #4) > I agree on the suggested approach. > Regarding the supported Hono versions: That would be down to Hono 1.0, right? > Or which versions do we still consider supported? That is a good question. To be honest, I do not think that we will be able to backport all bug fixes to all minor versions since 1.0.0. Maybe we can restrict ourselves to the three latest minor versions? > (Hono 1.0 still uses vert.x 3.7.1, so there are some more changes involved > there, but still not too many, I guess.)
(In reply to Kai Hudalla from comment #5) > That is a good question. To be honest, I do not think that we will be able > to backport all bug fixes to all minor versions since 1.0.0. Maybe we can > restrict ourselves to the three latest minor versions? Sounds appropriate to me.
Committers, this is the CVE report data that I would like to use for this vulnerability when we disclose it. The CWE codes for Software Development related vulnerabilities can be found at [1]. Let me know if you would like to see any changes. [1] https://cwe.mitre.org/data/definitions/699.html --- project: Eclipse Hono versions: 1.3.0, 1.4.0 CWE-1284: Improper Validation of Specified Quantity in Input summary: In Eclipse Hono version 1.3.0 and 1.4.0 the AMQP protocol adapter does not verify the size of AMQP messages received from devices. In particular, a device may send messages that are bigger than the max-message-size that the protocol adapter has indicated during link establishment. While the AMQP 1.0 protocol explicitly disallows a peer to send such messages, a hand crafted AMQP 1.0 client could exploit this behavior in order to send a message of unlimited size to the adapter, eventually causing the adapter to fail with an out of memory exception.
Wayne, what do we need to do in order to get a CVE number for this issue? Kai
> what do we need to do in order to get a CVE number for this issue? My apologies, the email got lost in my backlog. We need to remove the committer-only flag before I can push. Are you ready to do that? We'll use CVE-2020-27217
(In reply to Wayne Beaton from comment #9) > > what do we need to do in order to get a CVE number for this issue? > > My apologies, the email got lost in my backlog. > > We need to remove the committer-only flag before I can push. Are you ready > to do that? > > We'll use CVE-2020-27217 Hi Wayne, my understanding of the process is that we create our service releases and refer to the given CVE number in the release notes, right? Once the service releases are published/available, the (reserved) CVE entry will be replaced with the real one containing the problem description as we have defined above, correct? Kai
> my understanding of the process is that we create our service releases and > refer to the given CVE number in the release notes, right? Once the service > releases are published/available, the (reserved) CVE entry will be replaced > with the real one containing the problem description as we have defined > above, correct? The assigned CVE number is reserved for use by the Eclipse Foundation. The CVE number should not be used to publicly refer to the issue until after the vulnerability information is pushed to the central authority. I need to have complete information before I push. I can later update that information. Including the CVE as part of some release notes and then pushing the report is fine so long as we keep the time between the two short. The situation that we want to avoid is having folks go looking for the CVE (or making references to it from other CVEs) and the central authority not having the information.
(In reply to Wayne Beaton from comment #11) > > my understanding of the process is that we create our service releases and > > refer to the given CVE number in the release notes, right? Once the service > > releases are published/available, the (reserved) CVE entry will be replaced > > with the real one containing the problem description as we have defined > > above, correct? > > The assigned CVE number is reserved for use by the Eclipse Foundation. The > CVE number should not be used to publicly refer to the issue until after the > vulnerability information is pushed to the central authority. I need to have > complete information before I push. Do you need any additional information from me/us in order to do so? > I can later update that information. > > Including the CVE as part of some release notes and then pushing the report > is fine so long as we keep the time between the two short. The situation > that we want to avoid is having folks go looking for the CVE (or making > references to it from other CVEs) and the central authority not having the > information. Ok, then we'd rather create the service releases without referring to the CVE but instead refer to the service release versions where the vulnerability is fixed from the CVE, right?
@Wayne We have created the service releases which fix the vulnerability yesterday. Is there any additional information you need from us in order to publish the CVE record? Kai
My apologies for the delay. I've sent a pull request to the central authority's repository. https://github.com/CVEProject/cvelist/pull/110
