How shoud we report security issues?

[Catminusminus]

I found some behaviors that seem vulnerabilities in uWebSockets.
However, there is no guide for reporting security issues here.
​
Where can I report the vulnerabilities?

[uNetworkingAB]

You can send me a mail

[Catminusminus]

@uNetworkingAB

Thank you for your response.
Which one is better for you, sending one report including all vulnerabilities or sending one report for each vulnerability?

[uNetworkingAB]

I have Gmail they will end up pretty much the same either way; a thread. So it makes no difference

[uNetworkingAB]

Alright I'm closing this as you have not responded or sent me anything.

I've found one class of issue namely the 11.2 part of RFC 9112 which is only an issue if you are using a proxy and you rely on the proxy being able to filter certain URLs. These are fixed in two steps:

1. More strict use of transfer-encoding and content-length
2. Making reading of content-length more strict in terms of overflows, same for chunk lengths in chunked encoding.

These are not really "vulnerabilities" when looking at uWS itself, they are more vulnerabilities in a deployment of a proxy and uWS with filter rules not implemented in uWS but in the proxy.

My opinion is that, doing such a set up is begging for issues since it requires all parts being entirely spec. compliant here and the smallest deviation will break the filtering mechanism. I would say if you care about your data, then apply filtering where you have you data or partition your network so that sensitive data is not even reachable from the front-end proxy at all.

I would file these issues more under "spec. compliance" and I will implement all changes needed to make it so.

Kind of like talking to a brick wall here but I guess, thanks for the input. It made me look deeper at this.

[Catminusminus]

@uNetworkingAB
Sorry for not getting back to you sooner.
I sent an email describing my findings..

[uNetworkingAB]

Thanks. Yeah like I wrote these are all 11.2 compliance issues:

We found three HTTP Request Smuggling (HRS) Vulnerabilities in
uWebSockets.

These aren't vulnerabilities in uWS itself, they apply to set-ups that have proxies that expect to be able to block requests based on url.

These http1.1 spec compliance issues will gradually be fixed as we become more spec compliant with RFC9112.

A recommendation is to not put all your eggs in one basket protected by an inherently fragile blocking mechanism that has been broken in pretty much every http server ever created. Instead use proper network partitions to separate interval traffic from external.

Honestly it boggles my mind how anyone could even think of relying on such a broken feature when you have sensitive data exposed under a separate http route - this way of thinking is new to me, I would never ever rely on two parsers from two different vendors to always parse a text format with 4534 different versions, the identical way.

Honestly, I still wouldn't trust such a feature even if servers claim to be "protected" from it since it just takes ANY differing behavior to completely break that feature.

I would instead just make it so that proxies aren't allowed to block certain URLs since doing so is such a fundamentally broken feature.

[uNetworkingAB]

I appreciate the detailed reports but the more I look at them the less important they seem:

All three issues are of the form "use uWS as the proxy that forwards to a backend server that does X instead of Y". uWS isn't even a proxy and has no such functionality.

One of the three reported issues is that we don't break when host header is missing, how on earth can that be a "vulnerability".

I'm thankful for the nice work made and I have easy fixes that will be made but this is really stretching the wordage "vulnerability" to its breaking point.

One issue is that we trim whitespace between header key and the colon, instead of rejecting the request. This simply is not a vulnerability. The header is reported to the app trimmed and there is no such functionality that allows forwarding the original untrimmed key, because again uWS is not a proxy and it has no such functionality.

The final issue is that we don't break when a header value contains LF or NULL. This is again an issue on the basis that if uWS was a proxy that forwarded the raw request then some shittily implemented downstream server could interpret that LF as CRLF....

Anyways, will apply these fixes but they are really nit picking spec compliance issues not vulnerabilities.