Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple issues with IPv6 and IPvFuture literal parsing #146

Closed
yescallop opened this issue Apr 17, 2022 · 5 comments · Fixed by #150
Closed

Multiple issues with IPv6 and IPvFuture literal parsing #146

yescallop opened this issue Apr 17, 2022 · 5 comments · Fixed by #150
Assignees
Labels
bug Something isn't working
Milestone

Comments

@yescallop
Copy link
Contributor

yescallop commented Apr 17, 2022

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.

@hartwork hartwork changed the title Multiple issues with IP literal parsing Multiple issues with IPv6 and IPvFuture literal parsing Apr 17, 2022
@hartwork hartwork added the bug Something isn't working label Apr 17, 2022
@hartwork
Copy link
Member

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.

@yescallop
Copy link
Contributor Author

Hi @hartwork,

I wonder if you'd have time to take a look at this? Thanks :)

@hartwork
Copy link
Member

hartwork commented Jun 2, 2022

@yescallop I have been busy with work for the most part, but it's not forgotten. Are you blocked by these very bugs somewhere?

@yescallop
Copy link
Contributor Author

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.

@hartwork
Copy link
Member

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!

@hartwork hartwork added this to the 0.9.7 milestone Sep 29, 2022
@hartwork hartwork self-assigned this Sep 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants