> 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
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
