Open mnhauke opened 1 week ago
Such things is one of the reasons (or maybe a primary reason) why I rewritten it using modern dependencies.
It is impractical to close all those things - maybe porting the features to 4.0.0 branch would be simpler.
I hope that most of the things should not be (easily) reachable from Websocat. For example:
Lenient
hyper
header parsing ofContent-Length
could allow request smuggling
Websockets do not use Content-Length
field.
Integer overflow in
hyper
's parsing of theTransfer-Encoding
header leads to data loss
WebSockets do not use Transfer-Encoding
.
Potential segfault in the time crate
As far as I remember, it's about environment variables and setting timezone or something like that. Obviously Websocat does not use set_env
.
In general RUSTSEC
s rarely directly translate to exploitable vulnerabilities.
The most important security-related dependency - OpenSSL - should be up to date even with v1 branch.
Maybe try to package v4.0.0-alpha1
instead?
The only cargo audit
warning there is that "instant
is unmaintained" (RUSTSEC-2024-0384) (coming from a transitive dependency).
Note that a lot of Websocat1 features are missing at the moment (porting is tracked at #276). If Websocat is unpackaged at the moment it may be less of a problem, but automatic update from v1.13
to 4.0.0-alpha1
may be not a good idea.
The current version v1.14.0 fails that check
Is it the first time OpenSUSE packages Websocat (i.e. v1.14.0 is a starting version) or it is an update?
v1.14.0 is not significantly different from v1.13.0
, v1.12.0
and so in this regard - master
branch stuck with legacy deps for a long time.
Maybe cargo audit
requirement is a new one?
The only correctness change of v1.14
compared to v1.13
is prioritisation of pong replies over normal traffic. The rest are somewhat minor features, so sticking with 1.13 for some time should not be a large problem.
websocat is currently only available in the "network:utilities" add-on repository and not (yet) in of openSUSE's official distributions like Tumbleweed, Leap, ...
It's a package update but passing "cargo audit" is a new requirement for packages since some time (at least for those in the official distribution) thus the package builds are failing.
websocat v1.14
https://build.opensuse.org/package/show/home:mnhauke/websocat
with the following settings to workaround build errors
https://build.opensuse.org/projects/home:mnhauke/packages/websocat/files/_service?expand=1 ...
<param name="i-accept-the-risk">RUSTSEC-2021-0078</param>
<param name="i-accept-the-risk">RUSTSEC-2021-0079</param>
<param name="i-accept-the-risk">RUSTSEC-2021-0124</param>
websocat 4.0.0-alpha1
https://build.opensuse.org/package/show/home:mnhauke:test/websocat
... looks better in general and once it's considered "stable" definitely the version I sooner or later want to push towards the official openSUSE distributions.
i-accept-the-risk RUSTSEC-2021-0078 RUSTSEC-2021-0079 RUSTSEC-2021-0124
Shall I review those specific RUSTSECs how (and if) they affect Websocat1?
once it's considered "stable"
It may take a while. Next Websocat4 release would probably be "beta" or something like that.
i-accept-the-risk RUSTSEC-2021-0078 RUSTSEC-2021-0079 RUSTSEC-2021-0124
Shall I review those specific RUSTSECs how (and if) they affect Websocat1?
That would be nice.
once it's considered "stable"
It may take a while. Next Websocat4 release would probably be "beta" or something like that.
Thanks for letting me know.
Lenient Parsing of Content-Length Header When Prefixed with Plus Sign
GET / HTTP/1.1 Host: example.com Content-Length: +3 abc
To be vulnerable, hyper must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents but still forwards it. desync attack Request Smuggling
This looks like a minor, obscure thing. I'm not even sure that accepting more requests that RFC suggest is a real problem - buggy proxies (especially usage of them for security) may be the real problem instead.
Websocat accept HTTP requests in two ways:
rust-websocket
library, which depends on legacy hyper 0.10
. http-post-sse:
(exotic mode, may be mostly unused in practice). It does not use hyper
at all, instead uses a very simple HTTP header parser.There are no mentions of Content-Length
there. When accepting a Websocket connection - it accepts anything there (0
, 3
, +3
, -3
, qqq
) - it does not attempt to fully validate the request and only looks at essential fields. When accepting a body for http-post-sse:
mode, it does not attempt to follow any complicated HTTP standards - just parses enough of HTTP header to know whether it is POST
or GET
and to know when header ends and body begins (which is streams as is, without any interpretation).
Vulnerability score seems to be somewhat inflated for this. And Websocat (at least as of version 1) does not aim to cross the t-s and dot the i-s regarding to web standards anyway. Websocat4 may be a bit better in that regard, but mostly implicitly (by using more modern dependencies).
Integer Overflow in Chunked Transfer-Encoding
GET / HTTP/1.1 Host: example.com Transfer-Encoding: chunked f0000000000000003 abc 0
"request smuggling" or "desync attacks" CVSS Score: 9.1 CRITICAL
How can "desync" even get such high score if it relies on a bad proxy?
Websocat just does not support Transfer-Encoding
at all. Typically it just upgrades to a WebSocket (or expects an upgrade to a WebSocket) or serves a static file (it does not attempt to read request body in this case). http-post-sse:
would just inline all those body headers as a data (not interpreting it as headers or chunks or whatever).
tokio: Race leads to panic in
oneshot::Sender::send()
When these methods are called concurrently ...
Websocat1 uses futures::unsync
for channel needs.
Additionally async part of Websocat1 is mostly single-threaded, so concurrency issues should not affect it.
Hello, I am one of the [openSUSE websocat package]() maintainers.
The package build routines nowadays include a check via cargo audit to only allow updates without security vulnerabilities. The current version v1.14.0 fails that check because of the following discovered vulnerabilities: