On 11/01/2017 01:24 PM, Ian Jackson wrote:
> The lack of a useable exception mechanism, with a sensible UI, is a
> big problem though. Ideally you would ask the user something like
>
> This { email attachment | web download } is a DESCRIPTION. The
> program for this is NAME but it has not been audited for security.
> If you're not expecting this kind of file then you probably didn't
> want to open it - it might be malware.
>
> [[ Don't open ]]
> [ Open this once ]
> [ Always open these kinds of files without asking ]
>
> You can change your mind about "always" by going to "settings"
> / "security" in the { Thunderbird | Firefox } menu.
Designing UIs that are not just ignored by the users are hard, though,
while sandboxes give you some defense in depth. For instance opening a
.pdf file with Chrom(e|ium) gives you a sandboxed PDF renderer (PDFium).
Plus it's not like you can present a super useful description. Go by
file extension? Go by included MIME type? (Hello,
application/octet-stream.) Go by whatever the target application sniffs
it to be[1]? And of course never try to obtain a locally generated
thumbnail of untrusted content.
In the end you'd just show that warning half of the time and users are
trained to just click the button without reading the box because users
are bad at reading.
Kind regards
Philipp Kern
[1]
https://scarybeastsecurity.blogspot.de/2016/11/0day-exploit-compromising-linux-desktop.html
Attachment:
signature.asc
Description: OpenPGP digital signature