🚨 [security] Update websocket-driver 0.7.7 → 0.8.2 (major)

[depfu]

---

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

---

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

↗️ websocket-driver (indirect, 0.7.7 → 0.8.2) · Repo · Changelog

Security Advisories 🚨

🚨 websocket-driver: Memory exhaustion via abuse of protocol length headers

Impact

The frame format in draft versions of the WebSocket protocol includes a length header that allows an arbitrarily large integer to be encoded as a sequence of bytes with the high bit set. By sending an indefinite sequence of bytes with values 0x80 or above, a server or client can make the other peer parse these bytes into an ever-growing integer. Since Ruby integers are arbitrary precision, this can be used to make a WebSocket connection consume an unbounded amount of memory and lead to the host process running out of memory.

Patches

The issue has been patched in version 0.8.1. All users should upgrade to this version.

Workarounds

No known workarounds exist.

Acknowledgements

This issue was discovered and reported by Pranjali Thakur, DepthFirst Security Research Team.

🚨 websocket-driver: Resource limit bypass via message compression

Impact

If this library is used in tandem with the permessage-deflate extension, a WebSocket server or client can be made to accept messages that are larger than the configured maximum message size. This is because this limit is checked against the message frames' length headers, which give the size of the compressed data, not the size after decompression. This can lead to applications accepting larger messages than expected and exceeding their intended resource usage.

Patches

The issue has been patched in version 0.8.1, by checking the length of messages after they are processed by incoming extensions. All users should upgrade to this version.

Workarounds

No known workarounds exist.

Acknowledgements

This issue was discovered and reported by Pranjali Thakur, DepthFirst Security Research Team.

🚨 websocket-driver: Memory exhaustion in HTTP header parser

Impact

If this library is used to implement a WebSocket server on top of a TCP server (rather than an HTTP server or framework) using the WebSocket::Driver.server() method, or, if it is used to complement a WebSocket client, then a peer can make a single connection consume an unbounded amount of memory by sending an HTTP request or response with a never-ending list of headers. This can lead to the receiving process running out of memory.

Patches

The issue has been patched in version 0.8.1, by limiting the total size of HTTP request/response lines and headers accepted by the parser to 32 kB. All users should upgrade to this version.

Workarounds

No known workarounds exist.

Acknowledgements

This issue was discovered and reported by Pranjali Thakur, DepthFirst Security Research Team.

Release Notes

0.8.2 (from changelog)

• Gracefully handle malformed Host headers in the Server driver

0.8.1 (from changelog)

• Close a draft-75/76 connection if a length header grows to exceed the configured max length
• Fail the connection if a message is larger than the configured max length after extension processing
• Limit the total HTTP request line and headers size to 32K

0.8.0 (from changelog)

• Emit binary message as a string with Encoding::BINARY instead of an array
• Add the option :binary_data_format to force the previous behaviour

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 19 commits:

• Bump version to 0.8.2
• Gracefully handle malformed `Host` headers in the `Server` driver
• Bump version to 0.8.1
• Limit the total HTTP request line and headers size to 32K
• Fail the connection if a message is larger than the configured max length after extension processing
• Close a draft-75/76 connection if a length header grows to exceed the configured max length
• Test on Ruby 4.0
• Update release date for 0.8.0
• Prefer text frames over binary; if the input is in some non-UTF-8 text encoding, then transcode it
• Bump version to 0.8.0
• Default to text frames if the input buffer is specifically UTF8-encoded
• Remove Ruby versions unsupported by GitHub
• Move the changelog_uri closer to other similar metadata
• Merge pull request #93 from mark-young-atg/provide_changelog_link_on_rubygems
• Update the documentation for representation of binary messages
• Emit binary frames as binary strings by default, and make Driver.frame() treat such strings as binary frames
• Merge pull request #95 from mackuba/binary_format
• added :binary_data_format option
• Provide a 'Changelog' link on rubygems.org/gems/websocker-driver

---

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

Recreates this PR, overwriting any edits that you've made to it

@​depfu merge

Merges this PR once your tests are passing and conflicts are resolved

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

Restores the branch and reopens this PR (if it's closed)

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

Ignores all future minor/major updates for this dependency and closes this PR

@​depfu resume

Future versions of this dependency will create PRs again (leaves this PR as is)