Page MenuHome GnuPG

GpgOL: MIME parameters provided with "*=" instead of just "=" are not parsed - Resulting in hidden attachments
Closed, ResolvedPublic

Description

I actually need to look this up which RFC specifies this but apparently AppleMail sends out Mails with such MIME headers and Outlook seems to parse them natively but GpgOL ignores them.

I don't have the full example mails but I will try to obtain some, currently I only have a detailed log where this is visible.

--Apple-Mail=_81A3F461-7DD3-494B-AFB5-14F1940C7C45'

Content-Disposition: inline;
	filename*=utf-8''Foo%C2%ADfoto%202023%2D07%2D10%20um%20xzy.png
Content-Type: image/png;
	name*=utf-8''Foo%C2%ADfoto%202023%2D07%2D10%20um%20xyz.png;
	x-mac-hide-extension=yes;
	x-unix-mode=0644
Content-Transfer-Encoding: base64

And even weirder, this can go across multiple parameters with continuation parameters apparently.

--Apple-Mail=_209E8ECB-4492-4AC5-A0DD-6D82E8B59053'
Content-Disposition: inline;'
	filename*0="Some long filename without any special characters but just a very";
long filename that is continued here";
	filename*1=and then in a second parameter.pdf;

Content-Type: application/pdf;
	name*0="Some long filename without any special characters but just a very";
long filename that is continued here";
	name*1=and then in a second parameter.pdf;
	x-unix-mode=0644

To be honest I have never seen such a way to transfer parameters but KMime and our new MIMETreeparser in T6199 can probably handle them but our old and trusty RFC822parse code in GpgOL needs to be adjusted.

This later leads to:

07:41:40/14840/ERROR/mail.cpp:add_attachments_o: Ignoring attachment without display name.
07:41:40/14840/ERROR/mail.cpp:add_attachments_o: Ignoring attachment without display name.

Here I think we should change the error handling to just add it as "unknown_attachment.dat" in such a case so that users have a chance to recover the attachments at all.

Prio high, because this might be a new version of AppleMail and we are just starting to see this. And to users it looks like a crypto related "Data loss" issue.

Revisions and Commits

Event Timeline

aheinecke created this task.

To be honest I have never seen such a way to transfer parameters but KMime and our new MIMETreeparser in T6199 can probably handle them but our old and trusty RFC822parse code in GpgOL needs to be adjusted.

Can confirm KMime handle this correctly :)

There is a test case for this in KMime https://invent.kde.org/pim/kmime/-/blob/master/autotests/data/mails/outlook-attachment.mbox which render correctly in the new mime tree parser ;) The test case is 9 years old but this syntax seems to be only used when the filename is using utf8 characters which might explain why this issue only appear now.

I can try to take a look at GpgOL and fix it, unless the short term plan is to use the new mimetreeparser anyway

Hi Carl,
yes I saw that test case. Btw. I don't really think that this comes from Outlook itself otherwise I would have seen this much earlier, the current MIME Parser in our Outlook Plugin is about 8 years old. Currently this comes through some kind of AppleMail (server?) application to the customer.

While I find the

name*=....

Irritating and would like to know how this is called and where the RFC for this is, I find the second case more difficult to implement:

name*0="Some long filename without any special characters but just a very";
long filename that is continued here";
	name*1=and then in a second parameter.pdf;

And for that I don't think KMIME has support currently.

I have the example mails from the customer in the binary outlook format. I will try to extract the MIME structure for testing and then create my own test mail which we can then add to KMIME / MTP, I would like to have them signed though. So I will probably hack my GpgOL version to produce such mails. When I have the examples I will attach them here.

For the c++ GpgOL the mimetreeparser is not an option. Its plain C++/C without Qt. We are currently basically using GnuPGs own https://dev.gnupg.org/source/gnupg/browse/master/tools/rfc822parse.c so a fix needs to go there. And TBH. I currently I have no idea how I can fit the second case in the architecture 🤔

name*0="foo"
name*1="bar.pdf"

In a way that I can later just rfc822parse_query_parameter("name") there.

I won't go so far to try to fully implement RFC2231 in the rfc822parse. But I have an idea how to implement this in a secure and robust manner in rfc822parse without touching the parser or the token stuff. My idea is to treat them as seperate TOKEN and then combine them in query parameter just for name and filename values.

Something like pseudocode:

if (param == name || param == filename)
  result = check(param);

if (result.empty())
  result = check(param + '*');

if (result.empty())
{
int i = 0;
do {
   foo = check(param + '*' + i);
   result += foo;
} while (!foo.empty() && i < 10)

Assuming that "check" already does the rfc2047 parse for the different parameter encodings.

aheinecke changed the task status from Open to Testing.Jul 31 2023, 3:31 PM

This works now for me and all the examples I have for the customer. With https://dev.gnupg.org/rO0fc4b87a946dd634d4b61d4e8cb0ad6164faa83c it looks to me in KMail like KMime might handle the transition between different encodings / languages not correctly in continued parameters.

aheinecke moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 31 2023, 3:31 PM
aheinecke mentioned this in Unknown Object (Event).Aug 7 2023, 8:56 AM

This can be resolved I tested this myself and gave a beta to the affected customer which also worked for them

ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Nov 15 2023, 11:09 AM