You are viewing this page in an unauthorized frame window.
This is a potential security issue, you are being redirected to
https://nvd.nist.gov
An official website of the United States government
Official websites use .gov
A .gov website belongs to an official government organization in the United States.
Secure .gov websites use HTTPS
A lock () or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.
Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. The WebSocket client in src/hackney_ws.erl imposes no upper bound on memory consumption in three code paths. First, read_handshake_response/3 accumulates received bytes into a growing buffer with no size cap; the per-receive timeout resets on every chunk, so a server that streams bytes without ever sending \r\n\r\n causes the buffer to grow until memory is exhausted. Second, parse_payload/9 and parse_active_payload/8 do not validate the declared frame payload length against any limit; because RFC 6455 allows payload lengths up to 2^63-1 bytes, a server that announces a very large frame and dribbles bytes causes the accumulation buffer to grow until OOM. Third, the frag_buffer field in #ws_data{} accumulates continuation frames indefinitely; a server that sends an endless stream of non-final (nofin) fragmented frames without ever sending a final (fin) frame grows frag_buffer without bound.
In all three cases the attacker only needs to control the WebSocket server the hackney client connects to, with no authentication or special client configuration required.
This issue affects hackney: from 2.0.0 before 4.0.1.
Metrics
NVD enrichment efforts reference publicly available information to associate
vector strings. CVSS information contributed by other sources is also
displayed.
By selecting these links, you will be leaving NIST webspace.
We have provided these links to other web sites because they
may have information that would be of interest to you. No
inferences should be drawn on account of other sites being
referenced, or not, from this page. There may be other web
sites that are more appropriate for your purpose. NIST does
not necessarily endorse the views expressed, or concur with
the facts presented on these sites. Further, NIST does not
endorse any commercial products that may be mentioned on
these sites. Please address comments about this page to [email protected].
Title: hackney de benoitc, Description: Vulnerabilidad de asignación de recursos sin límites ni limitación en benoitc hackney permite inundación. El cliente WebSocket en src/hackney_ws.erl no impone un límite superior al consumo de memoria en tres rutas de código. Primero, read_handshake_response/3 acumula los bytes recibidos en un búfer creciente sin límite de tamaño; el tiempo de espera por recepción se reinicia en cada fragmento, por lo que un servidor que transmite bytes sin enviar nunca \r\n\r\n hace que el búfer crezca hasta que la memoria se agote. Segundo, parse_payload/9 y parse_active_payload/8 no validan la longitud de la carga útil del marco declarada contra ningún límite; debido a que RFC 6455 permite longitudes de carga útil de hasta 2^63-1 bytes, un servidor que anuncia un marco muy grande y gotea bytes hace que el búfer de acumulación crezca hasta OOM. Tercero, el campo frag_buffer en #ws_data{} acumula marcos de continuación indefinidamente; un servidor que envía un flujo interminable de marcos fragmentados no finales (nofin) sin enviar nunca un marco final (fin) hace crecer frag_buffer sin límite.
En los tres casos, el atacante solo necesita controlar el servidor WebSocket al que se conecta el cliente hackney, sin autenticación ni configuración especial del cliente requerida.
Este problema afecta a hackney: desde 2.0.0 antes de 4.0.1.
Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. The WebSocket client in src/hackney_ws.erl imposes no upper bound on memory consumption in three code paths. First, read_handshake_response/3 accumulates received bytes into a growing buffer with no size cap; the per-receive timeout resets on every chunk, so a server that streams bytes without ever sending \r\n\r\n causes the buffer to grow until memory is exhausted. Second, parse_payload/9 and parse_active_payload/8 do not validate the declared frame payload length against any limit; because RFC 6455 allows payload lengths up to 2^63-1 bytes, a server that announces a very large frame and dribbles bytes causes the accumulation buffer to grow until OOM. Third, the frag_buffer field in #ws_data{} accumulates continuation frames indefinitely; a server that sends an endless stream of non-final (nofin) fragmented frames without ever sending a final (fin) frame grows frag_buffer without bound.
In all three cases the attacker only needs to control the WebSocket server the hackney client connects to, with no authentication or special client configuration required.
This issue affects hackney: from 2.0.0 before 4.0.1.
) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.
