On 10/26/20 5:22 AM, [email protected] wrote:
> October 23, 2020 6:00 PM, "Demi M. Obenour" <[email protected]> wrote:
> 
>> How important is the caching of userinfo data in mda.c? For security
>> reasons, I want userinfo lookups to happen in forkmda() in the child
>> process.
>>
> 
> Fairly important as if mda.c no longer do userinfo lookups, it becomes
> possible to provoke a DoS by preventing deliveries from happening in a
> relatively fair distribution. i.e: I could flood myself so that mda is
> saturated with mail deliveries to gilles@ which will then cause parent
> to call forkmda() exclusively for gilles@ and hit process limits which
> will prevent other users from getting their mails.
> 
> Note that it's not so much a caching of userinfo, it's a session which
> lives only as long as you're delivering for a specific user and that's
> gone when no deliveries are pending.
> 
> What problem are you trying to solve ?

As with my question about restricting MDAs, I am trying to prevent a
compromised or buggy PROC_PONY from tricking PROC_PARENT into doing
something nasty.  Many MDAs follow symbolic links, and trust that
$HOME is set correctly.  Therefore, if PROC_PONY and at least one
ordinary user have been compromised, they could collude to have
attacker-controlled mail written to an arbitrary location in any
non-root user's home directory.  This is enough for code execution.
As discussed in Qualys's writeup for CVE-2020-8794, code execution as
an attacker-chosen non-root user is usually enough to get root access.

Another approach would be for mda.c to run in a separate process
(PROC_MDA?) and for PROC_MDA and PROC_LOOKUP to run as a separate user.
To be effective, this would require fixing some type confusion bugs
in imsg handling.

Yet another approach would be for PROC_PARENT to maintain a session
keyed by user name, and for PROC_PONY to explicitly create and
destroy them.  That keeps the complexity in an unprivileged process,
where it belongs.

Sincerely,

Demi

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to