Re: Security findings

Matthias Andree via Mutt-dev <[email protected]>
Newsgroups gmane.mail.mutt.devel
Message-ID <[email protected]>
Am 18.04.26 um 17:42 schrieb Kevin J. McCarthy:
> On Sat, Apr 18, 2026 at 09:27:59PM +0800, Kevin J. McCarthy wrote:
>> On Sat, Apr 18, 2026 at 02:14:53PM +0200, evilrabbit via Mutt-dev wrote:
>>> Please find below a number of confirmed security findings in the 
>>> mutt client.
>>> None of these are significant but should probably be addressed.
>>
>> Thanks, I will start taking a look at these tomorrow.
>
> Just as a note to the other devs.  I started looking at some of these
> tonight.
>
> I've pushed up to gitlab some (very quickly made) branches:
>   kevin/stable-security-01        Fix NULL dereference in 
> show_sig_summary().
>   kevin/stable-security-02        Fix infinite loop in gpgme 
> data_object_to_stream().
>   kevin/stable-security-05        Fix IMAP auth_crm MD5 digest of 
> secret to use memcpy().
>   kevin/stable-security-06        Fix imap_auth_gss() security_level 
> size.
>   kevin/stable-security-07        Check for embedded nul in 
> url_pct_decode().
>   kevin/stable-security-08        Abort if there are DNS entries but 
> don't match.
>
> These still need to be cleaned up, verified, and tested.
>
> For #8 I need to check the RFC myself, so if anyone with OpenSSL code 
> experience wants to confirm that would be welcome.
>
> For #3, I'm not sure if we really need to fix this.
>
> For #4, I welcome input from others about this.  Randomizers are not 
> my thing.  If the algorithm is insufficient for what we are using it 
> for, then I welcome help in implementing something better.
>
Re #8, it's been a while since I'd read the standards (RFC 5280 and 
6125), but what's in the OP matches my recollection. I find the check 
plausible and correct. There might be improperly issued certificates 
afoot (I've also seen even some CA issue certificates with serial number 
0, which wolfSSL would reject) so with that change merged, mutt starts 
rejecting certificates - that don't repeat or pattern match the CN in 
the SAN - that it used to accept, so this should be announced as a 
"breaking change" in the NEWS.

Also, I wonder if I'd personally want to repeat the match_found=0 
initialization redundantly so I have a safety net if I were to edit the 
code later. Might trigger compiler warnings though because the compiler 
can prove it's redundant.

-- 

Matthias Andree
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.