[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Email based attack on University



Nicholas Geovanis, on 2019-10-02:
> Henning Follmann, on 2019-10-02:
> > On Wed, Oct 02, 2019 at 09:27:37AM -0400, Carl Fink wrote:
> > > On Wed, Oct 02, 2019 at 08:41:11AM -0400, Henning Follmann wrote:
> > > > only PDF/A is OK every other PDF, throw it out.
> > > > No multimedia (movies, mp3).
> > >
> > > Really? MP3? Paranoid much?
> >
> > Well, maybe.
> > OTOH these massive exploits these days were considered very unlikely some
> > time ago. And a vectors in remains a vector in, and most likely becomes
> > a common attack vector. Your point because it is not widely used _now_,
> > it is safe, is just ridiculous.
>
> True enough but with the following difference:  By
> specification, to the best of my amateur knowledge, the MP3
> format does not permit executable content. Whereas Word and PDF
> files do.

I don't believe MP3 allows executable code by specifications
either, so shouldn't the PNG image format.  But think of DSA
4435 which affected libpng earlier this year.  When the OS
library for handling multimedia has flaws, if an HTML email
embeds a specifically crafted PNG image inlined in the content,
then you wouldn't even have to hit the “preview” button to be
screwed:

	https://www.debian.org/security/2019/dsa-4435

tomás, on 2019-10-02:
> Specifically for MP3 there seem to have been player vulnerabilities,
> including some of the "code execution" flavour.
>
> IOW a vulnerable renderer is just some kind of (Rube-Goldbergian)
> interpreter :-)

Yup, that's the idea.  Even if the format is clean, there might
be bugs in libraries interpreting that format.  Kids, keep your
systems up to date!


Going back to the main topic leveraged by Keith, setting
apparmor(7) policies /may/ be a bit more helpful than doing a
mount noexec in these situations, if I understood properly its
purpose.  The nice thing is that Debian does it for you!

MUAs like Thunderbird come with what I believe would be
appropriate Apparmor default settings; although having a look
inside /etc/apparmor.d/usr.bin.thunderbird shows a lot of work
TODO left.  It should prevent effects of such attacks by
limiting the area of action of the whole thunderbird process,
and its children processes I would expect, to only a fraction of
the resources available on the machine, in case some operation
on untrusted data goes rogue[1].

[1] although, the apparmor profile does give a lot of margin to
    the /usr/bin/thunderbird process relative to the home
    directory, primarily to not break the “Save as...” button,
    so it depends on what the attacker will target.

Kind Regards,  :)
-- 
Étienne Mollier <etienne.mollier@mailoo.org>
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d


Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: