Signing Oracles with kmail

[Albert Astals Cid]

El dimarts, 14 de maig de 2019, a les 0:28:05 CEST, Sandro Knauß va escriure:
> Hey,
>  
> > Should we release our own advisory? Or at this point that this is all public
> > just let it be?
> 
> I don't know, when an own advisory is used in past. 

We've released advisories when someone notified privately us of issues and we fixed them
   https://kde.org/info/security/
My main issue here is that the bug has been public so it's not like saying "here we have a bug" is something new since the bug is already in the open "and relatively famous"

> At least Debian already 
> pinged me  (as mantainer, that upstream(KDE) fixed the issue. 
> 
> So distribution get the information, that we fixed the issue. But I think the 
> information on 404698 is not good enough to understand what needs to be done 
> to fix the CVE.
> 
> That is what I would write:
> 
> To fix the bug properly you should to backport the complete CVE-2019-10732 
> branch.
> 
> git diff a49182427bbf28142a8b2c9df73a905950b011d6..CVE-2019-10732
> 
> Don't get shocked about the amount of changes, most of the stuff is "just" 
> autotest. A minimal fix would just update templateparser/src/ and 
> mimetreeparser/src/. But I would recommend also update the autotests. 
> Especially when backporting you may end up updating the patches minimally and 
> autotests should help you make sure that you backport it properly.

Right so it seems that then maybe it would make sense to write something? Maybe not something as formal as an advisory listed in https://kde.org/info/security/ but maybe email the kde-packager list? https://mail.kde.org/mailman/listinfo/kde-packager

> 
> 
> > > But the paper [1] not
> > > only showed how to be a Decryption Oracles also showed a way to be a
> > > Signing Oracles by using html stuff. See appendix B. Does anyone looked
> > > at the blinding/conditional options and if we can improve the situation?
> > 
> > I don't understand appendix B. Is it only a list of CSS stuff KMail
> > supports?
> 
> yes this is only a list of CSS features, but these features are shown, that 
> attacks can trick the display of an mail (6, page 9). Also kmail may just not 
> marked as vulnerable, as they only tested the default settings, where HTML 
> support is disabled. kmail could/should considering to improve the 
> countermeasures (8.2, page 14):
> 
> "Conditional CSS makes it easy for an attacker to hide certain text within a 
> signed message while showing different text."
> 
> -> do we sanitizing those stuff? are there tests for it?
> As I don't know currently how we select the CSS features, that are 
> whitelisted/blacklisted. I can't say if it is feasible to control this. Or if 
> we should use the hammer solution and disable HTML replies:

I don't think it makes sense for us to become a HTML/CSS parser to be able to disable features on replies of HTML email. It'll be a game of wack-a-mole, you basically need a full fledged web engine parser to do that.

> "They must not sign any quoted HTML/CSS input from the original message [while 
> creating a reply], so that they cannot be misused as signing oracles."

That's an option, not doing HTML replies on emails that are signed? or at least warning the user? After all i think the "uses signing", the "uses HTML emails" and the "uses KMail" groups don't really intersect much.

> 
> What are your thoughts about this?

I think we need Laurent to chime on this, but AFAIU we use QtWebEngine and it doesn't really give us much control about things.

Cheers,
  Albert

> 
> sandro