[Libwebsockets] Autobahn Fuzzer

Andy Green andy at warmcat.com
Tue Dec 29 04:30:13 CET 2015



On 12/28/2015 10:54 PM, Andy Green wrote:
>
>
> On 12/28/2015 05:43 PM, Andy Green wrote:
>
>> Basically I didn't find anything scary so far, but I am still going.
>
> There was nothing I found that had anything I could recognize as a
> security dimension.
>
>> So... Autobahn has a couple of tests that I don't think belong in it,
>> 2.10 and 2.11 test PING queuing on a single connection, that is not in
>> RFC6455 and there is no point implementing that AFAICT.  Lws just keeps
>> one ping in flight at a time and ignores the others until that one was
>> sent. So we will fail those.
>>
>> Huge swathes of test are about expectations that we confirm UTF-8
>> compliance of ws "text" message payloads.  Until now lws does not get
>> involved in the content of the text messages leaving that for the user
>> code.  Any feelings about that out there?
>
> We pass everything I expect we should pass now.
>
> https://libwebsockets.org/reports/clients/index.html
>
>   - 2.10 / 2.11 are spamming 10 PINGs without waiting for PONGs, we pass
> it sometimes because we happen to serve each PONG before we get the next
> PING.  But since on a single connection with only the two peer endpoints
> we never expect to get back to back queue of PINGs, this seems to not
> bring any value to support it.  Anyone think it's actually useful?
>
>   - 6.* we don't check any UTF-8 as it is.  So we pass the ones that
> expect nothing special to happen and fail the rest.
>
>   - 7.5.1 is actually a check for invalid UTF-8 in CLOSE, we don't check
> anything related to UTF-8
>
>   - 12.* + 13.* claim compression "unimplemented" I didn't look at it yet.
>
> Otherwise everything else passes.
>
> I am not sure yet what to do about UTF-8.  I guess most users do not
> want lws bogged down with elaborate locale checks on every character
> that goes through it.  However if it could be confirmed in the parser
> state machine very cheaply maybe it should be done, for TEXT and CLOSE
> ws packet payloads.  I wrote a tiny parser for it already for lejp
>
> http://git.libwebsockets.org/cgi-bin/cgit/liblejp/tree/lejp.c#n219
>
> If we don't really care about it but want to conform, we could implement
> an example of how to do in test-echo.  But that's messier than doing it
> in the lib since it has to hold state there between RX packets.

Joakim pointed me to a nice table-based UTF-8 validator.  After staring 
at the author's state diagram for a while I made a much smaller one that 
should be vanishingly cheap for the most common case it's actually ASCII.

https://github.com/warmcat/libwebsockets/commit/0c7b38b1445585bd767050ee64cec83ca55882ec

With that, we pass everything in Autobahn wstest fuzzing except 2.10 / 
2.11 and "compression".

However after doing it, I realized this new strictness will make trouble 
for users who are sending non-UTF-8 binary in TEXT, which until now was 
OK for lws.

So I added a context creation-time option flag 
LWS_SERVER_OPTION_VALIDATE_UTF8, you have to set this in info->options 
to "opt-in" to having utf-8 validated in TEXT and CLOSE frames.

I added this flag to test-echo so he can continue to make Autobahn 
happy.  But this won't affect anyone else unless they ask for it.

-Andy

> -Andy
>
>> -Andy
>
>> _______________________________________________
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
>> http://ml.libwebsockets.org/mailman/listinfo/libwebsockets
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> http://ml.libwebsockets.org/mailman/listinfo/libwebsockets



More information about the Libwebsockets mailing list