Re: Email based attack on University
On Fri 04 Oct 2019 at 12:53:39 +0200, tomas@tuxteam.de wrote:
> On Fri, Oct 04, 2019 at 11:28:24AM +0100, Brian wrote:
> > On Fri 04 Oct 2019 at 11:36:02 +0200, tomas@tuxteam.de wrote:
> >
> > > On Fri, Oct 04, 2019 at 10:11:52AM +0100, Brian wrote:
> > >
> > > [...]
> > >
> > > > > Yes, "our" security story is way better than theirs [...]
> > >
> > > [edit: I forgot to put "theirs" in quotes]
> > >
> > > > A single reliable, well-documented and repeatable example of a problem
> > > > caused by pressing enter or clicking on a mail would go a long way to
> > > > wipe the smile of my face.
> > >
> > > That's not my goal, anyway. Smiles are like sunshine, so why would
> > > I want to wipe them?
> >
> > :)
> >
> > > But still: every "code execution" escape in your MUA paired with a
> > > privilege escalation (or some social-engineering equivalent like
> > > "click here to install shiny package) is an example. And "we" have
> > > had bunches of those.
> >
> > That's *after* the mail is opened.
>
> That even complicates the challenge to define the meaning of "opening"
> a mail a tad more: render just the "text/plain" MIME parts? Or also
> the "application/xml"? And so on. Even unwrapping the MIME seems to
> have unintended consequences, as we witnessed not long ago...
I don't think I am the one to meet this challenge, but I can see what
you are getting at (although I am not familiar with the "unintended
consequences"). Still, a concrete example would help.
> And to those in the belief that plain text is something else, I've
> a war story of a prank we used to play back in the 90ies which
> consisted in re-programming a terminal's answer to the control
> code ENQ (CTRL-E, 0x05) to contain an ENQ itself. Coupled with the
> detail that a UNIX machine back then sent an ENQ to the terminal
> to find out what it is and initialize the termcap settings, lots
> of hilarity ensued. Really, we laughed tears :-D
>
> Granted, plain text renderers are lightweight in comparison to the
> rest of the world, but they ain't zero-fat. It's turtles all the
> way down.
>
> > > > User files are not necessary for the health of the system.
> > >
> > > But they're the those which really count: after all, I can reproduce
> > > the system easily.
> >
> > The integrity of a user's files is underpinned by the integrity of
> > the system [...]
>
> Let's agree that the system's integrity is a (nearly) necessary
> condition to the user's data integrity -- but by far not a sufficient
> condition.
Let's do that. I'll not even argue with "nearly". :)
--
Brian.
Reply to: