Multiple issues with IPv6 and IPvFuture literal parsing
yescallop opened this issue · comments
I found several issues with IP literal parsing in uriparser
when fuzzing fluent-uri
against this library. Here's a list of them:
- According to RFC 3986 (RFC 3513), the use of
::
in an IPv6 address indicates one or more groups of 16 bits of zeros. However, parsing//[0:0:0:0:0:0:0::1]
succeeds. - A leading or trailing
:
that is not part of a::
is not permitted in an IPv6 address, but parsing//[:1::1:]
succeeds. - The leading
v
of an IPvFuture is case-insensitive (see RFC 3986), but parsing//[VF.addr]
fails. - Parsing
//[::1.1.1.11]
and//[::1.1.1.111]
succeeds somehow, but parsing//[::1.1.1.100]
fails. - Parsing
//[1:1:1:1:1:1::1.1.1.1]
succeeds.
Here's my fuzz target against uriparser
which I hope could help: against_uriparser.rs.
Hi @yescallop,
thanks for bringing this to my attention. From a quick look all three of these are bugs. I will have a closer look.
Hi @hartwork,
I wonder if you'd have time to take a look at this? Thanks :)
@yescallop I have been busy with work for the most part, but it's not forgotten. Are you blocked by these very bugs somewhere?
Nope, actually. But I think I've figured out a fix now :) I'll open a PR to close this if extra fuzzing goes fine.
Hi again @yescallop,
I found some time to check your report against the related RFCs 3986 and 3513 now, for a start:
- According to RFC 3986 (RFC 3513), the use of
::
in an IPv6 address indicates one or more groups of 16 bits of zeros. However, parsing//[0:0:0:0:0:0:0::1]
succeeds.
Confirming as a bug, 7 + 1 + 1 > 8.
- A leading or trailing
:
that is not part of a::
is not permitted in an IPv6 address, but parsing//[:1::1:]
succeeds.
Confirming as a bug.
- The leading
v
of an IPvFuture is case-insensitive (see RFC 3986), but parsing//[VF.addr]
fails.
Confirming as a bug. I wish that RFC 3986 would show that in the grammar better.
- Parsing
//[::1.1.1.11]
and//[::1.1.1.111]
succeeds somehow, but parsing//[::1.1.1.100]
fails.
Confirming as a bug.
- Parsing
//[1:1:1:1:1:1::1.1.1.1]
succeeds.
Confirming as a bug, 6 + 1 + 2 > 8.
Excellent work, thanks for these reports!