►
From YouTube: Use SES to Reduce Supply Chain Risk (English)
Description
On 15/03/2021, Mark S. Miller gave a lecture about SES (Secure EcmaScript) during a JavaScript Israel virtual Meetup.
Abstract:
Use SES (Secure EcmaScript) to run third-party JavaScript code safely inside featherweight compartments.
SES is a TC39 proposal, a shim used in production, a standalone implementation for embedded systems as specified by TC53, and a language for writing blockchain-based smart contracts.
SES enforces that subsequent code stays within object-capability security rules. Reduce supply chain risk by giving each package the least authority it needs to do its legitimate job.
Experience at Google, Salesforce, Agoric, MetaMask, Cosmos, Moddable, and Node confirm that much existing JavaScript code, not written to run under SES, nevertheless runs compatibly under SES within these security constraints.
Event Page: https://www.meetup.com/JavaScript-Israel/events/276415412/
Thanks to our Gold sponsors : Trax
Join the group:
http://www.meetup.com/JavaScript-Israel
A
A
Any
discussion
of
supply
chain
risk
should
start
with
the
event
stream
incident.
In
the
event
stream
incident,
the
maintainer
of
an
npm
package
named
event
stream.
Just
a
general
purpose.
Low-Level
utility
published
an
upgrade
of
the
package
that
contained
a
targeted
attack
on
the
bitpay
cryptographic
wallet.
A
A
A
What
we
mean
by
red
is
a
red
versus
green
is
a
measure
of
the
risk
that
you
have
from
the
package
in
normal
javascript
anything
can
damage
everything.
Anything
everything
is
fully
vulnerable
to
anything
and
that's
why
all
of
the
dots
would
be
read.
Metamask
uses
ses
to
partition
risk
to
give
each
package
only
the
least
authority
needed
follow
the
principle
of
least
authority
of
give
each
package
only
the
authority.
It
needs
to
do
its
proper
job.
A
However,
some
packages
still
need
significant
authority
to
do
the
proper
job.
Most
of
it's
green.
Most
packages
need
very,
very
little
authority
and
can
be
verified
to
need
little
authority
by
static
analysis,
but
the
ones
that
are
red
are
the
ones
that
still
need
a
dangerous
amount
of
authority
to
do
their
job.
A
A
good
example
is
the
attack
of
prototype
poisoning
the
primordial
objects.
Are
the
objects
like
array.prototype
or
the
array.prototype.push
method
that
all
the
arrays
inherit
that
are
the
primordials
are
the
ones
that
exist
before
code
starts
running
and
in
normal
javascript.
All
of
the
primordial
objects
are
fully
mutable,
so
any
code
can,
for
example,
replace
the
array
prototype,
push
method,
changing
the
behavior
of
all
of
the
arrays
created
by
all
of
the
other
packages
that
have
been
linked
together.
A
A
The
other
source
of
attack
is
through
the
shared
global
object.
All
the
code
linked
together
all
share
one
global
object,
and
the
global
object
is
also
the
one
that
contains
the
host
objects,
like
the
document
object
in
the
browser
all
of
the
each
host
each
context
that
javascript
runs
in
provides
some
powerful
global
objects
that
provide
the
ability
to
do
io
to
the
outside
world
and
because
everything
runs
in
the
global
scope.
Everything
has
access
to
all
of
that.
A
Power
so
javascript,
so
scs
introduces
an
abstraction
called
the
compartment.
The
compartment
creates
separate
global
objects
and
separate
global
scopes
inside
the
overall
javascript
system,
and
what
we,
what
we
in
fact
do
is
we
run
each
package
in
its
own
compartment
and
we
endow
that
compartment
with
only
the
globals
that
that
package
needs
so
over.
Here
we
have
a
compartment
c1
that
is
unendowed
with
anything
and
the
expression
x,
plus
y
evaluated.
There
just
gives
a
reference
error,
because
there
are
no
x
and
y
globals.
A
A
However,
even
strict
mode
has
these
problems
that
make
everything
vulnerable
to
anything.
All
of
the
primordial
objects
are
mutable.
There
are
these
host
objects
that
are
accessible
to
ed,
to
everything,
because
they're
bound
to
global
variables
and
there's
that
per
realm
global
object.
Everything
sharing
one
big
global
object.
A
A
And
the
security
properties
are
sufficiently
strong
that
they
even
provide
some
degree
of
mitigation,
some
degree
of
defense
against
side
channels.
It's
not
the
the
main
target.
The
main
target
is
integrity,
is
reducing
authority
ability
to
cause
effects,
but
the
observation
about
side
channels
is
all
these
side
channels
that
people
worry
about,
including
meltdown
and
spectre,
all
rely
on
the
untrusted
code,
the
attacker
code
being
able
to
measure
duration,
those
green
dots,
visibly
don't
most
of
them,
don't
need
any
of
the
objects
that
would
enable
them
to
measure
duration.
A
A
A
It's
easy
for
that
code
to
read
the
side
channel
and
thereby
figure
out
the
secret
with
the
same
page.
If
you
turn
off
the
power
of
the
date
object,
so
the
data
object
is
no
longer
providing
the
ability
to
measure
duration
still
provides
the
ability
to
represent
dates
to
parse
dates,
to
print
dates.
All
of
that,
then,
we
challenge
you
to
write
code
in
the
presence
of
this
incredibly
loud,
easy
to
read
side
channel.
If
you
can
measure
duration,
we
challenge
you
to
write
code
that
will
nevertheless
figure
out
what
the
secret.
B
A
The
c3
compartment
is
created
with
no
endowments
it.
The
compartment
by
default
has
almost
all
of
javascript
has
all
the
global
variables
defined
by
javascript
has
all
essentially
all
of
the
properties
and
all
of
the
methods
defined
by
standard
javascript,
which
is
why
old
code
still
works,
but
the
date
object
is
a
safe.
That's
provided
by
default
is
a
safe
variant
of
the
data
object
where
date
dot
now
gives
nan.
A
The
graph
you
see
here
is
a
sample
as
a
representative
sample
of
some
of
the
objects
in
the
primordial
javascript
heap
this
and
the
arrows
here
are
how
they're,
wired
together
the
vertical
arrow
is
inherits
from,
let's,
first
of
all,
just
remove
the
obvious
inherits
from
from
the
graph
all
functions
inherit
from
function.prototype.
So
we
don't
need
that.
A
A
A
A
A
A
The
global
object
itself
is
dangerous,
because
the
global
object
is
dangerous.
The
evaluators
that
evaluate
code
in
the
in
the
scope
of
that
global
object
are
dangerous,
because
now
that
code
can
reach
the
dangerous
objects
like
date
and
document,
so
what
we
need
to
do.
What
ses
needs
to
do
is
do
surgery
on
this
graph
to
partition
the
safe
versus
unsafe
worlds
and
to
do
it
in
a
way
that
has
the
minimal
impact
on
existing
code.
A
So
we
pull
off
all
of
the
unsafe
objects
into
the
graph
on
the
left
representing
the
start
compartment
and
the
graph
on
the
right
are
the
frozen
primordials.
The
frozen
shared
intrinsics,
which
are
pure,
which
have
no
mutable
state
and
that
are
safely
shareable
and
the
key
thing
is
to
notice
is
that
between
these
two
subgraphs,
the
only
arrows
that
cross
between
them
are
going
to
the
right.
The
start,
compartment
subgraph
points
into
the
intrinsics
and
there's
no
there's
no
pointers
in
the
opposite
direction.
A
The
two
dates
the
date
in
red
on
the
left
is
the
original
powerful
date.
The
white
date
that
remains
in
the
frozen
intrinsics
is
a
safe
variant
that
has
all
of
the
ability
to
represent
dates,
date,
instances
and
to
do
formatting,
etc,
but
not
to
provide
the
current
time
so
because
all
of
the
arrows
cross
only
rightward.
A
We
can
create
other
compartments
where
the
other
compartments
also
point
into
this
graph
in
a
similar
manner,
and
then
we
can
run
old
code
in
the
scope
of
that
compartment
and
because
the
evaluators
evaluate
code
in
in
some
global
object,
each
compartment
has
to
have
its
own
evaluators.
It
has
to
have
its
own
global
object,
but
it
doesn't
have
to
have
much
else
that
is
per
compartment,
so
these
compartments
are
really
featherweight.
They
cost
creating
a
few
objects
per
compartment,
so
you
can
have
many
many
little
compartments
and
very
little
overhead.
A
The
code
that
creates
compartments
can
also
endow
the
compartment
with
emulated
host
objects
with
with
or
attenuated
host
objects
with
host
objects
that
the
star
compartment
wants
to
endow
the
other
compartment
with
such
that
the
code
in
the
other
compartment
thinks
it's
running
in
a
normal
javascript
environment,
except
that
the
primordials
are
frozen,
but
it
finds
on
the
global
object
that
it
sees
as
global.
Whatever
host
objects
were
endowed
by
the
creator
of
that
compartment.
A
A
B
A
A
So
any
system,
whether
browser
or
node,
or
something
else
that
provides
a
javascript
engine
that
conforms
to
the
full
language,
should
be
able
to
run
our
shim
library
and
to
use
it
in
a
secure
manner.
And
all
of
those
organizations
that
I
mentioned
are
using
are
using
the
except
for
embedded
are
using.
The
shin
the
embedded
use
is
is
using
the
xs
engine
which
directly
builds
cess
rather
than
using
the
ship.
It's
actually
it's.
A
A
The
main
way
in
which
some
old
code
fails
to
run
under
cess
is,
if
it
modifies
the
primordials.
Like
the
example,
we
showed
of
array.prototype.push
assigning
an
attacker
function
to
that.
Well,
that
example
was
preventing
an
attack,
but
some
code
does
some
surgery.
Some
systems
do
some
surgery
on
the
primordials
in
startup,
in
order
to
get
some
deeper
integration
into
javascript
and
scs,
treats
that
as
an
attack
and
prevents
it.
B
A
Right,
thank
you
thank
you
for,
for
we
also
invite
everybody
to
read
all
of
our
code
and
to
comment
on
it
and
to
point
out
bugs
and
to
you
know,
send
us
pull
requests
whatever
everything
that
we're
doing
is
completely
open
source.
It's
all
on
github,
both
ses
itself
and
all
the
things
we're
building.
On
top
of
it
all
the
way
to
our
blockchain-based,
smart
contracting
system
and
most
of
the
other
projects
on
it
are
also
fully
open
source.