Summary: | Mosquitto Server Shutdown Attack | ||
---|---|---|---|
Product: | Community | Reporter: | Felipe Balabanian <f.balabanian> |
Component: | Vulnerability Reports | Assignee: | Security vulnerabilitied reported against Eclipse projects <vulnerability.reports-inbox> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | critical | ||
Priority: | P3 | CC: | jreimann, roger, wayne.beaton |
Version: | unspecified | Keywords: | security |
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
URL: | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7651 | ||
Whiteboard: |
Description
Felipe Balabanian
2018-01-12 11:55:03 EST
I thinks that qualifies for a CVEID. Any thoughts? @Roger: Can you confirm this? The first line of this attack is that any unauthenticated client can effectively ask the server to allocate the maximum mqtt packet size in memory as its first message, then do this multiple times with a slow transfer to cause OOM. This can be mitigated by a reasonable factor (at least for mqtt v3.1.1) by calculating the maximum size of a valid CONNECT packet and applying that as a limit. This is around 327,699 bytes vs. the maximum packet size of 268.435M - meaning a successful attack would now need 819 more clients than before, all other things being left the same. > Possible countermeasures: > > -Improve WITH_MEMORY_TRACKING configuration for set the max memory > in use by the server. > -Create a memory manager. All of these would require some form of administrator configuration to be effective. It would be possible to detect how much memory is available on the computer, but we have no way of knowing how much is available for mosquitto to use. If that's the case, then just running "ulimit -d <memory limit>" would do the same job with no code changes required. > -Use recv multiple times. recv is already used multiple times, the call as it is effectively just asks for all the data there is available - for a large payload it will usually take quite a lot of calls to get the full set of data, it would never happen in a single call. This is my assessment: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:F/RL:O/RC:C/CR:X/IR:X/AR:H/MAV:N/MAC:L/MPR:N/MUI:N/MS:U/MC:N/MI:N/MA:H I've implemented a code fix that limits the size of CONNECT packets which helps a lot. I suppose adding a configuration option to allow memory usage to be limited, plus a note to explain why it is necessary should be sufficient. The code changes mean that all systems are covered, but Linux/Mac can be protected using "ulimit -d", so a note to that effect should be added as well. Sounds reasonable to me! I would like to assign CVE-2017-7651 to this issue. Please don't use this CVE ID until it got assigned to this bug as alias. What is the next step with this? I'd like to do a release that combines this and #530102. Assigned: CVE-2017-7651 This was fixed in version 1.4.15. |