►
From YouTube: ROS 2 Security Working Group (14 Dec 2021)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Right
next
point,
I
would
like
to
make
a
call
for
action
and
raise
awareness
around
a
few
things.
A
I
I
hope
we
all
agree
that
that
it's
not
a
comfortable
situation,
but
for
me
not
for
the
working
group,
victor
you've
already
applied
for
a
new
position
in
your
role
and
at
the
moment
this
is
somewhat
blocked
by
the
fact
that
there
are
very
specific
rules
that
requires
inanimous
approval
by
the
approvers,
and
we
have
two
approvers
that
are
not
active
at
the
moment.
B
A
A
Essentially
you
open
a
ticket
requesting
for
a
role
in
the
working
group.
There
are
three
different
levels:
three
different
roles
from
members:
you
simply
attend
the
security
meeting
up
to
approvals
where
you
review
and
approve
requests
the
different
types
of
requests
that
are
made
to
the
the
working
group
repo.
C
So,
jeremy,
just
to
get
a
bit
of
clarity
on
on
this
topic
and
then
maybe
a
suggestion.
Actually
let
me
let
me
do
it
the
other
way
around
it'll
start
with
the
suggestion
I
currently
don't
have
this
ability
on
who
are
the
reviewers,
approvers
or
members?
C
Is
that
kept
in
any
list,
because,
if,
like
I
just
realized
that
we
are
waiting
for
a
for
an
actual
approver
to
to
go
forward
with
the
request
that
I
made
so
could,
could
we
maybe
land
that
into
the
community
repo
directly
and
not
just
for
the
sake
of
having
transparency,
which
I
think
is
already
a
good
reason,
but
also
for
the
sake
of
as
we've
been
doing
in
the
last
few
meetings
trying
to
raise
awareness
about
security
about
the
work
we
are
doing.
I
think,
having
some
names
in
there
is
going
to
help.
C
People
also
become
aware.
A
A
B
A
Agree,
if
that's
not
that's
not
explicit
at
the
moment,
then
it
should
be.
C
Yeah
and
also
it
did
sounded
to
me
like
and
correct
me
on
this
journey,
but
it
did
sound
to
me
that
we
currently
do
not
have
the
privileges
or
capabilities
to
manage
the
group
like
meaning
like
we
ourselves,
including
everyone.
That's
in
here
so
so,
do
we
need
to
reach
out
to
open
robotics,
to
ask
for
such
permissions
or
something
like
that
or
do
you
actually
have
them,
and
then
we
are
okay.
A
Does
he
does
but
again
that's
that's
yet
another
point:
that's
not
very
explicit
in
the
existing
rules.
So
I'm
trying
to
do
things
as
as
right
as
possible.
C
Yeah
also
also,
I
saw
like
florencia
trying
to
make
a
request
and
mikkel
answering
about
the
fact
that
maybe
we
need
to
change
those
rules.
I
guess
you're
working
towards
that.
I
mean
for
what
concerns
my
side.
I
think
we
need
contributors,
so
if
florencia
is
up
to
to,
you
know,
participate
actively,
I
would
say
thumbs
up
for
engaging
her
like
as
a
nerdy
step
and,
and
the
same
should
apply
to
everyone
willing
to
to
contribute.
C
Now
you
mentioned
at
the
very
beginning
that
you
would
like
to
get
a
few
more
members
as
approvers,
so
that
you
feel
more
comfortable
managing
the
group,
I'm
guessing
you're,
referring
to
like
the
the
eldest
in
here,
which
are
rafi
and
mikhail.
How
should
we
proceed
with
this?
Should
they
should
they
make
a
request
for
being
approvers
in
the
usual
way.
A
C
A
A
Again
at
the
moment,
I'm
the
only
approver
so
the
the
last
level
in
the
in
the
world
and
it's
a
bit
of
an
uncomfortable
situation
for
me,
because
I
have
to
take
those
decisions
alone
and
I
I'd
rather
prefer
to
have
other
approvals
so
that
there
is
a
bit
of
a
consensus
and
we
can.
We
can
discuss
that
altogether.
A
A
We
need
an
anonymous
approval
of
the
approvers,
and
two
of
them
are
currently
inactive
and
at
least
one
is
very
inactive,
so
we
need
to
edit
those
rules
or
we
need
more
more
approvers
and
those
that
are
inactive.
C
Sure
that
that
makes
sense-
and
and
thank
you
for
by
the
way
tackling
this
as
I've
expressed
repeatedly
publicly-
I
think
in
the
past
the
management
has
been
a
bit
questionable
of
the
group
because
there's
been
attempts
to
contribute
and
cooperate
and
collaborate
and
they
were
blocked,
and
you
know
it
makes
sense
to
block
things
when
they
don't
go
in
a
direction
the
group
wants.
But
the
group
really
wasn't
that
active
for
not
saying
that
there
really
weren't
actual
contributions
from
from
the
people
blocking
those
actions.
C
So
so
what
I'd
like
to
see
is
the
opposite
happening,
which
is
encouraging
the
projects
we're
pushing
forward
and
then
accepting
new
members
accepting
like
new
projects.
So
I'm
I'm
well
aware,
jeremy,
jeremy,
that
this
is
happening,
and
I
I
see
this
with
good
faith.
I
think
it's
awesome
what
you
proposed
and
what
you're
doing-
and
I
also
fully
empathize
with
the
fact
that
you
want
to
get
kind
of,
like
you
know,
a
group
of
members
who
are
committed,
contr
and
and
can
make
decisions
jointly.
C
I
think
that's
the
best
decision
so
thumbs
up
for
that.
If
you
need
help
pushing
forward
with
open,
robotics
or
pressing
intelli
to
react,
ping,
us
and
and
we'll
be
happy
to
do
so,
I
mean.
A
Don't
worry,
that's
that's
ongoing,
there's,
no
problem
and
and
nothing's
blocked
at
the
moment,
because
of
that
right.
But,
as
you
rightfully
pointed,
I
was
actually
surprised
that
that
you're
not
an
explicit
members,
member
of
the
working
group.
So
if
you
feel
like
it,
please
do
do
apply
for
a
reviewer
or
even
an
approval
position
and
and
the
same
for
the
rest
of
you
guys.
B
C
And
just
for
the
sake
of
clarity
on
this
as
well
jeremy,
you
mentioned
that
the
the
the
approvers
reviewers
tickets
are
are
waiting
for
approvers,
who
are
idle,
who
are
not
like
active
anymore.
Well,
we
have
the
same
situation
as
well
as
with
florencia,
myself
and
and
raffi,
and
many
others
or
or
are
we
actually
able
to
move
forward
with
those.
A
So
my
plan
is
to
first
of
all
explicit
the
rules
to
downgrade
inactive
members,
okay,
so
to
do
that
properly
and
and
by
the
book-
if
I
may
say
so,
we
set
up
some
rules
to
downgrade
those
those
inactive
approvers
and
once
they
are
downgraded
I'll,
promote
a
new
approver.
Whoever
applies
for
it
and
from
there
that
will
un
block
the
whole
the
whole
situation
right.
A
So
what
I
could
do
is
open
those
proposed
those
new
rules
for
the
before
the
next
working
group.
We
would
approve
them
during
the
next
meeting
and
if
so,
then,
by
by
the
end
of
the
next
meeting,
we
we
would
have
new
members
officially
does.
A
D
A
Closed
same
for
pull
requests,
there
are
recent
issues
that
haven't
received
any
any
answer.
So
please
do
have
a
look
at
it,
especially
the
two
that
have
linked
in
the
agenda.
A
C
So
maybe
on
the
before
we
do
so
jeremy
on
the
esros
ii
issue
list.
I
I
do
agree
that
we
definitely
need
to
have
more
eyes
on
this
group.
C
I
can
volunteer
to
look
at
this
ticket
you
you
listed
in
here
only
I
guess
I
need
some
degree
of
so
who's
who's
managing.
I
can
just
comment
on
this
right
and
yeah
yeah,
so
possibly
my
first.
My
first
reaction
would
be
to
engage
with
this
person
and
try
to
ask
for
further
details
so
that
it's
reproducible,
typically
when
security
researchers
facilitate
something
they
make.
It
reproducible
the
docker
container.
A
C
A
No,
no,
that's
not.
We've.
B
A
Right
so
please
guys
do
have
a
look
at
those
issues.
There
are
some
that
are
open
since
2019
2018
ruffin,
especially
you.
A
Well,
I
guess
the
same
talk
more
or
less
here,
so
victor,
thank
you
for
being
here
and
and
for
this
talk
and
the
floor
is
yours.
C
Awesome
thanks
for
joining
me
for
the
intro
and
and
I'll
stick
around
or
that's
my
plan
for
now
and
and
many
meetings
forward.
So
hopefully
we
we
all
can
cooperate
and
contribute
so
since,
as
introduced
by
jeremy,
I
gave
this
talk
together
with
with
my
colleagues
a
few
times
already.
We
gave
it
first
at
blackhead,
we're
giving
it
also
sorry
we
gave
it
a
week
ago,
a
roast
industrial
with
a
slightly
different
format.
C
I'll
give
you
now
again
a
different
one,
which
is
going
to
be
much
more
down
to
the
actual
code
and
something
that
you
guys
can
reproduce
your
yourself
on
your
site
and
in
your
machines.
What
I'll
do
is
to
get
started
I'll
share
in
the
chat,
a
link
to
a
discourse
thread
in
the
ros
discourse
community,
wherein
you
can
not
only
read
a
short
introduction
or
long
about
this
topic,
but
also
engage
into
a
discussion
if
you
consider
it
appropriately,
especially
for
those
of
you
using
dds
or
ross2
in
industrial
use
cases.
C
That's
that's
the
right
place,
we're
in
to
ask
so
far.
There
hasn't
been
too
many
people
commenting.
I
guess
people
still
reading
around
but
super
happy
to
follow
up
both
myself
and
and
my
core
researchers.
So
let
me
share
my
screen
here,
real
quick.
C
A
C
A
C
So
so
we'll
be
so
again
as
promised,
I'll
walk
you
through
an
actual
through
through
two
case
studies
which
are
haven't
been
edited.
So
this
is
kind
of
like
site,
I
would
say
project
and
maintaining
myself
to
to
keep
engaged
with
cyber
security
and
robotics
and
too
so
for
context
again.
C
If
some
of
you
are
keen
on
diving
deeper
into
the
field,
then
I
would
very
much
encourage
you
guys
to
dive
into
this
talk
list
which
I
compiled
also
for
the
sake
of
having
a
discussion
today.
This
talk
list
to
the
best
of
my
knowledge,
is
pretty
complete
for
what
concerns
robot
cyber
security
and
particularly
in
the
ros
context
as
of
today,
and
most
of
these
talks
actually
have
been
given
by
members
of
this
working
group
that
come
and
go,
but
most
of
them
remain
active.
C
So
so
I
would
really
encourage
you
to
to
take
a
look
and
keep
and
keep
that
handy
in
case.
You
want
to
learn
more.
What
we
are
going
to
do
today
is
look
at
two
case
studies,
the
ros
2
and
the
turtle
boat
3
using
watch
2
as
an
extension
of
the
first
one.
C
If
anyone
wants
to
read
further
a
similar
methodology
than
the
one
I
would
be,
explaining
right
now
was
used
for
studying,
ros1,
creating
a
dissector,
as
you
would
see,
right
now
explained
doing
fast,
testing,
static
analysis,
dynamic
analysis
and
finding
the
corresponding
flaws.
So
there
are
also
a
few
demonstrations,
for
there
was
one
use
case
and
maybe
a
few
more
that
I'll.
C
If
I
have
time
I'll
build
in
the
future,
a
few
more
exploits
with
the
dissector,
but
anyhow
just
just
noting
that
you
can
dive
down
into
that
as
well.
C
So
looking
at
the
ross2
case
study,
I
will
not
motivate
the
importance
of
words
too,
because
I
think
everyone's
aware
and
here
and,
if
not
feel
free
to
cross
these
links
and
read
more
about
it.
The
typical
way
that
a
group
of
researchers,
as
it
was
our
case
or
or
essentially
an
individual
researcher
as
well,
would
go
about
assessing
and
and
diving
deep
into
a
stack
with
the
complexity
of
ros.
C
Two
is
typically
by
dissecting
the
stack
at
different
levels,
but
one
of
them
is
the
networking
level
to
do
so.
There's
various
tools
that
allow
you
to
do
so.
If
you're
used
to
work
with
wireshark,
you
can
use
some
of
the
workshop
existing
tools
and
use
some
wrappers
around
some
of
those
instrumentations
to
literally
do
your
first
assessments,
but
besides
that,
there's
also
a
huge
community
behind
a
project
called
skapi,
which
is
essentially
a
python
based
framework
for
creating
dissectors.
C
It
has
already
quite
a
few
dissectors
for
industrial
grade
protocols.
C
You
will
find
over
there
the
most
popular
ones,
and
it
allows
you
to
essentially
field
by
field
and
bite
by
bite
literally
play
around
dissect
incoming
packages
craft
your
own
ones,
and
challenge
in
a
way
any
implementation
of
the
corresponding
communication,
interaction
and,
of
course,
also
the
endpoints
with
with
such
capabilities,
is
reasonably
easy
using
some
simple
python
scripting,
as
you
will
see
right
now
to
impersonate
endpoints,
the
dds
level,
to
create
man
in
the
middle
or
person
in
the
middle
attack.
C
Sorry,
in
a
variety
of
different
things,
attacking
not
just
the
application
layer,
which
is
often
what's
done
in
some
in
a
first
assessment
you
can,
you
can
attack
a
system
or
a
number
of
systems
across
the
whole
osi
stack,
meaning
that
you
can
try
to
challenge
the
determinism
obtained
at
the
layer.
Two,
the
data
link
layer.
You
can
try
to
challenge
the
networking
stack
layers.
Three
and
four
most
cases
involves
two
using
udp
and
ip.
C
You
can
tackle
upper
layers,
layer,
5
layer,
6
layer,
7
all
the
way
up
until
the
application
logic.
So
today
we
will
see
a
few
examples:
tackling
a
variety
of
these
layers
using
the
dissector
we
crafted
as
part
of
this
effort,
which
started
in
my
case
started.
Last
year
last
year,
in
ross
industrial
conference,
I
presented
the
dissector
for
was
one
and
this
year,
together
with
a
group,
we
presented
a
dissector
for
verse
too.
C
You
can
see
over
here
how
easy
it
is
to
use
it
so,
provided
you
have
imported
the
corresponding
libraries
or
modules
in
this
case
from
from
skappy.
You
can
just
craft
literally
bit
by
bit,
and
there
are
some
facilities
in
case
of
common
names
that
are
kind
of
like
written
and
hard-coded
into
the
dissector.
C
But
this
gives
you
essentially
a
package,
a
minimalistic
package
of
rtps,
which,
as
you
may
know,
is
the
underlying
wire
level
protocol.
The
tds
uses
tds
lives
on
top
of
rtps
the
real
time
published
subscribe
protocol.
So
if
you
want
to
challenge
things
from
a
networking
perspective,
you
typically
do
tackle
rtps.
C
The
representation
of
this
simple
package
is
depicted
right
over
here.
So
there's
I
think,
pdf
reso
pdf
versions
in
the
repo
in
case.
You
want
to
look
at
it
closely,
but
nevertheless
this
is
just
a
fun
graph
that
comes
out
of
this.
This
construct
right
over
here,
with
just
as
a
simple
python
command,
so
scopy
does
not
just
help
you
actually
in
doing
the
crafting,
but
also
in
dissecting
and
analyzing
things
with,
like
nice
plots
and
fancy
plots
like
those
ones
which
are
always
great
for
presentations.
C
The
first
thing
you
will
find
is,
as
I
was
introducing
before,
that
we
went
ahead
and
built
a
docker
a
container
for
you
guys.
Actually
it's
a
docker
file
from
where
you
can
build
your
own
docker
container
and
from
where
you
can
easily
reproduce
the
things
you
will
see
right
over
here
and
this
in
in
security,
especially
when
working
across
teams
of
researchers,
security,
researchers
and
roboticists.
C
It's
pretty
crucial
because
each
one
has
his
or
her
own
development
environment
and
that
that
makes
things
very
challenging
for
reproducing
things
so.
Keeping
things
easy
and
docker
based
has
essentially,
at
least
to
my
experience,
so
far
facilitated
things.
C
So
you
could
run
it
directly
after
building
it,
and
here
is
here's
a
simple
like
recipe
on
how
to
just
launch
a
simple
package
and
get
it
shown
in
your
device,
or
you
could
run
it
also
with
the
gui,
which
is
also
provided
in
here
using
x11,
which
you
can
try
yourself
if
you
want
to
as
well.
C
So
once
we
have
the
environment
up
and
running
and
there's
three
case
studies
or
three.
Let
me
let
me
put
it
three
subjects
studied
in
this
case
study
the
first
one
is
doing
reconnaissance,
which,
according
to
the
usual
kill
chain
model
that
most
attackers
follow,
is
the
first
thing
we
typically
see
from
malicious
actors,
which
is
they
try
to
identify
your
robots,
your
robotic
systems
in
the
network,
if
they
don't
have
visibility
of
what
they
are
attacking,
it's
pretty
challenging
to
just
throw
away
exploits
out
there.
C
They
first
need
to
do
reconnaissance,
which
often
comes
down
to
doing
footprinting,
and
then
fingerprinting
footprinting
generally
helps
you
identify,
let's
say
roughly
what's
out
there
and
then
with
fingerprinting.
You
obtain
further
details
about
what
particular
version
that
protocol
is
being
used
or
what
particular
sub
items
that
that
implementation
might
be
subject
to
so
doing.
Reconnaissance
once
again
is
something
that's
pretty
crucial
for
such
such
a
stimulation
of
an
attack.
C
So
that's
what
we
do.
We
craft
a
package
we're
using
the
dissector,
and
you
can
see
it's
representation
right
over
here
and
then
using
that
package
crafted
we
we
go
ahead
and
launch
it
to
the
network,
hoping
to
get
responses
now,
given
the
way
the
omg's
specifications
for
dds
and
rtps,
and
also
the
security
extensions
are
written
currently
essentially
nodes
to
respond
to
these
queries.
So
we
we
find
ourselves
in
a
situation
where
discovery
essentially
happens,
regardless
of
how
much
we
harden
currently
our
roster
notes,
if
compliant
with
the
dds
specifications.
C
If
you
were
to
modify
your
dds
implementation
to
not
respond
appropriately,
then
you
would
be
breaking
with
the
interoperability
of
specified
by
dds,
but
you
would
be
able
to
mitigate
this
this
reconnaissance
issue,
so
in
this
case
you're
seeing
right
over
here,
is
a
recording
on
how
we're
demonstrating
that.
C
C
In
this
case,
it's
been
done
with
a
particular
dds
implementation.
Now,
what
we're
going
to
do
is
stop
the
publisher
and
change
it
to
a
different
dds
implementation,
so
from
cyclone
we're
going
to
go
into
fast
dds.
C
So
the
expectation
for
those
of
you
who
are
familiar
with
the
dds
specification,
the
expectation
is
that
discovery
should
still
work
and
you
should
still
get
a
response,
but
surprisingly
or
unsurprisingly,
there
does
not
seem
to
to
happen
what
expected
and
within
the
the
time
allocated
for
it.
There
are
no
responses
whatsoever
now,
in
this
case
we're
publishing
with
fastidious,
but
this
doesn't
mean
that
fast
dds
is
more
secure.
C
We
similarly
also
crafted
the
corresponding
package
with
fast,
dds
and
tested
that
again,
as
stated
it's
possible
to
discover
rush,
two
notes
powered
by
fast
dds
and
in
fact
I
may
point
out
that
it's
not
just
that
fast
dds
is
as
exposed
as
cyclone
dds
to
to
reconnaissance.
C
We
found
in
fast
dds
a
significant
amount
of
flaws.
We
did
not
find
in
other
implementations,
so
so
I
wouldn't,
I
wouldn't
take
any
conclusions
out
of
just
simply
the
fact
that
there's
no
interoperability
from
a
discovery
perspective
now,
once
we
as
potential
attackers
again
simulating
it
have
found
potential
targets.
Next
thing
we
do
is
to
essentially
go
ahead
and
try
to
identify
which
of
those
corresponding
nodes,
run,
dds,
implementations
that
are
flawed
or
that
have
been
somehow
tagged
as
vulnerable
to
specific
known
security
vulnerabilities.
C
In
this
case,
we
ourselves
found
those
vulnerabilities,
so
we
knew
what
we
were
doing
and
we
triggered
two
attacks.
The
first
one,
you
will
see
is
a
reflection
attack,
which
is
essentially
affecting
all
dds
implementations
so
similar
to
reconnaissance.
This
is
affecting
all
of
the
dds
implementations
and
it's
also
a
flow.
C
That's
triggered
by
a
lack
of
consideration
in
the
omg
specifications,
meaning
that
right
now,
the
thread
model
considered
within
the
omg
dds
security
plugins
do
not
consider
such
such
an
such
attacks,
and
it
would
need
to
be
amended
and
extended.
With
this
and
other
flaws,
we
we
did
detect
and
we
are
still
processing
what
you
will
see
right
now.
C
C
So,
what's
going
to
happen,
is
that
when
we
do
so
we're
going
to
use
888,
which,
as
you
know,
is
the
google's
dns
server
and
what's
going
to
happen,
is
that
it's
just
going
to
start
reflecting
packages
the
dns
server,
and
this
is
going
to
trigger
a
significant
amount
of
traffic
which
is
going
to
overload
c.
You
can
see
it
right
over
here.
This
is
just
because
of
a
flow
that
exists
right
now
in
how
essentially
packages
are
being
sent
from
an
rtps
perspective.
C
So
this
is
one
of
the
things
we
demonstrated
here.
Is
here's
the
complete
package
used
and,
as
you
can
see
again,
it's
crafted
using
scappy.
You
can
see
how
easy
it
is
to
build
it
up.
We
start
by
telling
what
we
want
in
the
ip
layer
same
at
the
rtps
level.
C
Then
we
craft
one
or
multiple
rtps
messages
and
submessages
in
this
case,
it's
enough
to
build
one
of
the
sub
messages,
the
data
one
in
particular,
and
we
define
where
we
want
the
the
traffic
reflected
within
the
pid
meta
traffic
unicast
locator.
Currently
there
is
no
defense
to
this
attack.
If
you
want
to
remain
compliant
with
the
omg
specification,
the
only
way
to
mitigate
this
properly
would
be
to
change
the
omg
specification.
C
But
what
some
vendors
we
have
been
working
with
are
doing
is
to
limit
the
traffic
they
send
out
by
applying
some
essentially
scaling
so
that
if
the
traffic
starts
bursting
out
significantly,
they
they
lower
that
exponentially,
and
that
so
far
is
mitigating,
to
a
certain
extent,
the
the
exponential
reflection
we
we
observed.
C
C
So
this
was
the
second
attack,
and
in
this
case
it
was
demonstrated
with
with
opendds
in
the
video
you
saw,
but
it
could
literally
also
be
done
with
any
other,
any
other
rt
sorry,
dds
implementation,
there's
cv,
ids
assigned
for
connects,
rti
or
opendds
and
prosimone
cyclone
dds
for
all
of
them
pretty
much.
And
then,
here
you
have
the
instructions
in
case
you
wanna,
try
it
home,
but
only
home,
please.
C
Finally,
there
is
at
least
within
this
case
study
there's
this
third
vulnerability.
We,
we
do
demonstrate,
which
essentially
crashes
a
note,
and
this
is
due
to
a
flow
found
in
open,
dds,
particular
implementation.
This
flow
is
only
applicable
to
opendds
and,
as
pointed
out
in
here,
it
leads
rost2
nodes
to
crash
or,
frankly
speaking
also,
we
believe,
to
execute
arbitrary
code,
though
we
did
not
spend
time
just
playing
around
with
techniques
or
doing
rob,
because
it
wasn't
the
the
aim
of
our
research.
C
C
C
So
so
that's
that-
and
let
me
actually
show
you
how
this
looks
in
real
and
also
as
in
previous
ones,
you
can.
You
can
reproduce
this
in
the
docker
container,
facilitate
it
pretty
easily,
so
we're
setting
up
the
environment.
C
C
So
yeah
there
we
go,
we
have
a
publisher
and
we
also
see
on
the
left
side,
the
the
actual
ports.
C
And
so
there
we
go,
we
just
launched
the
exploit
and
we
exploit
that
flow
and
we
just
crash
it
and
actually
now
I
I
launch
it
again,
just
for
the
sake
of
demonstration
yeah
there
we
go
so
again
this
this
generates
a
segment
well,
a
core
dump
segmentation,
folder,
no
pointer
in
a
way,
and
it
could
be
further
introspected
by
attackers
to
again
not
just
crush
the
note
but
by
but
to
execute
malicious
code,
and
it's
important
to
note
that
this
could
happen
in
a
in
a
remote
manner.
C
So
it's
it's
it's
very
close
to
rc
or
we
believe
so
remote
code
execution.
Sorry,
so
that's
pretty
much
it
for
the
three
demonstrations
in
here
there's
a
few
more
details
in
here.
If
you
want
to
look
deeper
into
this
last
last
flow,
I
I
did
demonstrate-
and
here
I'm
walking
you
through
how
to
further
look
into
the
memory
and
see
how
we
could
further
tinker
with
it.
C
But
I
just
leave
it
there
for
the
sake
of
remaining
nice
and,
of
course,
credit
to
to
all
my
my
co-researchers,
who
so
far
have
been
doing
an
outstanding
work
and-
and
this
group
continues
further
we're
we're
still
working
together
and
we
hope
to
to
keep
it
up.
So
if
you,
if
you
would
like
to
to
know
more
just
to
reach
out
and
we'll
let
you
know
so,
that
was
the
first
piece
that
I
prepared
the
second
one.
C
The
second
one
is
an
extension
because
in
this
case,
the
turtle
3
is
also
powered
by
rose
2.,
but
in
this
case
I'm
going
to
skip
the
reconnaissance
which
you
just
saw
in
a
pure
roster,
essentially
environment.
So
in
the
case
of
a
robot
tower
by
wash
2
such
as
the
turtle.
What
is
pretty
much
the
same,
I'm
also
going
to
skip
the
reflection
attack.
C
So
we
found
without
interesting
the
fact
that
even
the
the
best
in
the
world
apparently
has
has
definitely
stuff
to
do
security
wise
and
that's
why
this
group
is
so
important.
So
in
this
case
the
security
flow
is
somewhat
similar
in
the
sense
of
what
it
causes
as
the
previous
one
we
just
shot.
We
just
we
just
saw
sorry,
I'm
just
gonna
show
it
to
you
now
in
a
real
robot
with
a
bit
of
a
more
robotics
context.
C
So
what's
happening
in
here
is
that
we
are
launching
the
turtle
wall
3
and
we
are
teleoperating
it
with
with
the
teleop
node,
which
is
running
on
top
of
of
rti's
connext.
So
with
the
teleop
node,
we
give
it
a
given
command.
As
you
can
see
right
here
and
and
so
the
moment
we
stop
the
tele-up
note.
C
Obviously,
the
robot
stops,
because
the
note
finishes
appropriately
and
and
essentially
the
right
velocity
is
sent
to
set
things
to
zero
now,
if,
instead
of
stopping
it
properly,
the
roster
note
if,
if
we
stop
the
tilly
up
node
by
killing
it
with
the
exploit,
as
you
can
see
right
here,
what
happens
is
that
the
velocity
remains
with
the
last
value
that
the
actual
delay
was
giving
it
leading
the
potential
operator
to
lose
complete
control
of
the
robot,
because
he
or
she
might
be
thinking
that
nothing
happened.
C
But
the
reality
is
that
the
note
was
crushed
remotely
and
essentially
the
computational
graph
was
was
messed
up
with,
which
leads
to
this
simple
and
silly
crushing
demonstration.
Some
some
of
my
core
researchers
are
trying
to
make
this
fancier
by
using
a
bigger,
amr
or
or
even
a
self-driving
car.
But
the
underlying
aspects
are
the
ones
just
demonstrated
how
we
we
can
crash
a
note
one
within
the
computational
graph.
C
That,
in
this
case,
plays
a
role
in
the
overall
actuation
chain
and
how
that
that
causes
an
inconsistency
in
the
computational
graph,
which
makes
essentially
well
which,
which
makes
things.
C
Wrong,
I
guess
that's
that's
the
way
to
put
it
unless
you
have
considered
that-
and
in
this
case
it
is,
it
is
not
as
it
ships
within
wars
2..
So
there
is
there's
another
poc
of
this
same
flaw
in
here,
which
is
less
fun
because
there
are
no
graphics,
so
I'm
just
going
to
leave
it
there
and
maybe,
with
the
time,
left,
open
myself
to
questions
and
and
comments,
criticisms,
suggestions,
etc.
C
Thank
you
so
much
and
hoping
that
this
was
at
least
interesting.
A
Thank
you
victor.
That
was
very
interesting
and
very
well
illustrated,
and,
and
what
I
found
interesting
as
well,
is
a
collateral
effect
of
this
research.
I
may
say
so
that
just
highlight
the
lack
of
interrupt
interoperability
between
dds
implementations,
yeah
long
running
long
gag
in
in
roster
and
still
is
definitely
right.
B
Yeah
thanks
thanks
victor
for
a
really
nice
presentation.
I
I
just
wanted
to
ask
like
what
has
been
the
reactions
from
from
the
companies
doing
the
dds
implementations
like
how
have
they
responded
or
reacted
to
this.
C
That's
that's
the
question
yeah,
so
there
is
lots
of
reactions
and,
and
just
for
the
sake
of
remaining
fair
to
everyone,
I
will
not
will
not
name
who
said
what,
but
I
can
tell
you.
I
can
tell
you
a
bit
of
what
has
been
said
without
naming
anyone
specifically,
I
can
tell
you
that
some
some
have
been
very
responsive
and
have
cooperated
with
us
from
the
very
beginning,
particularly
and
in
this
case.
Yes
in
this.
In
this
one
case,
I
will
cite
who
it
is.
C
80
link
which
is
behind
cyclone
dds
have
been
outstandingly
responsive
so
far.
They
have
actually
have
been
working
with
us.
So
it's
been
awesome
to
have
not
just
a
group
of
security,
researchers
and
roboticists,
but
also
you
know
an
architect
of
dds
helping
us
dissect
it
helping
us
understand
when
we
broke
things,
why
we
broke
it
and
how
we
could
mitigate
it
and
in
some
cases,
how
it
can't
be
mitigated
so
80
links
and
particularly
having
eric,
who
is
the
main
architect
at
their
side.
C
Working
side
by
side
with
us
has
been
a
privilege,
and-
and
I
can't
compliment
him
enough
and
thank
him
enough
and-
and
things
are
continuing
forward
with
him
as
well,
so
super
excited
about
that,
and-
and
I
think
for
what
concerns
myself
at
least,
I
would
say
thumbs
up
for
the
work
cyclone
dds
is
doing
on
security.
C
Most
others,
to
be
honest,
are
still
getting
up
to
speed
with
security,
meaning
that
many
didn't
know
what
an
identifier
or
a
cv
id
was.
So
we
had
to
you
know,
struggle
a
bit
to
get
the
ids
in
some
cases,
because
we
didn't
want
it
to
raise
it
beyond
themselves.
We
wanted
them
to
take
actions.
C
Eventually,
we
had
to
cooperate
with
sisa
and
with
some
other
cnas
to
get
the
ids
because
they
were
not
prepared
to
grant
to
granted
for
what
concerns
mitigations
most
have
been
pretty
responsive,
provided
we
did
give
them
the
pocs,
meaning
that
we
did
give
them
a
way
to
reproduce
the
flaws.
The
reality,
though,
is
that
it
was
a
significant
effort
on
our
side
and
and
the
overall
awareness
needs
to
raise
to
be
proactive
on
this.
You
cannot
expect
that
a
group
of
you
know
hippie
security.
C
Researchers
like
us
are
going
to
put
their
personal
months
into
finding
flaws
and
then
gifting
it
away.
So
that's
not
how
typically
it
works.
We
we
wanted
most
of
them
to
take
a
proactive
attitude
and
you
know
not
ask
but
hire
someone,
maybe
some
of
you
guys
to
to
find
the
flaws
and
and
touch
them
directly.
C
So
so
that's
also
something
we
observed,
and
then
there
are
things
on
the
bad
side
of
the
spectrum,
which
also
were
observed.
Things
such
as
trying
to
take
legal
actions
against
us
things
such
as
trying
to
enforce
licensing
aspects.
To
avoid
us
disclosing
aspects,
I
can
tell
you
also
that
we
we
were
planning
to
release
this
much
sooner
and
much
earlier,
but
we've
been
repeatedly
blocked
by.
C
I
guess
I
can
say
yeah
I
I
guess
I
can
say
certain.
Let's
say
national
funded
bodies
because
it
was
affecting
apparently
military
contractors,
part
of
the
work
we
were
pushing
out,
and
that's
also
one
of
the
reasons
why
what
you
have
seen
today
and
what
you
can
read
on
our
public
disclosures
is
not
everything
we.
We
do
have
plans
to
disclose
much
much
more,
but
we're,
of
course,
trying
to
be
responsive
and
following
responsive
disclosure
approaches.
C
So
there's
also
that
there's
also
vendors
who
are
trying
to
enforce-
let's
say
the
legal
path,
but
unfortunately
we're
not
the
bad
guys
so
and
against
cyber
criminals.
That
legal
approach
is
gonna,
be
very
useless
in
our
humble
opinion.
So
that's
that's
our
standpoint
and
then
maybe
moving
beyond
the
bad
reactions.
There's
the
funny
reactions
funny
in
the
sense-
and
you
will
hear
about
this-
also
in
our
white
paper,
which
we're
hoping
to
publish
next
year.
C
But
you
will.
You
will
read
a
bit
about
the
fact
of
how,
while
doing
so,
we
found
some
dds
dds
implementations.
I
would
say:
teams
behind
the
dds
implementations,
which
literally
were
so
exposed
that
we
found
out
their
credentials
in
the
open
in
their
ci
pipelines.
We
could
access
their
source
code
and
they
are
sold
as
proprietary
implementations.
C
So
we
found
out
pretty
much
everything.
So
it
was.
It
was
a
bit
and,
of
course
we
we
will
not
say
who
who's
behind
that,
but
it
was.
You
know
we
found
like
fun
stuff
and
also
the
funniest
thing
is
that
this
particular
vendor
hasn't
hasn't
really
cared
about
answering
any
of
our
responsive,
like
emails,
responsive,
meaning,
responsive
disclosures,
like
hey
guys,
you've
like
we
found
this.
Would
you
mind
please
taking
a
look
not
or
hey
guys.
We
found
that
we
found
this,
and
this
is
you
know
this
is
your
source
code.
C
I
I
think
it's
it's
proprietary,
so
would
you
mind
just
removing
your
credentials
from
the
open?
Please
not
even
responding
to
that.
So
no,
no
thank
yous,
no
got
it.
Thank
you
we'll
look
into
it.
Nothing
at
all.
So
I
think
there's
lots
of
work
to
do,
and
I
encourage
you
all
to
maybe
take
this
humble
contribution
that
we've
we've
made
and
take
it
to
our
your
organizations
and
further
extend
it.
C
That's
why
we
are
disclosing
also
the
dissectors
that
you
can
play
around
the
feeling
is
that
this
is
just
the
tip
of
the
iceberg.
There's
lots
of
things
that
will
blow
up
and
we
as
a
group
need
to
need
to
consider
being
responsive
and
contributing
back.
B
Yeah
thanks
thanks
victor
yeah.
I
think
it's
a
quite
a
common
problem
in
white
hat
stuff
that
you
never
know
the
reaction
on
the
other
side,
but
one
follow-up
question:
what
about
the
omg?
I
understood
that
some
of
the
some
of
the
mitigations
and
fixes
would
require
some
amendment
or
extensions
for
the
security
spec
of
dds.
Have
they
reacted
somehow
to
this.
C
Fight
we're
trying
to
engage
into
more
conversations.
So
far
we
haven't
been
very
successful.
I
can
tell
you
we're
lucky
we're
lucky
that
one
of
our
close
cooperators
and
members
of
the
team,
actually
our
researchers,
is
eric.
Who
is
actively
a
member
of
omg's
meetings,
so
he's
trying
to
to
get
us
into
the
right
meeting
so
that
we
do
convey
the
right
pieces
of
information.
C
The
the
information
that
we
know
from
the
discussions
that
have
been
held
is
that
omg
is
keeping
an
internal
issue
tracker,
which
is
non-non-public
with
with
a
significant
amount,
like
many
thousands
of
security
issues
which
haven't
been
addressed,
so
that
makes
us
think
that
maybe
they
might
be
aware
of
certain
things,
but
they
lack
the
resources
to
tackle
them
all
together,
which
is,
I
guess,
great
news
for
for
groups
like
us.
A
Right
so
we've
reached
the
end
of
the
meeting,
but
maybe
we
can
take
another
question.
Anyone
as
well.
D
Through
the
killing
the
the
teleop
process
and
subsequently
causing
the
the
robot
to
continue
moving
out
on
its
current
trajectory
velocity,
I
suspect
that
that's
partially
bet
to
you
know
maybe
a
flaw
in
whoever's,
robot
controller
implementation.
Normally
they
would
have
some
kind
of
dead
man
protocol
where,
if
they
where,
if
a
deadline
is
conceded,
then
the
velocity
gets
kind
of
reset.
D
But
that's
just
like
one
particular
second
order
kind
of
vulnerability.
Did
you
experience
any
any
others
were
like
affecting
the
the
quality
of
service
on
the
network
or
many
dealing
packets
resulted
in
unexpected
behaviors
in
in
the
raw
systems.
C
So
short
answer
to
the
first
question
is
yes,
I
I
share
your
view,
and
I
I
agree-
that's
possibly
that's
possibly
hidden
within
the
controllers
and
would
need
to
be
patched
at
that
level
on
top
of,
of
course,
the
corresponding
implementation
of
the
dds
implementation.
But
but
there
is
possibly
lots
of
things
that
will
come
up
from
under
layers,
meaning
dds
all
the
way
up
to
ross
shoe
stacks,
which,
due
to
security
issues,
will
will
need
to
be
modified.
C
So
so
that
is,
that
is
one
of
the
things
that
is
starting
to
be
obvious
to
to
me
and
to
us,
as
for
having
further
ways
to
visualize
what
what
these
flaws
could
cause
or
or
because
I
mean
the
vulnerabilities
are,
are
these,
but
then
they
could
affect
a
significant
number
of
of
components
within
the
computational
graph,
but
those
wouldn't
be
new
vulnerabilities.
C
Those
would
be
just
no
realize
or
exploit
exploitations
new
ways
to
exploit
the
flaws,
and
so
the
way,
our
vulnerability,
at
least
strictly
speaking
within
the
security
domain
is,
is
assigned,
is
by
complying
to
mitres
rules
and
and
and
by
ensuring
that
you
get
a
proper
cv
id.
If
you
do
have
a
new
cv
id,
then
it's
a
new
vulnerability,
but
but
that
doesn't
mean
it
can't
be
used
to
exploit
different
parts
of
the
graph.
You
pointed
out
about
maybe
messing
up
with
the
quality
of
service.
C
I
I
suspect,
that's
very,
very
easy
to
do
with
the
second
flaw
I
demonstrated,
which
essentially
causes
your
endpoints,
your
notes
to
start
like
shouting,
traffic
literally
start
shouting
out
traffic
outside
and
and
they
do
so
as
as
much
as
you
ask
them
to
do
so.
Possibly
it
should
be
fairly
easy
to
demonstrate
how
that
can
can
compromise
real
time
deadlines
of
real
time
overall,
and
if
there's
anyone
interested
in
going
that
path,
then
I'm
more
than
happy
to
to
cooperate.
Putting
together
a
poc
I
gave.
C
I
gave
a
speech
in
roscon
2019
about
this
topic
about
real-time
security
using
a
different
vector
in
a
way,
but
but
definitely
I
think,
that's
that's
a
feasible
way
to
to
do
so.
D
In
particular,
with
denial
of
service,
what's
often,
the
most
valuable
aspect
for
for
an
attacker
is
is
having
some
multiplier,
where
you
given
some
amount
of
effort
and
then
that
magnitudes
into
a
larger
impact
based
on
some
particular
flaw
or
echo
in
the
protocol,
did
you
did
you
find
anything
like
that
where
edius
is
maybe
susceptible
to
like
this
amplification
of
of
noise
over
the
network,
based
on
some
malicious,
malicious
payloads.
C
So
I
think,
if
I
understood
your
question
properly,
I
would
say
we
found
two
flaws
that
that
do
fit
into
that
category.
Where
you
know
one
flow
actually
affects
many
many
systems
and
can
can
be
used
with
actual
actually
all
of
the
dds
implementations.
C
The
first
one
would
be
the
fact
that
that
reconnaissance
and
footprinting
and
fingerprinting
is
is
possible,
and
this
is
something
you
yourself
roughly
also
researched
in
the
past,
with
one
of
your
papers
that
I'm
aware
and
that
I
that
I
read
so
this
is
the
first
one
which
I
think
sometimes
is
you
know
left
aside,
but
again,
if
an
attacker
is
not
able
to
do
footprint
your
system,
he
or
she
is
really
not
going
to
have
a
clue
on
how
to
start
attacking
it.
So
it's
very
important.
C
We
we
do
mitigate
those
those
issues,
asap
and
then
the
second
one
is
the
reflection.
One
demonstrated
right
now.
What
our
group
is
trying
to
accomplish
is
to
in
the
same
way
it
was
done
in
the
past
for
ross
to
try
to
scan
the
internet
for
roster
endpoints,
particularly
sorry
for
dds
endpoints,
where
we're
not
like,
specifically
looking
for
roster,
which
would
require
maybe
a
bit
of
more
logic
on
top
of
the
scanners,
we're
building
but
tds
endpoints,
and
for
some
reason,
which
I
don't
really
know.
C
I
I
remember
that
in
the
last
few
years
in
face-to-face
encounters
people
used
to
say
yeah,
you
know
you
can't
you
can't
find
in
the
internet
dds
endpoints
well,
this
is
this
is
not
true
and-
and
I
can
tell
you
what
we're
finding
and
and
and
we're
finding
them
across
dds
implementations
and
hopefully
that's
something
we
will
disclose
with
with
future
disclosures
and
with
with
the
paper
in
a
few
in
a
few
weeks
or
months
when,
once
we
are
ready,
possibly
in
early
next
year,
but
but
yeah.
C
We're
also,
I
mean
the
plan,
as
far
as
I
know
also
is
to
disclose
how
to
do
this,
meaning
that
that
should
put
some
pressure,
good
pressure
on
dds
vendors
to
try
to
find
you
know
ways
to
mitigate
this
potential
discovery.
But
these
two
are
the
ones
we
are
commenting
publicly
right
now
there
are
a
few
others
that
could
cause
chaos.
You
know,
let's
say
in
a
you-
know
in
an
interesting
manner
and
possibly
many
many
more
hidden
which
we
haven't
located
so
far.
C
What
one
one
comment
I
can
make
is
that
we
only
touch
the
very,
very
exterior
layers
of
dds,
meaning
that
we
just
did
like
a
fast
testing,
a
bit
of
dynamic
analysis
using
other
techniques
and
a
bit
of
static
analysis,
but
we
didn't
dig
very,
very
deep,
so
so,
just
with
a
bit
of
fast
testing,
we
found
already
a
lot.
So
there's
lots
of
work
to
do.
C
A
We're
gonna
get
busy
right.
We
are
reaching
the
end
of
the
meeting.
Thank
you.
Thank
you
very
much
victor
and
thank
to
all
of
you
for
attending.
I.
I
will
conclude
this
meeting
echoing
again
this.
This
call
for
action.
Please
do
apply
for
an
explicit
membership
to
the
to
the
security
working
group
community
group
on
github.