uriparser / uriparser

:hocho: Strictly RFC 3986 compliant URI parsing and handling library written in C89; moved from SourceForge to GitHub

Home Page:https://uriparser.github.io/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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!