On Wed, Mar 2, 2022 at 3:30 PM Antoine Beaupré <[email protected]> wrote:
> Do you plan to pass a significant security audit over the procmail code > base and fuzz the binary? > A binary fuzz is being planned, but if anyone has a ready setup which I can run, it would be much appreciated. A security audit I did, two years ago. I plan to do one again after the fuzz results. The critical paths are those until it drops setuid/setgid root status, which is reasonably contained. > But software security has changed a lot in the past 20 years. Even C has > moved on. The current codebase is littered with things like strcpy and > difficult to parse macros. The coding style is historically interesting, > but would be rather surprising to many reviewers. > I agree that the coding style is quaint. That is not to say that despite the old-style use of strcpy, I was fully aware of all the pitfalls back then, and am still fully aware of them now. As far as I could guarantee back then, all strcpy() uses are accounted for and have been hand-checked to not cause stack/heap overflows. It definitely never has been, and never will be the case that they have been used in a handwaving fashion. > With my security researcher hat on, I am confident there are still > significant security issues in procmail, even with the fixes committed > to the git repository you have pointed out. > Well, from a purely statistical standpoint considering old software in general that hasn't been used since, I'd have to agree with you. Then again, with the same statistical view specific to procmail and friends (which undoubtedly have seen a declining use over the years, then again, it has been installed on more systems, so that might have slowed the decline), I see the following (from a security standpoint) over a period of 16 years: - In procmail proper: exactly 1 bug that causes stack/heap corruption (commit 990f9d4), which cannot be used to elevate privileges, because it can only happen in the path after setuid/setgid privs have been dropped. It can be triggered only by crafting a special procmailrc, so it only affects the command-line caller inflicting it upon himself. - In formail proper: 3 bugs causing a pointer to run off into the heap (commit 570ef09, commit 5e6dfe0 and commit d35595a), destroying the heap-structure, directly followed by a free()/malloc()/realloc() which traverses the corrupted structure. So primarily a segfault on demand. What can we learn from this: a. Clearly I had my security focus on procmail back then. But all the critical paths have been audited to pieces before the year 2000. b. The 3 heap corruption bugs in formail, I'm certainly not proud of them, but none of them are readily exploitable because they never corrupt the stack, only the heap, and are likely to result in segfaults because the heap structures are visited shortly after the corruption. c. A score of one critical but not exploitable bug in 16 years of use in procmail does not seem so bad. d. A score of three critical (and very similar) but not exploitable bugs in 16 years of use in formail (which is (just) a regular non-setuid root binary) does not seem so bad either. > I do not believe that, in its current state, procmail should be shipped > in the next Debian release, let alone with SUID bits by default. > >From a statistical standpoint, given the points a) to d) above, I'd say that procmail/formail have a above average track record and can be trusted. > So while it's interesting that you are making procmail active again, > maybe we could be careful about including it in the next Debian release? > Let's see if it can be brought back to shape and deal with the modern > threats email servers are currently faced with. > The way procmail was designed from a security/threat standpoint is not different from the threats that modern email servers face now. If you we still fail any fuzz-tests, I'd agree with you, but if fuzz tests prove it to be robust, I'd say that given the other arguments, it can be declared safe and compliant. -- Stephen.
