Re: CVE request: procmail heap overflow in getlline()

[Martino Dell'Ambrogio <tillo () tillo ch>]

For what is worth, I strongly believe this is a security bug for the 
same reason.
As soon as there is an undocumented way to execute code, it will be 
impossible for a .procmailrc file generator to avoid execution of code.
Workaround measures like security capabilities can not be taken into 
account as they are not implicit.

Martino Dell'Ambrogio
Security Auditor
Web: http://www.tillo.ch/
Email: tillo () tillo ch

On 12/04/2014 10:58 AM, Florian Weimer wrote:
> On 12/04/2014 09:41 AM, Kurt Seifried wrote:
> > On 04/12/14 12:57 AM, Santiago Vila wrote:
> > > On Wed, Dec 03, 2014 at 05:30:57PM -0600, Joshua J. Drake wrote:
> > > > Is it possible to trigger this issue with untrusted input or only
> > > > trusted input from procmailrc?
> > >
> > > This is an issue with the handling of .procmailrc file, which contains
> > > the filter rules for procmail. An external attacker is not supposed to
> > > provide the .procmailrc file at /home/user, only the email to be
> > > filtered, so, IMHO, this is a bug but maybe not a security bug.
> > >
> > > Thanks.
> >
> > I disagree. Many mail servers allow people to edit their .procmailrc but
> > explicitly block shell accounts. This would allow a user with a non
> > interactive shell account to execute arbitrary commands using procmailrc
> > even if they were otherwise restricted (e.g. using permissions or
> > SELinux for example).
>
> procmail already executes commands in lines starting with “|” (and the 
> documentation suggests it does not honor SHELL, so SHELL=/bin/false 
> does not block this).  If permissions/SELinux contain that, they will 
> also work against a procmailrc parser exploit.  In other words, I 
> don't think there's a security bug here.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature