Debian Bug report logs - #1006633
procmail is unmaintained upstream

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: procmail is unmaintained and a security liability

Date: Mon, 28 Feb 2022 21:11:49 -0500

Package: procmail
Version: 3.22-26
Severity: critical
Tags: security
X-Debbugs-Cc: Debian Security Team <team@security.debian.org>

procmail is a security liability and completely unmaintained
upstream. there are viable alternatives, and it should be removed from
debian. details below.

# unmaintained

procmail is unmaintained. the "Final release", according to
Wikipedia[1], dates back to September 10, 2001 (3.22). this is the
release that is shipped with Debian, although we do have *26*
debian-specific uploads on top of that (3.22-26, in all suites since
buster).

[1]: https://en.wikipedia.org/wiki/Procmail

that release entered Debian on 2001-11-21, now twenty (!) years ago,
and presumably shipped with Debian 3.0 "woody":

https://tracker.debian.org/news/269157/installed-procmail-322-1-i386-source/

the upstream website has been down since about 2016, according to a
quick tour around archive.org. it currently returns an empty JSON
document, mysteriously. (reported as #805864 in 2015, no change
since.)

in effect, we are maintaining a fork of this dead software.

# security liability

by default, procmail is installed suid root:mail. there's no debconf
or preseed that can change that, although you could, in theory, do a
dpkg-divert to workaround that, but I doubt anyone deploying procmail
these days does that.

the last maintainer of procmail explicitly advised us (in #769938) and
other projects (e.g. OpenBSD, in [2]) to stop shipping it.

[2]: https://marc.info/?l=openbsd-ports&m=141634350915839&w=2

Quote:

> Executive summary: delete the procmail port; the code is not safe
> and should not be used as a basis for any further work.

That Debian bug report is still open, and concerns a NULL pointer
dereference. I do not know if it is exploitable. Strangely, the
original procmail author (Stephen R. van den Berg, presumably) wrote
in that bug report *last year* saying that was "Fixed in upcoming 3.23
release", which has been targeted for release for all of those last 20
years.

# alternatives

there are plenty of modern alternatives to procmail, typically part of
the mail server. Dovecot has its own LDA which implements the standard
Sieve language (RFC 5228, published in 2008, 7 years after procmail's
death). Courier has "maildrop" which has its own filtering
mechanism. then the tmux author, in 2007, wrote fdm as a fetchmail and
procmail replacement.

but procmail, of course, doesn't just ship procmail (that would be too
easy). it ships `mailstat(1)` which we could probably ignore because
it only parses procmail log files. but more importantly, it also
ships:

lockfile - conditional semaphore-file creator
formail - mail (re)formatter

lockfile already has somewhat acceptable (if TOCTOU is something you
like) in the form of `flock(1)`, part of util-linux (which is
Essential). it might not be a direct drop-in replacement, but it
should be close enough.

formail is similar: the courier `maildrop` package ships
`reformail(1)` which is, presumably, a rewrite of formail. it's
unclear if it's a drop-in replacement, but it should probably possible
to port uses of formail to it easily.

# conclusion

there is really, absolutely, no reason to keep procmail in Debian at
this point. it's a great part of our computing history, and it should
be kept forever in our museums and historical archive, but not in
main, and certainly not in bookworm or even sid. it's just a bomb
waiting to go off.

-- System Information:
Debian Release: 11.2
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages procmail depends on:
ii  libc6  2.31-13+deb11u2

Versions of packages procmail recommends:
ii  postfix [mail-transport-agent]  3.5.6-1+b1

procmail suggests no packages.

Message #10 received at 1006633@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Antoine Beaupre <anarcat@debian.org>, 1006633@bugs.debian.org, "Stephen R. van den Berg" <srb@cuci.nl>

Subject: Re: Bug#1006633: procmail is unmaintained upstream

Date: Tue, 1 Mar 2022 15:37:42 +0100

severity 1006633 important
retitle 1006633 procmail is unmaintained upstream

Hi.

I could understand that we want to get rid of unmaintained software, but 
please do not inflate severities, at least while the discussion takes 
place and a consensus that the package should be removed has not been 
reached. This package is optional, and we are not forcing anybody to use 
it. If we had kept the extra priority, I would be glad to put it in 
"extra", but extra does not exist anymore.

There are some things which need a clarification because they are not 
100% accurate.

El 1/3/22 a las 3:11, Antoine Beaupre escribió:
> # unmaintained
> 
> procmail is unmaintained. the "Final release", according to
> Wikipedia[1], dates back to September 10, 2001 (3.22). this is the
> release that is shipped with Debian, although we do have *26*
> debian-specific uploads on top of that (3.22-26, in all suites since
> buster).

The Debian package is actually based on version "3.23pre" since version 
3.22-21, dated 2013-10-15. I know this is a very minor correction, but I 
think it's important to state the facts right.

While it's true that procmail has not been maintained upstream for a 
long time, Debian is absolutely in his right to maintain its own version 
without an upstream, that's one of the properties of free software.

> the last maintainer of procmail explicitly advised us (in #769938) and
> other projects (e.g. OpenBSD, in [2]) to stop shipping it.

Same as before, Debian is in his right to follow this advice or not.

> That Debian bug report is still open, and concerns a NULL pointer
> dereference.

I've just make an upload to fix such bug.

Debian security people: Is there a CVE for Bug #769938? Maybe this
should backported for stable as well.

> I do not know if it is exploitable. Strangely, the
> original procmail author (Stephen R. van den Berg, presumably) wrote
> in that bug report *last year* saying that was "Fixed in upcoming 3.23
> release", which has been targeted for release for all of those last 20
> years.

I guess he did not refer to the version which was "upcoming 20 years 
ago", but to the git version on which he was working in the last years.

In either case, I'm Cc:ing Stephen, who some time ago was preparing a 
release which included all the Debian fixes so far.

Stephen: If you intend to release a new procmail version, please do so.

Thanks.

Message #19 received at 1006633@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Santiago Vila <sanvila@unex.es>, 1006633@bugs.debian.org, "Stephen R. van den Berg" <srb@cuci.nl>

Subject: Re: Bug#1006633: procmail is unmaintained upstream

Date: Tue, 01 Mar 2022 09:57:52 -0500

On 2022-03-01 15:37:42, Santiago Vila wrote:
> severity 1006633 important
> retitle 1006633 procmail is unmaintained upstream

I think that title is a mischaracterisation. Procmail is not just
unmaintained upstream, it's known to be insecure.

> Hi.

Hi,

> I could understand that we want to get rid of unmaintained software, but 
> please do not inflate severities, at least while the discussion takes 
> place and a consensus that the package should be removed has not been 
> reached. This package is optional, and we are not forcing anybody to use 
> it. If we had kept the extra priority, I would be glad to put it in 
> "extra", but extra does not exist anymore.

I disagree with this assesment. If this was any leaf package with normal
permissions, I wouldn't mind. but procmail installs a SUID binary and,
because of that, should be subject to much stricter rules.

There were two bug reports asking for the SUID bit to be dropped or at
least be configurable (#298058, #264011), both of which were closed in
favor of dpkg-statoverride. But that, in my opinion, is not the right
mechanism: we should "fail closed" and default to a more secure option,
with the burden on the caller to enable a more dangerous option.

So this is not just some random package that's unmaintained. It's a key,
high profile security risk.

Also, I understand that we're not responsible for all the "guns" we ship
for people to "shoot in the foot" with. I get that. But this one doesn't
say anywhere on the tin that we're basically the upstream now.

> There are some things which need a clarification because they are not 
> 100% accurate.
>
> El 1/3/22 a las 3:11, Antoine Beaupre escribió:
>> # unmaintained
>> 
>> procmail is unmaintained. the "Final release", according to
>> Wikipedia[1], dates back to September 10, 2001 (3.22). this is the
>> release that is shipped with Debian, although we do have *26*
>> debian-specific uploads on top of that (3.22-26, in all suites since
>> buster).
>
> The Debian package is actually based on version "3.23pre" since version 
> 3.22-21, dated 2013-10-15. I know this is a very minor correction, but I 
> think it's important to state the facts right.

"3.23pre" doesn't really sound like a release at all to me...

> While it's true that procmail has not been maintained upstream for a 
> long time, Debian is absolutely in his right to maintain its own version 
> without an upstream, that's one of the properties of free software.

Sure. We have every right to ship dead and unmaintained software if we
really, really want to. My argument is that we *shouldn't*.

>> the last maintainer of procmail explicitly advised us (in #769938) and
>> other projects (e.g. OpenBSD, in [2]) to stop shipping it.
>
> Same as before, Debian is in his right to follow this advice or not.

Yes, but is it *right* to ignore it? I strongly doubt that.

I'm not making a legal argument here. I'm making an ethical argument:
procmail is unmaintained and insecure, and we shouldn't ship it.

There are plenty of programs we remove from Debian because they are
unmaintained upstream, even *without* being insecure. That's fine. We
are a free software clearing house, not a dump.

>> That Debian bug report is still open, and concerns a NULL pointer
>> dereference.
>
> I've just make an upload to fix such bug.

I'm sorry, but the fact that it took over 7 years to do this is
telling. That bug isn't fixed upstream, for example.

> Debian security people: Is there a CVE for Bug #769938? Maybe this
> should backported for stable as well.
>
>> I do not know if it is exploitable. Strangely, the
>> original procmail author (Stephen R. van den Berg, presumably) wrote
>> in that bug report *last year* saying that was "Fixed in upcoming 3.23
>> release", which has been targeted for release for all of those last 20
>> years.
>
> I guess he did not refer to the version which was "upcoming 20 years 
> ago", but to the git version on which he was working in the last years.

But the 3.22-1 upload explicitly refers to that 3.23pre release:

procmail (3.22-1) unstable; urgency=low

  * New upstream release, which uses the `standard' format for Maildir
    filenames and retries on name collision. It also contains some
    bug fixes from the 3.23pre snapshot dated 2001-09-13.
  * Removed `sendmail' from the Recommends field, since we already
    have `exim' (the default Debian MTA) and `mail-transport-agent'.
  * Removed suidmanager support. Conflicts: suidmanager (<< 0.50).
  * Added support for DEB_BUILD_OPTIONS in the source package.
  * README.Maildir: Do not use locking on the example recipe,
    since it's wrong to do so in this case.

 -- Santiago Vila <sanvila@debian.org>  Wed, 21 Nov 2001 09:40:20 +0100

That's what I'm refering to. The existence of 3.23pre was manifest all
the way back in 2001, unless that changelog is inaccurate.

So I think it's fair for me to assume that there's a good chance that
3.23 will never see the light of day, especially since the procmail.org
homepage is dead.

Where would it even be released?

> In either case, I'm Cc:ing Stephen, who some time ago was preparing a 
> release which included all the Debian fixes so far.
>
> Stephen: If you intend to release a new procmail version, please do so.

I'm sorry if I'm beating a dead horse here, but this is just the tip of
the iceberg. My understanding of the current situation is that anyone
running AFL long enough for procmail will find further major security
issues and that will take an untold amount of time to fix.

The fact that we had a possibly exploitable NULL deref open for 7 years
and shipped in two release is already alarming enough. We shouldn't keep
doing this and stop shipping this in stable releases.

Do we really need someone to go through with this process and flood this
bugtracker with fuzzer bugs to prove that point?

If you want to keep procmail in Debian, please at least keep it away
from stable.

Thanks.

a.

-- 
Sous le projecteur, on ne voit pas les autres.
                        - Félix Leclerc

Message #24 received at 1006633@bugs.debian.org (full text, mbox, reply):

From: "Stephen R. van den Berg" <srb@cuci.nl>

To: Antoine Beaupré <anarcat@debian.org>

Cc: Santiago Vila <sanvila@unex.es>, 1006633@bugs.debian.org

Subject: Re: Bug#1006633: procmail is unmaintained upstream

Date: Wed, 2 Mar 2022 11:07:02 +0100

[Message part 1 (text/plain, inline)]

As of May 2020, the dormant state of procmail upstream maintenance has been
changed back to active.

As Santiago Vila can attest to, I have taken up active maintenance of
procmail again since the past two years (lockdowns appear to have its uses
after all).
All bugreports have been actively fixed since May 2020.
It's time for a new release version v3.24.

The latest version can now always be found at:
https://github.com/BuGlessRB/procmail
Official releases are tagged, as in this case: v3.24
The repository currently has tags going back to v3.20

I'd be willing to include a Debian directory with all the things you need
to ease Debian packaging, just tell me what I should put in there.

On Tue, Mar 1, 2022 at 3:58 PM Antoine Beaupré <anarcat@debian.org> wrote:

> On 2022-03-01 15:37:42, Santiago Vila wrote:
> > severity 1006633 important
> > retitle 1006633 procmail is unmaintained upstream
>
> I think that title is a mischaracterisation. Procmail is not just
> unmaintained upstream, it's known to be insecure.
>
> > Hi.
>
> Hi,
>
> > I could understand that we want to get rid of unmaintained software, but
> > please do not inflate severities, at least while the discussion takes
> > place and a consensus that the package should be removed has not been
> > reached. This package is optional, and we are not forcing anybody to use
> > it. If we had kept the extra priority, I would be glad to put it in
> > "extra", but extra does not exist anymore.
>
> I disagree with this assesment. If this was any leaf package with normal
> permissions, I wouldn't mind. but procmail installs a SUID binary and,
> because of that, should be subject to much stricter rules.
>
> There were two bug reports asking for the SUID bit to be dropped or at
> least be configurable (#298058, #264011), both of which were closed in
> favor of dpkg-statoverride. But that, in my opinion, is not the right
> mechanism: we should "fail closed" and default to a more secure option,
> with the burden on the caller to enable a more dangerous option.
>
> So this is not just some random package that's unmaintained. It's a key,
> high profile security risk.
>
> Also, I understand that we're not responsible for all the "guns" we ship
> for people to "shoot in the foot" with. I get that. But this one doesn't
> say anywhere on the tin that we're basically the upstream now.
>
> > There are some things which need a clarification because they are not
> > 100% accurate.
> >
> > El 1/3/22 a las 3:11, Antoine Beaupre escribió:
> >> # unmaintained
> >>
> >> procmail is unmaintained. the "Final release", according to
> >> Wikipedia[1], dates back to September 10, 2001 (3.22). this is the
> >> release that is shipped with Debian, although we do have *26*
> >> debian-specific uploads on top of that (3.22-26, in all suites since
> >> buster).
> >
> > The Debian package is actually based on version "3.23pre" since version
> > 3.22-21, dated 2013-10-15. I know this is a very minor correction, but I
> > think it's important to state the facts right.
>
> "3.23pre" doesn't really sound like a release at all to me...
>
> > While it's true that procmail has not been maintained upstream for a
> > long time, Debian is absolutely in his right to maintain its own version
> > without an upstream, that's one of the properties of free software.
>
> Sure. We have every right to ship dead and unmaintained software if we
> really, really want to. My argument is that we *shouldn't*.
>
> >> the last maintainer of procmail explicitly advised us (in #769938) and
> >> other projects (e.g. OpenBSD, in [2]) to stop shipping it.
> >
> > Same as before, Debian is in his right to follow this advice or not.
>
> Yes, but is it *right* to ignore it? I strongly doubt that.
>
> I'm not making a legal argument here. I'm making an ethical argument:
> procmail is unmaintained and insecure, and we shouldn't ship it.
>
> There are plenty of programs we remove from Debian because they are
> unmaintained upstream, even *without* being insecure. That's fine. We
> are a free software clearing house, not a dump.
>
> >> That Debian bug report is still open, and concerns a NULL pointer
> >> dereference.
> >
> > I've just make an upload to fix such bug.
>
> I'm sorry, but the fact that it took over 7 years to do this is
> telling. That bug isn't fixed upstream, for example.
>
> > Debian security people: Is there a CVE for Bug #769938? Maybe this
> > should backported for stable as well.
> >
> >> I do not know if it is exploitable. Strangely, the
> >> original procmail author (Stephen R. van den Berg, presumably) wrote
> >> in that bug report *last year* saying that was "Fixed in upcoming 3.23
> >> release", which has been targeted for release for all of those last 20
> >> years.
> >
> > I guess he did not refer to the version which was "upcoming 20 years
> > ago", but to the git version on which he was working in the last years.
>
> But the 3.22-1 upload explicitly refers to that 3.23pre release:
>
> procmail (3.22-1) unstable; urgency=low
>
>   * New upstream release, which uses the `standard' format for Maildir
>     filenames and retries on name collision. It also contains some
>     bug fixes from the 3.23pre snapshot dated 2001-09-13.
>   * Removed `sendmail' from the Recommends field, since we already
>     have `exim' (the default Debian MTA) and `mail-transport-agent'.
>   * Removed suidmanager support. Conflicts: suidmanager (<< 0.50).
>   * Added support for DEB_BUILD_OPTIONS in the source package.
>   * README.Maildir: Do not use locking on the example recipe,
>     since it's wrong to do so in this case.
>
>  -- Santiago Vila <sanvila@debian.org>  Wed, 21 Nov 2001 09:40:20 +0100
>
> That's what I'm refering to. The existence of 3.23pre was manifest all
> the way back in 2001, unless that changelog is inaccurate.
>
> So I think it's fair for me to assume that there's a good chance that
> 3.23 will never see the light of day, especially since the procmail.org
> homepage is dead.
>
> Where would it even be released?
>
> > In either case, I'm Cc:ing Stephen, who some time ago was preparing a
> > release which included all the Debian fixes so far.
> >
> > Stephen: If you intend to release a new procmail version, please do so.
>
> I'm sorry if I'm beating a dead horse here, but this is just the tip of
> the iceberg. My understanding of the current situation is that anyone
> running AFL long enough for procmail will find further major security
> issues and that will take an untold amount of time to fix.
>
> The fact that we had a possibly exploitable NULL deref open for 7 years
> and shipped in two release is already alarming enough. We shouldn't keep
> doing this and stop shipping this in stable releases.
>
> Do we really need someone to go through with this process and flood this
> bugtracker with fuzzer bugs to prove that point?
>
> If you want to keep procmail in Debian, please at least keep it away
> from stable.
>
> Thanks.
>
> a.
>
> --
> Sous le projecteur, on ne voit pas les autres.
>                         - Félix Leclerc
>
>

-- 
Stephen.

[Message part 2 (text/html, inline)]

Message #29 received at 1006633@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: "Stephen R. van den Berg" <srb@cuci.nl>, Antoine Beaupré <anarcat@debian.org>

Cc: 1006633@bugs.debian.org

Subject: Re: Bug#1006633: procmail is unmaintained upstream

Date: Wed, 2 Mar 2022 11:28:35 +0100

El 2/3/22 a las 11:07, Stephen R. van den Berg escribió:
> I'd be willing to include a Debian directory with all the things you 
> need to ease Debian packaging, just tell me what I should put in there.

Note: It's almost always better not to include a debian/* directory at all.

Thanks.

Message #34 received at 1006633@bugs.debian.org (full text, mbox, reply):

From: "Stephen R. van den Berg" <srb@cuci.nl>

To: Santiago Vila <sanvila@unex.es>

Cc: Antoine Beaupré <anarcat@debian.org>, 1006633@bugs.debian.org

Subject: Re: Bug#1006633: procmail is unmaintained upstream

Date: Wed, 2 Mar 2022 11:41:36 +0100

[Message part 1 (text/plain, inline)]

On Wed, Mar 2, 2022 at 11:28 AM Santiago Vila <sanvila@unex.es> wrote:

> Note: It's almost always better not to include a debian/* directory at all.
>

Noted.
Incidentally, all historical release tags are now back in the repository
for as long as the repository goes back.
-- 
Stephen.

[Message part 2 (text/html, inline)]

Message #39 received at 1006633@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: "Stephen R. van den Berg" <srb@cuci.nl>

Cc: Santiago Vila <sanvila@unex.es>, 1006633@bugs.debian.org

Subject: Re: Bug#1006633: procmail is unmaintained upstream

Date: Wed, 02 Mar 2022 09:29:46 -0500

Hi Stephen (and Santiago),

Do you plan to pass a significant security audit over the procmail code
base and fuzz the binary?

I don't think fixing the handful of security issues that were publicly
disclosed is enough, to be honest.

I don't know how else to put this; I am truly grateful for the amazing
work you've done on all those projects. I have used procmail myself
extensively, probably for almost two decades, before switching away, and
it was amazing for the time I used it.

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.

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.

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.

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.

I don't mean to necessarily completely remove procmail from Debian if it
eventually finds its way towards a more secure and maintainable
codebase, but I strongly feel it's not fit for release in its current
shape.

Thank you for your understanding,

a.

Message #44 received at 1006633@bugs.debian.org (full text, mbox, reply):

From: "Stephen R. van den Berg" <srb@cuci.nl>

To: Antoine Beaupré <anarcat@debian.org>

Cc: Santiago Vila <sanvila@unex.es>, 1006633@bugs.debian.org

Subject: Re: Bug#1006633: procmail is unmaintained upstream

Date: Thu, 3 Mar 2022 09:15:51 +0100

[Message part 1 (text/plain, inline)]

On Wed, Mar 2, 2022 at 3:30 PM Antoine Beaupré <anarcat@debian.org> 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.

[Message part 2 (text/html, inline)]

Message #49 received at 1006633@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: "Stephen R. van den Berg" <srb@cuci.nl>

Cc: Santiago Vila <sanvila@unex.es>, 1006633@bugs.debian.org

Subject: Re: Bug#1006633: procmail is unmaintained upstream

Date: Thu, 03 Mar 2022 09:31:46 -0500

On 2022-03-03 09:15:51, Stephen R. van den Berg wrote:
> On Wed, Mar 2, 2022 at 3:30 PM Antoine Beaupré <anarcat@debian.org> 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.

Thanks, that seems like a good idea. Let us know how the fuzzing turns
out.

[...]

>> 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:

[...]

One problem with those statistics is that they ignore the fact that
procmail has been basically declared un maintained for most of that
time. There is the distinct possibility that there hasn't been much
attention to this program from the security community because it was
thought that no one was still using it, because it was
unmaintained.

Turns out at least one of those affirmations were incorrect, and I guess
we'll see what the next ten years will bring.

[...]

>> 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.

I agree with that.

-- 
Celui qui sait jouir du peu qu'il a est toujours assez riche.
                         - Démocrite

Message #54 received at 1006633-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 1006633-close@bugs.debian.org

Subject: Bug#1006633: fixed in procmail 3.24-1

Date: Thu, 05 Jan 2023 22:10:44 +0000

Source: procmail
Source-Version: 3.24-1
Done: Santiago Vila <sanvila@debian.org>

We believe that the bug you reported is fixed in the latest version of
procmail, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1006633@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Santiago Vila <sanvila@debian.org> (supplier of updated procmail package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 05 Jan 2023 22:35:00 +0100
Source: procmail
Architecture: source
Version: 3.24-1
Distribution: unstable
Urgency: medium
Maintainer: Santiago Vila <sanvila@debian.org>
Changed-By: Santiago Vila <sanvila@debian.org>
Closes: 805864 1006633 1006653
Changes:
 procmail (3.24-1) unstable; urgency=medium
 .
   * New upstream release, now hosted on github. Closes: #1006633.
   * Downgrade priority to optional to match the override file.
   * Update Homepage. Closes: #805864.
   * Switch to dh. Now there is a procmail-dbgsym package. Closes: #1006653.
   * Drop debian/mailstat.1, it has been adopted upstream.
   * Set upstream metadata fields Bug-Database, Bug-Submit and Repository-Browse.
   * Rules-Requires-Root: binary-targets.
   * Use List-Id in QuickStart and README.Maildir.
   * Update standards version to 4.6.2.
   * No longer necessary patches:
     - 00: Adopted upstream (this is version 3.24, which is past 3.23pre).
     - 06: Adopted upstream.
     - 10: Adopted upstream.
     - 12: Adopted upstream.
     - 13: Adopted upstream.
     - 14: Fixed upstream in another way.
     - 15: Adopted upstream.
     - 16: Adopted upstream.
     - 17: Adopted upstream.
     - 18: Adopted upstream.
     - 19: Adopted upstream.
     - 21: Adopted upstream.
     - 22: Adopted upstream.
     - 23: Adopted upstream.
     - 24: Fixed upstream using cgetline.
     - 25: Adopted upstream.
     - 26: Adopted upstream.
     - 27: Fixed upstream in another way.
     - 28: Adopted upstream.
     - 29: Adopted upstream.
     - 30: Fixed upstream in another way.
     - 31: Adopted upstream.
   * Renamed patches:
     - 01: renamed to trim-list-of-directories-to-search.patch.
     - 02: renamed to use-fcntl-and-dot-locking.patch.
     - 03: renamed to do-not-touch-var-mail-during-build.patch.
     - 04: renamed to define-path-for-example-procmailrc.patch.
     - 05: renamed to allow-writeable-rcfiles.patch.
     - 07: renamed to make-buggy-sendmail-to-be-undefined.patch.
     - 08: renamed to define-default-path.patch.
     - 09: renamed to define-defaultdotlock-to-follow-locking-policy.patch.
     - 11: renamed to do-not-search-for-var-mail.patch.
     - 20: renamed to hardcode-things-for-biff.patch.
Checksums-Sha1:
 c782b310e44048d938c68bd59d7ed517dceaaf42 1368 procmail_3.24-1.dsc
 7de1d9d27fe0a59d553b93a4ace17e50003cf667 299704 procmail_3.24.orig.tar.gz
 5e67a69eb10529f8912540e7fe765f731e5b2de9 11024 procmail_3.24-1.debian.tar.xz
 6c623f6e41a2e150dae06fde352eafd03a0571f1 5420 procmail_3.24-1_source.buildinfo
Checksums-Sha256:
 a8324c76c510c212b2b5cfde717ebff038febc2dc8e7a44f4590499ef26080bc 1368 procmail_3.24-1.dsc
 514ea433339783e95df9321e794771e4887b9823ac55fdb2469702cf69bd3989 299704 procmail_3.24.orig.tar.gz
 18bcad62f3909dd9d04ea3f55cd35f35d7382d4a2f0339e86a97b2a96e3155a5 11024 procmail_3.24-1.debian.tar.xz
 6bfb8935810622be6aabc1dc2d27dde8641a35aedbc8ebfa672fb75a0dac71ac 5420 procmail_3.24-1_source.buildinfo
Files:
 bc593ae01c8c1c13df7306bd8f91b022 1368 mail optional procmail_3.24-1.dsc
 e38b8739e5c6400e3586c5fd9810c1e0 299704 mail optional procmail_3.24.orig.tar.gz
 81978e0114a588d9515f60d5117d2e56 11024 mail optional procmail_3.24-1.debian.tar.xz
 c3eec9c701b9998330b2c69b863aef28 5420 mail optional procmail_3.24-1_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE1Uw7+v+wQt44LaXXQc5/C58bizIFAmO3REYACgkQQc5/C58b
izLy8Af/ThuTd+UpE/RU4JdWhDo+Lu9EtbV+1sh47oxSAg1wApGY9GmeYzY8ZJBC
jDXzONiW2TlmiG4tGwVxFAP5wMvl4DCaVofU6kSRVr6R/Q0BAxMAQvH1TVsgwUIn
lxIF4jqvRtTsyVdRmnBPCHWBUne8Dvqrzk9dCvwyHLThi4JZYVZYm1MMVleImPVu
ukPrFVOyIBfiSBZV2WDvq1qCcpJ6meZNUl21MFajZVHAvbCxeUufRpKXGMx5y1Aj
FPvXlEcHFnc0QWXqnP/A7eyBTpTVOquNipy69JshWO/KlS3OVu77ULRpVSsY7/xY
VlNTj9PbI5ypcY9weHUxAcmxKo0ltA==
=ghQa
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.