Email based attack on University

classic Classic list List threaded Threaded
70 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Email based attack on University

tomas@tuxteam.de
On Fri, Oct 04, 2019 at 11:28:24AM +0100, Brian wrote:

> On Fri 04 Oct 2019 at 11:36:02 +0200, [hidden email] 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...

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.

Cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Email based attack on University

Brian
On Fri 04 Oct 2019 at 12:53:39 +0200, [hidden email] wrote:

> On Fri, Oct 04, 2019 at 11:28:24AM +0100, Brian wrote:
> > On Fri 04 Oct 2019 at 11:36:02 +0200, [hidden email] 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 | Threaded
Open this post in threaded view
|

Re: Email based attack on University

tomas@tuxteam.de
On Fri, Oct 04, 2019 at 12:24:14PM +0100, Brian wrote:
> On Fri 04 Oct 2019 at 12:53:39 +0200, [hidden email] wrote:
> > On Fri, Oct 04, 2019 at 11:28:24AM +0100, Brian wrote:

[...]

> > > That's *after* the mail is opened.
> >
> > That even complicates the challenge to define the meaning of "opening"
> > a mail [...] 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,

Nor am I. I just wanted to stress that those definitions vary wildly
with user's expectations: for some, displaying a HTML mail, with all
that entails is fundamental -- others rather prefer to see the HTML
source code and decide then what to do about it.

> but I can see what
> you are getting at (although I am not familiar with the "unintended
> consequences"). Still, a concrete example would help.

Well -- that thing I implicitly mentioned was EFAIL [1], which could
leak a PGP encrypted content by crafting a broken MIME/HTML container
around it. You could argue that the MIME parser is broken, but software
tends to be broken in various and creative ways always.

[...]

> > 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". :)

So we're in strong agreement here :)

Cheers
[1] https://en.wikipedia.org/wiki/EFAIL
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Email based attack on University

Curt
On 2019-10-04, <[hidden email]> <[hidden email]> wrote:
>
> Well -- that thing I implicitly mentioned was EFAIL [1], which could
> leak a PGP encrypted content by crafting a broken MIME/HTML container
> around it. You could argue that the MIME parser is broken, but software
> tends to be broken in various and creative ways always.
>

You both might be happy to know that senior ANU staff have currently
switched their MUAs to Oberon Mail, the reasoning being that the use of
such a butt-ugly, obsolete, non-RFC compliant email client that hasn't
been maintained in twenty years would strain the credulity of even the
canniest Middle Kingdom black hat, who wouldn't think of targeting
an app that all except one man somewhere in the Rockies considers
defunct.

This ruse has come to be known, in a punning variation on the well-known
phrase, as "security by obtusity."

On a lighter note, an unofficial source at MIT, that vibrant locus of
human and artificial intelligence, has informed the /New York Times/
that Minsky et. al. believed Epstein named his plane the "Lolita
Express" as a sincere tribute to Russian emigre literature.


--
"There are no foreign lands. It is the traveler only who is foreign."
-- Robert Louis Stevenson

Reply | Threaded
Open this post in threaded view
|

Re: Email based attack on University

Jonathan Dowland-5
In reply to this post by Keith Bainbridge-2
On Wed, Oct 02, 2019 at 07:03:59PM +1000, Keith Bainbridge wrote:
>I wonder if having /home on a 'noexec' partition would stop this
>attack, please?

I don't know specifically about this attack, but noexec is trivial to
circumvent. Here's three ways:

    bash -c "~/whatever"
    cp ~/whatever /tmp && /tmp/whatever
    /lib64/ld-linux-x86-64.so.2 ~/whatever

--
👱🏻 Jonathan Dowland
✎    [hidden email]
🔗 https://jmtd.net

Reply | Threaded
Open this post in threaded view
|

noexec mount option (was: Email based attack on University)

Sven Joachim
On 2019-10-04 16:22 +0100, Jonathan Dowland wrote:

> On Wed, Oct 02, 2019 at 07:03:59PM +1000, Keith Bainbridge wrote:
>> I wonder if having /home on a 'noexec' partition would stop this
>> attack, please?
>
> I don't know specifically about this attack, but noexec is trivial to
> circumvent.

Is it?  Running scripts in shell, Perl or Python is trivial since you
can just invoke the interpreter, but for binaries it is not so easy.

> Here's three ways:
>
>    bash -c "~/whatever"

Does not work, bash reports "Permission denied".

>    cp ~/whatever /tmp && /tmp/whatever

Obviously /tmp (and /var/tmp) must be mounted noexec as well if you want
to keep users from running arbitrary binaries.

>    /lib64/ld-linux-x86-64.so.2 ~/whatever

Does not work, "error while loading shared libraries:
/home/sven/whatever: failed to map segment from shared object".

I wonder how I would recover from an accidental
"mount -o remount,noexec /", even with a root shell still open.

Cheers,
       Sven

Reply | Threaded
Open this post in threaded view
|

Re: noexec mount option (was: Email based attack on University)

Greg Wooledge
On Fri, Oct 04, 2019 at 05:52:45PM +0200, Sven Joachim wrote:
> On 2019-10-04 16:22 +0100, Jonathan Dowland wrote:
> > Here's three ways:
> >
> >    bash -c "~/whatever"
>
> Does not work, bash reports "Permission denied".

The quotes shouldn't be there.

wooledg:~$ rm foo; echo 'echo hi' > foo; ls -l foo
-rw-r--r-- 1 wooledg voice 8 Oct  4 11:56 foo
wooledg:~$ bash ~/foo
hi

Reply | Threaded
Open this post in threaded view
|

Re: noexec mount option (was: Email based attack on University)

tomas@tuxteam.de
In reply to this post by Sven Joachim
On Fri, Oct 04, 2019 at 05:52:45PM +0200, Sven Joachim wrote:

> On 2019-10-04 16:22 +0100, Jonathan Dowland wrote:
>
> > On Wed, Oct 02, 2019 at 07:03:59PM +1000, Keith Bainbridge wrote:
> >> I wonder if having /home on a 'noexec' partition would stop this
> >> attack, please?
> >
> > I don't know specifically about this attack, but noexec is trivial to
> > circumvent.
>
> Is it?  Running scripts in shell, Perl or Python is trivial since you
> can just invoke the interpreter, but for binaries it is not so easy.
For binaries, the "interpreter" is just ld.so :-)

But as you state below, there seems to be some protection for that...

> > Here's three ways:
> >
> >    bash -c "~/whatever"
>
> Does not work, bash reports "Permission denied".

Interesting (I actually never tried). Noexec seems to do a tad
more than "just" ignoring the x bit. For bash, you can "fix"
that by feeding it ~/whatever through stdin (e.g. -s or something).

For a binary... I think ld.so wants to mmap it.

Cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: noexec mount option (was: Email based attack on University)

tomas@tuxteam.de
In reply to this post by Greg Wooledge
On Fri, Oct 04, 2019 at 11:56:44AM -0400, Greg Wooledge wrote:
> On Fri, Oct 04, 2019 at 05:52:45PM +0200, Sven Joachim wrote:
> > On 2019-10-04 16:22 +0100, Jonathan Dowland wrote:
> > > Here's three ways:
> > >
> > >    bash -c "~/whatever"
> >
> > Does not work, bash reports "Permission denied".
>
> The quotes shouldn't be there.

Right -- with the quotes, tilde isn't expanded, but...

> wooledg:~$ rm foo; echo 'echo hi' > foo; ls -l foo
> -rw-r--r-- 1 wooledg voice 8 Oct  4 11:56 foo
> wooledg:~$ bash ~/foo
> hi

... there's another thing: the -c shouldn't be there (you haven't it, OP
has it) either (that's the "permission denied" part)

cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: noexec mount option (was: Email based attack on University)

Greg Wooledge
On Fri, Oct 04, 2019 at 06:05:13PM +0200, [hidden email] wrote:

> On Fri, Oct 04, 2019 at 11:56:44AM -0400, Greg Wooledge wrote:
> > On Fri, Oct 04, 2019 at 05:52:45PM +0200, Sven Joachim wrote:
> > > On 2019-10-04 16:22 +0100, Jonathan Dowland wrote:
> > > > Here's three ways:
> > > >
> > > >    bash -c "~/whatever"
> > >
> > > Does not work, bash reports "Permission denied".
> >
> > The quotes shouldn't be there.
>
> Right -- with the quotes, tilde isn't expanded, but...
>
> > wooledg:~$ rm foo; echo 'echo hi' > foo; ls -l foo
> > -rw-r--r-- 1 wooledg voice 8 Oct  4 11:56 foo
> > wooledg:~$ bash ~/foo
> > hi
>
> ... there's another thing: the -c shouldn't be there (you haven't it, OP
> has it) either (that's the "permission denied" part)

Yes, you're absolutely correct.  Jonathan must be having a bad day.

Reply | Threaded
Open this post in threaded view
|

Re: noexec mount option (was: Email based attack on University)

Jonathan Dowland-5
On Fri Oct 4, 2019 at 12:10 PM Greg Wooledge wrote:
> Yes, you're absolutely correct.  Jonathan must be having a bad day.

I actually had a great day! But I am guilty of only testing the things I
wrote on a filesystem which wasn't actually mounted noexec. (the quotes,
I added by mistake in the email.)

I have happily left professional system administration behind (for
nearly five years now). The prevailing wisdom back then was as I have
written: noexec is not particularly secure, not hard to work around, and
not worth relying upon. Things may have changed in the intervening time,
(and indeed the ld trick seems not to work directly anymore)
but I still wouldn't bet my systems on it.

--
👱🏻 Jonathan Dowland
✎    [hidden email]
🔗 https://jmtd.net

Reply | Threaded
Open this post in threaded view
|

Re: Email based attack on University

Keith Bainbridge-3
In reply to this post by Jonathan Dowland-5
I'm still lurking here, but not sure what this suggestion means.

Please expand.


On 5/10/19 1:22 am, Jonathan Dowland wrote:

> On Wed, Oct 02, 2019 at 07:03:59PM +1000, Keith Bainbridge wrote:
>> I wonder if having /home on a 'noexec' partition would stop this
>> attack, please?
>
> I don't know specifically about this attack, but noexec is trivial to
> circumvent. Here's three ways:
>
>     bash -c "~/whatever"
>     cp ~/whatever /tmp && /tmp/whatever
>     /lib64/ld-linux-x86-64.so.2 ~/whatever
>


--
Keith Bainbridge
[hidden email]
+61 (0)447 667 468

Reply | Threaded
Open this post in threaded view
|

Re: Email based attack on University

tomas@tuxteam.de
On Sat, Oct 05, 2019 at 06:02:32PM +1000, Keith Bainbridge wrote:
> I'm still lurking here, but not sure what this suggestion means.
>
> Please expand.

I don't really understand your question. Otherwise I'd try to answer.

Could you be more explicit?

Cheers
-- tomás

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Email based attack on University

Curt
In reply to this post by Keith Bainbridge-3
On 2019-10-05, Keith Bainbridge <[hidden email]> wrote:

> I'm still lurking here, but not sure what this suggestion means.

He's not making one.

He's offering examples of the trivial circumvention of the noexec option
(but they all appear to be faulty for one reason or another).

> Please expand.

>
> On 5/10/19 1:22 am, Jonathan Dowland wrote:
>> On Wed, Oct 02, 2019 at 07:03:59PM +1000, Keith Bainbridge wrote:
>>> I wonder if having /home on a 'noexec' partition would stop this
>>> attack, please?
>>
>> I don't know specifically about this attack, but noexec is trivial to
>> circumvent. Here's three ways:
>>
>>     bash -c "~/whatever"
>>     cp ~/whatever /tmp && /tmp/whatever
>>     /lib64/ld-linux-x86-64.so.2 ~/whatever
>>
>
>


--
"There are no foreign lands. It is the traveler only who is foreign."
-- Robert Louis Stevenson

Reply | Threaded
Open this post in threaded view
|

Re: Email based attack on University

tomas@tuxteam.de
On Sat, Oct 05, 2019 at 09:39:06AM -0000, Curt wrote:
> On 2019-10-05, Keith Bainbridge <[hidden email]> wrote:
>
> > I'm still lurking here, but not sure what this suggestion means.
>
> He's not making one.
>
> He's offering examples of the trivial circumvention of the noexec option
> (but they all appear to be faulty for one reason or another).

OK. Calculemus, as Leibnitz used to say. At least one of them isn't faulty.
Here is a session transcript (interspersed with comments by me, prefixed
with '#'), which shows that method 1 actually works (I wouldn't have
expected otherwise):

  # Make two directories. The one will be mounted onto the other:
  tomas@trotzki:~$ mkdir foo bar
  # Create a shell script in foo, make it executable, and run it...
  tomas@trotzki:~$ echo -e '#!/bin/sh\necho hello, world' > foo/hello
  tomas@trotzki:~$ chmod ugo+x foo/hello
  tomas@trotzki:~$ foo/hello
  hello, world
  # OK, that works. Now mount bind foo onto bar...
  tomas@trotzki:~$ sudo mount --bind foo bar
  [sudo] password for tomas:
  # and remount it noexec
  # (NB this two-step process seems needed, I failed trying
  # to pass the noexec option to the first bind-mount.
  # Possibly PEBKAC)
  tomas@trotzki:~$ sudo mount -oremount,bind,noexec foo bar
  # What do we have?
  tomas@trotzki:~$ ls -al foo bar
  bar:
  total 20
  drwxr-xr-x   2 tomas tomas  4096 Oct  5 11:53 .
  drwxr-x--x 228 tomas tomas 12288 Oct  5 11:53 ..
  -rwxr-xr-x   1 tomas tomas    28 Oct  5 11:53 hello
 
  foo:
  total 20
  drwxr-xr-x   2 tomas tomas  4096 Oct  5 11:53 .
  drwxr-x--x 228 tomas tomas 12288 Oct  5 11:53 ..
  -rwxr-xr-x   1 tomas tomas    28 Oct  5 11:53 hello
  # Strangely enough, bar/hello shows as executable, although
  # we clearly ordered noexec. WTF? But...
  #
  # ...noexec works as advertised!
  tomas@trotzki:~$ bar/hello
  bash: bar/hello: Permission denied
  # But we can bypass it with Jonathan's first method:
  tomas@trotzki:~$ /bin/sh bar/hello
  hello, world


The other two methods are left as an exercise to the reader.

I'm pretty confident that they'll work. Firstly, Jonathan
knows his stuff. Secondly, for each method, for the interpreter
(be it the shell, be it ld.so), the thing coming from the
"noexec" file system are just data: the interpreter is what
is being executed (and that is outside of the noexec mount).
The system can't know that the interpreter is going to "pass
the buck".

Cheers
-- tomás

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Email based attack on University

Curt
On 2019-10-05, <[hidden email]> <[hidden email]> wrote:
>
>   # But we can bypass it with Jonathan's first method:
>   tomas@trotzki:~$ /bin/sh bar/hello
>   hello, world
>

I meant

 bash -c "~/whatever"

appears to be faulty (for one reason or another.

--
"There are no foreign lands. It is the traveler only who is foreign."
-- Robert Louis Stevenson

Reply | Threaded
Open this post in threaded view
|

Re: Email based attack on University

tomas@tuxteam.de
On Sat, Oct 05, 2019 at 12:14:28PM -0000, Curt wrote:

> On 2019-10-05, <[hidden email]> <[hidden email]> wrote:
> >
> >   # But we can bypass it with Jonathan's first method:
> >   tomas@trotzki:~$ /bin/sh bar/hello
> >   hello, world
> >
>
> I meant
>
>  bash -c "~/whatever"
>
> appears to be faulty (for one reason or another.
I see. Yes, it is "faulty" because "-c" means to bash "invoke the
following argument as a command", and this precisely fails... due
to noexec. Without the "-c" it just means "interpret that file as
(ba)sh source", which doesn't care about the file's executable status.

Cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Email based attack on University

Keith Bainbridge-3
In reply to this post by Jonathan Dowland-5
On 5/10/19 1:22 am, Jonathan Dowland wrote:

> On Wed, Oct 02, 2019 at 07:03:59PM +1000, Keith Bainbridge wrote:
>> I wonder if having /home on a 'noexec' partition would stop this
>> attack, please?
>
> I don't know specifically about this attack, but noexec is trivial to
> circumvent. Here's three ways:
>
>     bash -c "~/whatever"
>     cp ~/whatever /tmp && /tmp/whatever
>     /lib64/ld-linux-x86-64.so.2 ~/whatever
>

Well I think the bash line means that the bash command uses ~/whatever
as data (which it could do without the x switch?) like any program does
with data files. I wasn't aware of this. I read later the the -c is not
necessary, and wonder if the "s are necessary.


I see that cp to /tmp will get around the noexec. Am now wondering how I
can use that process to my advantage elsewhere.


The 3rd suggestion is still a mystery.


Then to get away from sudo.   But su -c doesn't work the way I expected.
  Back soon

Thanks to all who have contributed to an enlightening discussion.



--
Keith Bainbridge

[hidden email]

+61 (0)447 667 468

Reply | Threaded
Open this post in threaded view
|

Re: Email based attack on University

andy smith-10
In reply to this post by rhkramer
Hello,

On Thu, Oct 03, 2019 at 08:05:27AM -0400, [hidden email] 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 | Threaded
Open this post in threaded view
|

Re: Email based attack on University

Greg Wooledge
In reply to this post by Curt
On Sat, Oct 05, 2019 at 12:14:28PM -0000, Curt wrote:
> On 2019-10-05, <[hidden email]> <[hidden email]> wrote:
> I meant
>
>  bash -c "~/whatever"
>
> appears to be faulty (for one reason or another.

For two reasons.

First, the -c.  That's been explained already.
Second, the quotes around the tilde cause tilde expansion not to be done.

1234