[Rpm-maint] [rpm-software-management/rpm] Use int64_t for lengths (#1492)

[Demi Marie Obenour]

> So yeah, I'll note this here now for lack of better place.
> 
> _I_ am overflowing with all these PR's to add a little check here and another on there. Time to take a step back and cool off a little. There clearly are various missing checks in the code but seems to me we're running in circles putting out small fires here and there rather than addressing the fundamental issues (already hinted at this in #1494)

The biggest question is _what the fundamental issues are_.  Using signed types where unsigned types should be used is one.  Not checking for overflow before arithmetic is another.  That said, I believe the biggest improvements are:

- Continuous fuzzing.  libfuzzer is incredibly good at finding bugs, especially when combined with ASAN and UBSAN.  And once we get it set up, we can enroll rpm in Google’s OSS-Fuzz, which will perform automatic fuzzing on every commit at massive scale.
- Use a bounded buffer abstraction for parsing and serialization.  That lets us write the security-critical bounds (and other) checks _once_, and centralizes them where they can be easily audited and tested.  BoringSSL has such an abstraction under an ISC license already.
- Clearly separate untrusted and trusted data.  QubesOS uses variables with names starting with `untrusted_` for the former.
- More tests.  We probably won’t be able to go as far as SQLite, but we can go farther than we do now.
- Be as strict as possible when parsing.  While we are limited by backwards compatibility, we should be as strict as possible within that constraint.  RPMv6 is an opportunity to tighten the rules on what will be accepted, and I suggest using it.

Some longer-term ideas:

- Consider alternatives to C.  I understand that Rust is not currently portable enough, as RPM supports architectures that LLVM does not.  That said, a GCC backend for Rust is in development, which will make Rust able to target any platform GCC supports.  More immediately, we might be able to move some logic to Lua.  If we required SQLite, we might even be able to implement some of the logic as SQL queries against the rpmdb.
- (Someday) Formal methods.  Just being able to prove that certain functions (such as `headerImport`) don’t have undefined behavior would be awesome.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1492#issuecomment-785373237
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20210224/33a93183/attachment.html>