HeaderMap: C string to string_view conversion follow ups

[dnoe]

Description:

These are various places where we need to follow up to complete removal of C style strings in the header map.

1. HeaderString::find(const char* str) can probably be eliminated entirely by converting call sites to use getStringView().find().
2. StringUtil::atoull currently requires creation of some temporary std::string objects because it expects C strings, and also returns a C style string. Most call sites ignore the return value, so they can be converted to use absl::SimpleAtoi or a new StringUtil function that takes and returns string views.
3. UuidUtils::uuidModBy() should be migrated to take absl::string_view
4. Span::setOperation() should be migrated to take absl::string_view

Context:
#6494
#6564

Action item for CVE-2019-9900

[dnoe]

Once this is all done, we can reclaim the NUL byte: #6581

[dnoe]

Span::setTag could also use some love.

[dnoe]

GzipFilter::isContentTypeAllowed can use heterogeneous lookup to elide an std::string construction if CaseUnorderedSet is updated to use a Swiss Set.

[dnoe]

Looks like StringUtil::atoll can be replaced entirely by calls to absl::SimpleAtoi since all uses are base 10 conversions.

[dnoe]

The remaining fruit left hanging:

1. StringUtil::atoull is still used for Base 16 hex conversions. Unfortunately absl::SimpleAtoi only does base 10. It looks like there are no remaining non-hex users of StringUtil::atoull, but there are a number of hex ones. Since atoull is just a relatively thin wrapper around std::strtoull which expects a C string this fruit hangs high.
2. UuidUtils::uuidModBy() is one of the hex conversions, and will be an easy follow up once 1) is done.

[mattklein123]

@dnoe one quick thought here: Maybe rename StringUtil::atoull to hexToUint or something just so we prevent new uses of base 10 conversion?

[dnoe]

I like this idea. It would enable us to write a custom hexToUint which only has to support hex, and then if any future other odd base use cases show up then the user can construct a string and use c_str() or roll their own conversion function if it's performance critical. I suspect those future use cases are extremely rare given none exist today.

[htuch]

@mattklein123 @dnoe one thought I had was to switch everyone to safe variants of StringUtil::atoull etc. that take a bound and clamp to this. This is to prevent potential wire level attacks where header values etc. are consumed opaquely and used for memory allocation or to attempt overflow attacks. By making the only methods we export for this safe-by-construction, we would have confidence in avoiding an entire class of attacks. We could then lint for the unsafe variants.

[mattklein123]

Yes agreed.

[dnoe]

Definitely. I'm just wondering if we can skip the generic atoull functionality for now and create a safe variant that takes a bound but only does hex. It can be refactored later if conversion from other bases is required but right now it looks like 10 and 16 are the only two being used and base 10 conversion is covered by absl::SimpleAtoi.

I guess we might need to think about extensions we aren't aware of here - when we get to this it's probably worth polling the community in case someone is using octal or whatever.

[htuch]

@dnoe I'm hoping we can also avoid direct reliance on absl::SimpleAtoi. Basically, anywhere we do ASCII to integer conversion, this is reasonable place to be defensive and go through wrapped variants that do bounds checks IMHO. Maybe there will be some performance exemptions, but we can deal with these on a case-by-case basis.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[htuch]

Is there any work here remaining? Is this just down to StringUtil:atoull? Would making its argument a string_view get rid of C strings outside this one util?

[mattklein123]

Is there any work here remaining? Is this just down to StringUtil:atoull? Would making its argument a string_view get rid of C strings outside this one util?

I'm not sure of current status. This issue is pretty old so my preference would be to assign an owner and do a fresh pass if we are going to keep this open.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[htuch]

Marking help wanted, I think we should at least cleanup the atoull.