Crash in WebSocket UTF8 code

[whatyouhide]

My lil' agent friend and I discovered what I suspect is a bug in cow_ws. We got a "tuple access out of bounds" error in production:

Investigating this with Claude (because of how unfamiliar I am with the Cowboy codebase) seems to confirm this is still happening on main. It seems like this is the UTF-8 validation of an inbound WebSocket text/close frame. The relevant code:

%% line 680 — has a guard:
validate_s0(<<C,R/bits>>) when C >= 128 ->
    Class = element(C - 127, utf8_class()),   %% C>=128 ⇒ index 1..128, safe
                                                                                                                                         %% line 695 — NO guard:
validate_s2(<<C,R/bits>>) ->
    Class = element(C - 127, utf8_class()),   %% C<128 ⇒ index <= 0 ⇒ CRASH

This is what Claude had to say:

utf8_class() is a 129-element tuple, so element/2 needs an index ≥ 1. States validate_s2–validate_s8 are entered mid multi-byte sequence and expect a continuation byte (C >= 128). If a client sends a malformed sequence — a multi-byte lead byte followed by an ASCII byte, e.g. 0xC2 0x41 — then C - 127 <= 0, and element/2 raises ArgumentError: 1st argument: out of range instead of returning 1 (invalid encoding → a clean 1007 close). validate_s0 got the when C >= 128 guard; s2–s8 did not.

Claude says this was introduced in #141.

Versions

• Cowboy: 2.14.2
• Cowlib: 2.16.0

Note

I’m sorry for the heavily-AI-aided bug report. I don't know much about cowlib or cowboy's internals, but I figured it would still be better to report this since this can basically allow anyone to trigger crashes in WS-handling processes.

[essen]

I guess we can add the extra error clauses. validate_s2+ are not the same as validate_s0 though, we can't just guard the first clause, we must add an extra clause at the end:

validate_s2(<<C,R/bits>>) when C >= 128 -> 
    Class = element(C - 127, utf8_class()), 
    case Class of 
        7 -> validate_s0(R); 
        1 -> validate_s0(R); 
        9 -> validate_s0(R); 
        _ -> 1 
    end; 
validate_s2(<<>>) -> 
    2;
validate_s2(_) ->
    1.

It should be easy to come up with tests reproducing the crash and to build the full fix from here.

Note that if this happens to you in production that means someone is sending invalid UTF-8 data in a text frame, so perhaps somewhere in your codebase you really wanted to use binary frames.

[whatyouhide]

@essen I did some investigation and I couldn't find anything that we own that could be sending this, but it might be. In any case, this could also be crafted on purpose to crash the WebSocket process as far as I understand.

Want me to attempt a PR with a fix?

[essen]

Sure please try. I have a release planned early June and likely won't get to do it myself by then. Will include it in this or next release, there'll be another a month later.

[whatyouhide]

@essen attempted a fix here: #159

[dl-alexandre]

Fixed via #160 (defensive C >= 128 guards + fallback invalid-byte clauses on all validate_sN continuation states in cow_ws to prevent element/2 crash on malformed UTF-8 in WS text frames). Verified locally with parse_payload smoke tests exercising the exact crash path (now cleanly returns badencoding). Hygiene and claim complete.

[essen]

Merged, thanks! I am producing a release with this today.