Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 565222 - [Auditing] mail-client/claws-mail-3.9.0 trusts server(?)-provided Message-Id to deduplicate messages
Summary: [Auditing] mail-client/claws-mail-3.9.0 trusts server(?)-provided Message-Id ...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Auditing (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security Audit Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-09 12:17 UTC by Fedja Beader
Modified: 2018-03-21 20:23 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Part of the chat with upstream (chat-excerp,1.88 KB, text/plain)
2015-11-09 12:30 UTC, Fedja Beader
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fedja Beader 2015-11-09 12:17:19 UTC
From what I see in src/folderutils.c, the gint folderutils_delete_duplicates
function uses server-provided Message-Id header field to deduplicate messages.
It does not do a byte-by-byte comparison to confirm a duplicate nor does it
use checksums of its own.

This could allow the server/sender to craft a special Message-Id that would
result in a previously stored message being wrongly moved to thrash (and
deleted afterwards).

This function looks the same in claws-mail-3.13.0 as well.
Comment 1 Fedja Beader 2015-11-09 12:30:47 UTC
Created attachment 416362 [details]
Part of the chat with upstream

Upstream #claws@freenode says there is nothing wrong with this (!?!?!)
Comment 2 Fedja Beader 2018-03-21 14:35:38 UTC
I request for the package to be masked if noone is wiling to fix this. Perhaps this will teach upstream about what is not OK.
Comment 3 Kristian Fiskerstrand (RETIRED) gentoo-dev 2018-03-21 15:14:39 UTC
Seems package maintainer is not added in this report to begin with, so adding now.

Will the deduplication actually delete the existing message and not the newly incoming one?
Comment 4 Fedja Beader 2018-03-21 15:23:33 UTC
I do not know, in any case it would be wrong as they are different messages.
Comment 5 Lars Wendler (Polynomial-C) gentoo-dev 2018-03-21 15:26:45 UTC
(In reply to Fedja Beader from comment #2)
> I request for the package to be masked if noone is wiling to fix this.
> Perhaps this will teach upstream about what is not OK.

I doubt upstream would feel taught by such a measure.
Did you file a bug report upstream? Having only some IRC conversation might not be the best approach to put upstream's attention on this issue.

To be clear, I see your point and I do agree that this can be dangerous but I won't mask the package because of this. We should rather make this public and perhaps get some CVE ID for this in order to force some reaction from upstream. The more public pressure the better.
Comment 6 Kristian Fiskerstrand (RETIRED) gentoo-dev 2018-03-21 20:19:32 UTC
(In reply to Lars Wendler (Polynomial-C) from comment #5)
> (In reply to Fedja Beader from comment #2)
> > I request for the package to be masked if noone is wiling to fix this.
> > Perhaps this will teach upstream about what is not OK.
> 
> I doubt upstream would feel taught by such a measure.
> Did you file a bug report upstream? Having only some IRC conversation might
> not be the best approach to put upstream's attention on this issue.
> 
> To be clear, I see your point and I do agree that this can be dangerous but
> I won't mask the package because of this. We should rather make this public
> and perhaps get some CVE ID for this in order to force some reaction from
> upstream. The more public pressure the better.

Discussion of CVE might be premature at this point, as I'm not sure if it crosses any security boundry. For the same reason I'm making the report public for discussion.

In particular I'd say it makes a different if only new message is rejected vs existing one. What does other MUAs do in similar situations?
Comment 7 Kristian Fiskerstrand (RETIRED) gentoo-dev 2018-03-21 20:23:11 UTC
Since public, adding project alias