Re: Email based attack on University
Hello,
On Thu, Oct 03, 2019 at 08:05:27AM -0400, rhkramer@gmail.com wrote:
> On Thursday, October 03, 2019 06:23:20 AM Andrew McGlashan wrote:
> > There have been numerous bugs with LookOut (otherwise known as
> > Outlook), running scripts and having other vulnerabilities due to
> > preview pane being open.
[…]
> I suppose then, that the same vulnerabilities that you allude to
> are present in (at least older versions of) kmail?
I think it's important to realise that large organisations tend to
enforce a monoculture of office productivity and email applications.
These tend to be large and complex software packages which harbour
many bugs and opportunities for security compromise.
There have been many incidents of the large office suites having
flaws that execute content, even sometimes without any user action
beyond some sort of email preview. This will continue to happen.
Web-based email may even have a better security story, as the
browser security model has at least had a lot of thought applied to
it over time as opposed to standalone large executables.
Realistically therefore, if there was an enterprise mandating a
Linux desktop and mail package to all its users, we probably would
still continue to find security bugs in that email application that
did not rely on the user following a link or maybe not even
explicitly opening a media attachment. You would have to assume such
bugs are present, though possibly as yet undiscovered. Every large
monoculture installation is waiting for their own specific 0-day
exploit.
As previously noted in this thread, blocking execution from the
/home filesystem tree would not help here as in this case it would
either be the email application or a media handler it launches doing
the executing.
There are other security features available in Linux, such as
SELinux and AppArmor, which seek to limit the privileges of
binaries. Conceivably a rigorous use of these could really lock down
a desktop and productivity suite to be much harder to break into.
For example, a media viewer/player could be restricted from writing
to the filesystem or making network calls.
My experience is that very few organisations are willing to spend
the time to define such policies, and in truth I rarely do either,
much beyond what comes as default with the OS. Some even disable
them entirely. But at least the feature is there, and that's the
sort of thing that would be worth exploring if someone is seriously
wanting to lock down this sort of big desktop deployment.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Reply to: