Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 04 Dec 2014 15:03:26 +0100
From: Martino Dell'Ambrogio <>
Subject: Re: CVE request: procmail heap overflow in getlline()

On 12/04/2014 01:02 PM, Florian Weimer wrote:
> On 12/04/2014 11:26 AM, Martino Dell'Ambrogio wrote:
>> 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.
> There are many documented code execution opportunities (some of them 
> still rather subtle), so I find any arguments based on the existence 
> of a hypothetical secure procmailrc file generator not very convincing.

If you mean documented, then you can have a secure .procmailrc file 
generator by taking into account each possibility.
It's exactly what you do when you sanitize input in any software: you 
need a structure defining contexts, and you need to know how to 
encode/filter things to be safe and not get out of context.

If you mean undocumented (the phrase makes more sense), they all have to 
be either documented or, if they weren't the intention of the 
developers, they should be fixed.
In my opinion, in both cases, there is a security bug because there is 
unexpected execution.

> :0
> |echo code execution >/dev/tty
> :0
> * ?echo code execution >/dev/tty
> /dev/null
> … and so on.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4234 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.