►
Description
Pietro Albini
Rust Infrastructure Team Lead - Rust and Llvm Security Response - Building Compilers at Ferrous Systems
The Rust Security Response WG is responsible for receiving reports about Rust vulnerabilities, disclosing the vulnerability to the public, and assisting the Rust project teams when developing the fix. The WG is crucial for the security of the Rust ecosystem, but most of its work has to be kept private to prevent vulnerabilities from leaking.
In this talk, a member of the WG explains how it operates and handles vulnerabilities. During the talk we’ll walk through CVE-2022-21658 (race condition in std::fs::remove_dir_all), from the moment we received the report to the public disclosure.
A
So
hi
everyone-
and
in
this
talk,
I,
want
to
talk
about
how
Russ
daras
project
handles
vulnerabilities
in
Rust
itself.
I'm
Pietro
I
lead
the
Ross
infrastructure
team
and
I'm.
Also
a
member
of
the
rust
release
team
and
the
security
response
working
group,
so
I'm
kind
of
in
the
theory
of
those
project
making
sure
us
gets
delivered
to
you
and
also,
as
my
day,
job
I
work
on
the
Pharisee
infrastructure
and
build
system
at
Pharaoh
systems.
Ferrosine
is
a
qualified
tool
chain
of
the
eras
project
for
safety,
critical
users.
A
So
what
is
drug
security
response
working
group?
The
group
is
part,
is
a
part
of
the
last
governance
and
it
handles
all
the
security
vulnerabilities
that
are
present
in
the
rust
project.
So,
ideally,
when
someone
finds
a
security
concern
near
us,
they
will
come
to
us
and
we'll
make
sure
the
bug
is.
The
vulnerability
is
fixed
and
disclosed
properly.
A
Our
job
is
to
fold.
We
first
need
to
Route
the
vulnerability
details
to
The
Domain
expert,
and
then
we
handle
all
the
bureaucracy
of
disclosing
security
issues
and,
crucially,
fixing.
The
vulnerability
is
not
in
this
slide
and
is
not
something
we
do
because
the
last
project
by
now
is
really
large.
We
are
around
300
people
in
the
project
with
multiple
different
sub
projects
and
it's
impossible
for
people
in
the
group
to
have
knowledge
of
of
how
to
fix
most
vulnerabilities.
A
So
we
prefer
to
take
a
step
back
and
instead
make
sure
the
domain
experts
that
are
the
most
knowledgeable
person
of
the
theory
of
the
project
are
in
the
know,
and
that
will
help
us
fix
things.
There
are
22
members
of
the
team
myself
and
Justin,
and
it's
fine.
We
rust
doesn't
receive
that
many
vulnerabilities,
so
it's
a
workflow
we
can
support
and
unfortunately
the
work
we
do
is
inherently
private
because
we
handle
vulnerabilities
under
embargo.
A
So
that
means
vulnerabilities
are
not
yet
disclosed
publicly
and
we
have
to
keep
them
private,
otherwise,
the
otherwise
the
details
of
vulnerability
will
be
in
the
public
without
a
fix
being
available,
and
so
for.
The
security
of
the
ecosystem
is
imperative
that
we
keep
everything
private,
but
unfortunately
that
means
people
don't
know
what
we
do
and
so
in
this
talk,
I
want
to
shed
a
bit
of
light
on
how
our
processes
work,
how
vulnerabilities
are
handled
and
what
takeaways
you
can
take
for
your
own
projects.
A
This
is
the
list
of
all
the
security
vulnerabilities
that
were
reported
to
us
and
handled
in
the
last
project
since
the
1.0
release,
and
they
vary
a
lot
in
severity
from
just
low
severity
vulnerabilities
in
cargo.
We
disclosed
last
month
to
this
extreme
to
this
really
nice
buffer
overflow
in
the
standard
library,
because
standard
Library
uses
unsafe
rust
and
in
some
parts,
and
so
vulnerabilities
happen
there
as
well,
even
though
it's
trust
them
and
for
this
talk,
I
want
to
pick
a
specific
one.
A
There
is
condition
in
remove
the
role,
which
was
a
vulnerability
that
we
disclosed
earlier
this
year
and
I
want
to
use
it
as
an
example
for
how
we
handle
vulnerabilities
to
have
an
Amazon
approach
so
first
off
what
was
that
vulnerability?
I
want
to
give
a
bit
more
context
so
that
the
what
we
so?
What
we
do
makes
sense
they
removed
it
all
function
in
the
standard
library
is
meant
to
remove
a
directory
and
all
its
child
content.
A
And
crucially,
it
does
not
follow
Sim
links.
So
if
inside
the
director,
you
have
a
SIM
link
to
a
different
directory,
the
function
will
remove
the
sim
link
itself,
not
the
contents
of
the
directory
disabling
points
to,
and
that's
a
really
important
guarantee,
because
it
prevents
a
lot
of
security,
vulnerabilities
that
plague
Sim
links
and,
unfortunately,
that
wasn't
properly
implemented,
and
it
was
possible
with
a
race
condition,
to
trick
the
function
into
removing
an
arbitrary
director
on
the
system.
A
The
prop
the
problem
appears,
if
you,
if
you
can
take
a
privileged
program
into
removing
a
director,
you
can
you
control
so
like
a
system
demon
or
else
at
your
ID
program
like
sudo.
In
those
cases,
you
will
be
able
to
do
a
lot
of
damage
to
the
system
from
an
unprivileged
user
and
that's
where
the
vulnerability
is
lies.
A
So,
of
course,
the
first
phase
is
US.
Knowing
that
we
have
this
vulnerability
and
receiving
a
report,
this
vulnerability
was
reported
To
Us
by
Anne
scratch,
and
how
did
he
report
it
turn?
Well,
it's
explained
in
our
security
policy.
The
security
policy
for
us
is
a
document
that
explains
where
to
report
vulnerabilities,
how
we
will
handle
them.
What's
the
user
response
time
and
how
things
will
work
once
you
report
things
to
us
and
having
such
a
document
is
very
important,
because
every
project
naturally
treats
vulnerabilities
differently
and
does
different
processes.
A
So
it's
really
important
for
security
researchers
to
know
exactly
what
to
report
and
in
general,
security
policies
should
include
where
and
how
to
report
vulnerabilities,
maybe
via
email
with
the
hacker
one
or
other
other
things.
What
the
expectation
of
the
response
time
is,
and
also
if
the
project
has
a
backup
Bounty,
is
really
important
to
include
the
scope
and
possible
rewards
of
the
bounty,
but
bounties
are
a
way
for
companies
to
reward
security.
A
Every
time
you
open
an
issue
on
GitHub,
there
is
a
link
to
the
security
policy
and
that's
something
you
can
configure
with
issue
templates
and
once
you
receive
the
report,
it's
crucial
to
acknowledge
quickly
and
a
lot
acknowledgment
for
us
simply
means
okay,
we
received
the
report.
We
will
look
at
it
soon
and
let
you
know
once
we
find
more
results
and
that's
because
that's
virtual
reasons,
one
is
such
an
expectations
on
where
on
when
the
reporter
can
receive
a
response
because
like
for
us
that
varies
a
lot.
A
If
we
receive
a
critical
security
vulnerability,
we'll
drop
everything
we
do
and
focus
on
it
if
it's
a
low
security,
a
low
impact
thing
we'll
do
it
in
the
next
day,
but
also
it
signals
to
the
reporter
that
they
actually
emailed
their
correct
place,
because
maybe
the
mail
got
through
the
spam
filter.
Maybe
that
made
box
is
not
me
monitored
anymore.
So
it's
important
for
them
to
know
that
there
it's
the
correct
place.
A
A
This
is
hard
because,
especially
for
libraries,
assessing
the
impact
means
assessing
how
users
can
use
that
library
and
where
it
could
go
wrong,
and
occasionally
we
miss
things
like
really
early.
In
our
assessment,
we
discovered
that
this
vulnerability
was
also
publicly
reported
on
the
rust
issue
tracker
and
after
digging
a
bit.
It
was
reported
in
issue
tracker
because
or
they
it
was
sent
I
think
in
2018
to
the
security
contact.
A
It
wasn't
something
that
everyone
was
aware
in
that
moment.
If
Instead
This
was
a
vulnerability
that
appeared
all
right
that
was
discussed
for
a
whole
day
already
the
day
before,
then
we
probably
wouldn't
trade
it
as
something
we.
The
security
response
working
group
handles
so
this
is
not
a
hard
rule
that
if
it's
public,
we
want
handle
it,
but
it
depends
as
everything,
but
also
it
was
trivial
to
find
vulnerable
code
for
this,
like
that.
That
was
actually
a
really
good
coincidence.
A
I
got
access
to
the
GitHub
called
search
private
beta
the
day
before
and
by
the
way,
it's
great
a
request.
Access
for
it
is
so
useful
and
so
I
said,
like
I,
didn't,
have
a
chance
to
try
it.
Let's
try
searching
for
a
movie
role
and
set
your
ID
and
literally
the
first
resultant
was
metazo
the
right
of
Mercurial
in
Rasta
and
that
river
right
included
a
saturated
binary
that
called
remove
the
role
on
a
user
control
path.
A
So,
like
little
in
five
minutes,
I
was
able
to
find
vulnerable
code,
and
this
is
not
to
say
the
code
was
bad.
The
code
made
assumptions
that
the
standard
Library
had
ear
to
its
contract,
but
it
wasn't-
and
this
really
prompted
us
to
say:
okay,
let's
do
this
as
a
hype
impact
vulnerability,
not
because
it
was
metascon.
A
A
A
The
next
step,
of
course,
was
writing
and
reviewing
the
fix.
We
do
code
reviews
for
all
the
fixes,
they
don't
happen
in
public
pool
requests,
but
we
they
are
still
reviewed
them,
and
this
problem
was
actually
surprisingly
hard
to
fix,
because
we
didn't
have
to
write
a
fix.
We
had
to
write
three
of
them
because
the
standard
Library
uses
a
lot
of
low
level
operating
systems
API
and
the
implementation
for
Unix
like
Windows
and
Wazi.
A
A
You
add
a
security
vulnerability,
but
there
is
this
extremely
useful
feature
to
start
a
temporary
private
Fork
which,
which
security
advisories
you
can
create
a
private
Fork
of
your
repository
inside
the
same
organization
when
you
can
collaborate
on
the
fixes
in
a
private
repository
and
that's
really
convenient,
and
also
it
has
a
feature
to
request.
Cv
IDs,
even
though
I'll
talk
about
that
later.
So
we
use
use
this
feature
to
collaborate
on
the
fixer
and
get
it
to
a
state
where
it's
ready.
A
The
next
state
next
thing
was
drafting
a
security
advisory,
and
this
is
also
like
the
while
writing
the
fixer
and
reviewing
the
fix
was
something
that
the
domain
experts
did
from
now
on.
All
this
work
is
done
by
members
of
the
security
response.
Tracking
group
and
drafting
the
security
advisory
is
surprisingly
hard
because
you
need
to
strike
a
really
good
balance
between
providing
All
Tech,
all
the
technical
information
that
a
technical
person
can
use
to
fix
the
proper
the
plot
Problem
on
their
project.
A
But
it
also
needs
to
be
concise
so
that
a
person
reviewing
multiple
advisories
a
day.
Don't
waste
this
all
day
on
your
on
your
10-page
report
and
also
needs
to
be
understandable
by
people
that
are
less
Technical
and
just
need
to
see
if
their
product
might
be
affected
them
and
I'm
not
English
speak
I'm,
not
a
native
English
speaker.
So
at
least
for
me,
it
takes
a
bit
of
time
to
start
that
balance
but
yeah.
So
those
are
the
in
a
security
advisory.
A
You
need
to
make
sure
to
a
really
brief
overview
and
what
did
the
impact?
What
is
severity
and
the
possible
impact
of
the
vulnerability
is
of
mitigations,
so
how
users
can
solve
the
vulnerability
on
their
own
and
also
it's
really
important
to
acknowledge
who
worked
on
that
advisory,
because
that
builds
trust
in
your
security
project
in
your
security
program
and
allows
you
to
have
more
reporters
responsibly,
disclosing
things
to
you,
instead
of
just
passing
it
on
Twitter
and
surprising
everyone,
and
also
in
this
step.
A
We
need
to
do
the
final
evaluation
of
the
severity
which,
especially
for
libraries,
is
surprisingly
hard
to
do,
because
the
severity
we
handed
up
for
that
vulnerability
was
high.
If
you
use
the
function
in
privileged
contexts
where
you
are
the
user
control
paths
and
basically
low
To,
None.
Otherwise,
and
that's
something
you
can
write
in
Pros
in
The
Advisory.
A
Even
though,
for
most
users
is
North,
Korea
high
score,
and
but
that's
the
tools
standard
in
the
security
industry,
so
you
have
to
do
it
and
the
next
step
was
actually
requesting
a
CV
ID.
You
probably
saw
them
all
over
the
news
whenever
it
is
a
big
vulnerability,
they're
like
cve,
2022
and
then
an
unincremental
number
and
CVS
are
unique
IDs
for
vulnerabilities
that
anyone
can
get
literally
everyone.
A
A
You
can
search
for
and
see
all
the
relevant
information,
but
but
also
like
often
they're
not
requested
by
the
project
and
the
project
doesn't
even
know
about
them
and
that
that
can
create
some
confusion,
but
also
you
don't
need
to
be
afraid
to
request
a
CV
for
your
small
project
and
your
small
Library
CVS
are
free,
and
especially
with
GitHub,
it's
just
a
click
of
a
button
to
request
them
on
the
GitHub
security
advisories
you
once
you
feel
the
advisor.
You
click
the
report.
A
Button
GitHub
looks
at
it
before
it's
public
and
if
it's
actually
vulnerability-
and
you
are
not
just
brought
to
random
stuff-
they'll
assign
your
cvid
within
a
day
and
even
if
you
don't
use
GitHub
other
projects,
kind
of
science,
CV
numbers
and
worst
case,
you
can
go
to
Metra
the
com.
The
U.S
U.S
agency
handling
these
handling
CPUs
to
request
one
directly
from
them
and
they're
not
staying
in
your
project.
It's
not
like
approach.
It
is
worse
if
it
has
severe
ideas.
A
Actually,
my
opinion
is
better
because
it
signals
that
they
have
a
good
security
practice.
So,
even
if
you
have
a
small
crate
and
you
find
security
vulnerability,
please
request
CV
ideas,
it's
easy
and
it's
free.
And
finally,
there
was
a
big
step
of
disclosing
things
to
the
public,
which
is
kind
of
involved.
We
have
now
pretty
well
oiled
the
process,
but
there's
still
a
lot
of
steps
because,
first
off,
we
need
to
prepare
the
actual
Parts
files
that
will
be
applied
to
all
different
channels.
Last
time
it
supports
nightly
beta
and
the
latest
stable.
A
We
do
not
support
any
previous
table,
and
so
at
least
we
need
to
provide
patches
for
those
frame.
Occasionally
we
also
provide
patterns
for
older
versions,
depending
on
the
vulnerability,
but
preparing
patches
files
can
be
trivial
or
extremely
complex,
depending
on
what
the
vulnerability
is,
because
we
do
a
lot
of
refactorings
inside
the
rust
compiler,
and
so
the
code
might
be
completely
different
in
in
six
weeks.
A
And
finally,
we
just
published
The
Advisory,
and
so
we
have
multiple
places
where
we
do
that.
We
have
the
official
security
mailing
list,
the
rust
Blog,
the
GitHub
security
advisors.
You
saw
earlier
and
Twitter
and
after
that
we
need
to
prepare
the
actual
pointer,
at
least,
and
that's
currently
the
bad
thing
about
our
security
process,
because
there
are
still
at
least
infrastructure
can
only
release
when
the
source
code
is
public.
We
do
not
have
the
ability
to
pre-build
the
binaries
before
making
the
code
available,
and
that
means
we
can.
A
We
need
to
start
the
release
process
once
the
disclosure
happens
and
if
everything
goes
well,
which
it
doesn't
because
it's
CI
and
so
superior's
failures
happen.
We
once
we
publish
the
code,
we
can
get
our
release
out
in
four
hours
most
of
the
times,
it's
eight
or
nine
or
nine,
because
CI
face
Midway
and
that's
something
we're
slowly
working
to
improve,
but
that's
going
to
take
time
because
it
will
require
a
big
redesign
of
how
does
this
release,
though?
A
We
basically
accidentally
zero
date,
the
C
plus
plus
ecosystem,
and
for
those
who
don't
know
zero
Deng
is
when
you
publish
the
details
of
unvulnerability
without
letting
the
vendor
know,
and
in
this
case
we
didn't
let
the
C
plus
plus
ecosystem,
know
and
honestly,
because
we
didn't
think
we
didn't
think
of
it
at
the
time
and
turns
out
both
the
two
major
implementation
of
the
C
plus
plus
standard
template
library
and
also
the
Boost
Library,
were
also
affected
by
this
fix,
and
that's
not
ideal,
and
that's
something
we
are.
We
are
not.
A
What
doesn't
deserve
it
so
right
now
is
after
vulnerability
is.
If
we
think
it's
for
a
favor
bounty,
we
email
them
to
contact
TBB
and
get
the
money,
and
we
are
we're
planning
to
work
on
a
more
defined
policy
that
we
can
actually
publish,
and
once
that
will
be
done,
it
will
be
more
transparent
right
now.
We
have
a
lot
of
stuff
to
do.
A
This
is
the
step
less
effort
way
until
we
can
get
to
a
point
to
our
policy
and
also
these
might
be
a
bit
controversial,
but
we
recommend
it
to
the
reporter
to
notify
meta
about
its
vulnerability
before
the
Embargo
was
lifted
and
we
did.
The
last
project
did
not
notify
metadirectly.
We
recommended
to
the
reporter
to
do
that
and
that's
a
really
important
distinction,
because.
A
Like
there's
project
does
not
control
who
gets
to
know
about
vulnerabilities.
This
is
not
a
legal
rule.
This
is
an
informal
consensus
in
the
security
community
that
it's
up
to
the
reporter
to
have
the
final
say
home
who
gets
to
know
about
it,
and
we
just
made
a
recommendation
that
even
you
could
find
vulnerable
code
in
five
minutes
with
the
first
result
of
GitHub
concerts.
It
would
be
a
good
idea
to
notify
them
in
advance
not
of
the
whole
details
of
the
vulnerabilities,
but
just
that
there
will
be
a
release
on
that
date.
A
A
So
what
are
the
conclusion
of
how
of
this
talk,
and
what
can
you
take
away
from
it
for
stuff?
You
don't
have
to
do
this.
Much
work
for
your
project.
Rust
is
large
and
Rasta
has
a
need
for
this
complex
of
a
process
for
most
of
your
Formosa
small
crates,
small
libraries
and,
like
even
medium-sized
ones.
You
can
have
a
very
more
lightweight
processor
that
will
still
handle
things
good
and
for
the
rate
you
get
security
report
like
don't
expect
to
have
many.
A
In
fact,
any
of
them
in
a
year
so
like
what
I
can
recommend
to
most
projects
is
to
have
a
way
to
receive
security,
bug
reports
in
private
that
can
just
be
aligned
on
the
readme.
That
says,
if
you
have
a
security
concern,
please
email,
the
my
personal
email
address.
That's
fine
and
after
you
see
the
report,
you
can
Winger
the
rest
of
the
process
on
the
fly,
but
just
having
a
way
to
contact
you,
that's
not
opening
a
publish.
A
A
They
are
not
sustaining
your
project
and
they
help
everyone
working
on
the
security
ecosystem
and,
finally,
keep
in
mind
that
the
reporter
is
often
your
friend
putting
often
because
it's
the
internet
and
people
occasionally
are
not
your
friend,
but
the
reporter
is
the
person
that
probably
knows
the
most
about
the
vulnerability
in
that
moment,
because
if
they
found
it,
they
means
they
have
experience
on
that
class
of
vulnerabilities
and
it's
really
important
to
just
talk
with
them.
Keep
them
in
the
loop
and
maybe
have
them
review
your
fix.
A
They
can
provide
things
you
missed
or
more
suggestions
on
how
to
prevent
this
problem
for
happening
in
the
future,
and
when
there
is
this
collaboration,
everything
went
goes
well.
Of
course,
occasionally
reporters
goes
aggressive
and
whatever,
like
is
the
internet,
but
try
to
communicate
and
eat
things
go,
but
but
by
the
way,
so
I
want
to
acknowledge
everyone
who
worked
on
this
vulnerabilities,
both
the
two
reporters
that
also
helped
with
the
fix
for
Unix
lag
systems
going
back
to
the
involved,
reporters
and
also
the
domain
experts
liability
lead.
A
We
looked
in
and
everyone
on
the
security
response
working
group
at
the
time
who
worked
on
the
vulnerability
and
finally,
I
want
to
thank
both
the
employers
of
both
me
and
Josh
Stone
for
me,
fire
systems
and
for
just
fed
up
because
they're
letting
us
spend
the
work
time
to
handle
security
issues.
So
all
the
work
we
do
is
thankfully,
funded
by
those
two
companies
and
they
make
sure
that
their
ass
ecosystem
is
secure
by
letting
us
do
the
work
we
enjoy
to
handle
security
vulnerabilities
for
the
last
project.