Upstream has issued an advisory today (February 15):
The issue is fixed in version 1.9.1 and the patch to fix it is included in the message above.
Cauldron is likely affected too as it appears to be a git snapshot with an invalid version.
Debian has issued an advisory today (May 9):
It fixes several CVEs. I'm not sure if they're fixed in Cauldron or not.
I've pushed the latest git version in cauldron and asked for a freeze push.
Will update mga5 as a follow-up.
I'm unsure why there is a version mismatch now. When I imported it the versin was 2.6 somehow (at least for ytnef itself or the lib), and now it appears they use 1.9.x. We should work on a fix sometime.
Ok, I found the issue.
I got ytnef originally from sf.net: https://sourceforge.net/projects/ytnef/files/libytnef/ and they were using 2.6 as a version for the tool and 1.5 for the lib.
In mga6 the update was done using the github repo which is up to date but seems ti have adopted the lib version going forward, not the tool version. Thus our mismatch.
The sf.net version isn't maintained, so we would have to push that new ytnef pckage into 5 to solve the issue, but I'm unsure on how to do that correctly. (the latest git version from cauldron build fine on mga5 BTW).
So, after looking at Debian, Jessie is using the same version as us in mga5 so I shamelessly stole their patches to apply it successfully to our mga5 version. Push to updates_testing and advisory written.
Bruno, thanks for the update. Just a couple of things I noticed:
1) the tarball in mga5 is in SVN instead of the binrepo
2) you could fix the version in Cauldron by adding an Epoch
3) you should always post the advisory to the bug as well
4) the advisory in SVN is insufficient
QA team, please replace the advisory with the following:
Updated libytnef packages fix security vulnerabilities:
Several issues were discovered in libytnef, a library used to decode
application/ms-tnef e-mail attachments. Multiple heap overflows, out-of-bound
writes and reads, NULL pointer dereferences and infinite loops could be
exploited by tricking a user into opening a maliciously crafted winmail.dat
file (CVE-2017-6298, CVE-2017-6299, CVE-2017-6300, CVE-2017-6301,
CVE-2017-6302, CVE-2017-6303, CVE-2017-6304, CVE-2017-6305, CVE-2017-6306,
CVE-2017-6800, CVE-2017-6801, CVE-2017-6802).
Advisory updated in svn