FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756
2012 S&P Paper Reading Session1
1. S&P
2012
Paper
Reading
Session
1:
System
Security
Chong-‐Kuan
Chen
2. Outline
1. A
Framework
to
Eliminate
Backdoors
from
Response-‐Computable
AuthenHcaHon
2. Safe
Loading-‐A
FoundaHon
for
Secure
ExecuHon
of
Untrusted
Programs
3. ReDeBug:
Finding
Unpatched
Code
Clones
in
EnHre
OS
DistribuHons
3. A
Framework
to
Eliminate
Backdoors
from
Response-‐Computable
Authen<ca<on
Shuaifu
Dai,
Tao
Wei,
Chao
Zhang,
Tielei
Wang,
Yu
Ding,
Zhenkai
Liang,
Wei
Zou
Beijing
Key
Lab
of
Internet
Security
Technology
University
of
California,
Berkeley
5. IntroducHon
• Formalize
authenHcaHon
model
• Classify
backdoor
to
response-‐computable
authenHcaHon
(RCA)
• Propose
new
RCA
framework
to
eliminate
backdoors
6. AuthenHcaHon
Model
• The
basic
authenHcaHon
model
• Two
class
of
authenHcaHon
model
– Direct
compare
user
response
and
respected
response,
response-‐computable
authenHcaHon
(RCA)
– User
response
involves
in
authenHcaHon
progress
8. Backdoor
A[ack
Model
• The
a[acker
has
chance
to
modify
develop
progress
but
cannot
interfere
deployment
environment
• A[acker
cannot
intercept
code
review
and
tesHng
process.
• OperaHng
system
is
trusted.
• Password
database
is
trusted
• Examples
of
backdoor
– VSFTPD
2.3.4
Backdoor
– Thompson’s
compiler
backdoor
9. Type
of
Backdoor
• type
T1
:
bypass
response
comparison
– Depends
on
user
input(U-‐trigger
backdoor)
– Depends
on
global
states(G-‐trigger
backdoor)
– Depends
on
internal
states(I-‐trigger
backdoor)
• Type
T2
:
controlling
computaHon
of
expected
response
– Type
T2a
backdoor's
response
computaHon
depends
on
informaHon
other
than
challenge
and
password
– Type
T2b
is
response
computaHon
collision-‐based
backdoor
10. Proposed
Scheme
• This
RCA
framework
include
– Explicit
response
comparison
– FuncHon
purificaHon
– Backdoor
usability
tesHng
11. Explicit
Response
Comparison
• Decouple
verificaHon
process
– Response
computaHon
– Response
comparison
• Explicit
Response
Comparison
– Response
comparison
compare
user
response
and
respect
response
only
• This
step
can
eliminate
T1
backdoor
12. FuncHon
purificaHon
• Pure
funcHon’s
characters
– Without
side
effects
– DeterminisHc
• This
step
ensure
response
computaHon
is
a
pure
funcHon
– Only
challenge
and
password
involve
in
response
computaHon
• NaPu
components
employ
a
funcHon
level
sandbox
– Global
state
isolaHon
– Internal
state
reset.
• Acer
this
step
T2a
backdoors
are
eliminated.
13. Backdoor
usability
tesHng
• This
step
use
collision
tesHng
– Use
sampling
to
check
collision
probability
– find
out
high
collision
algorithms
• Eliminated
T2b
backdoors.
16. Safe
Loading-‐AFounda<on
for
Secure
Execu<on
of
Untrusted
Programs
Mathias
Payer,
Tobias
Hartmann
and
Thomas
R.
Gross
ETH
Zurich,
Switzerland
17. Outline
• IntroducHon
• Background
– Socware-‐based
fault
isolaHon
– Binary
TranslaHon
– Policy-‐based
system
call
authorizaHon
• A[ack
Vector
To
Loader
– ExploiHng
the
standard
loader
– The
late
intercepHon
problem
– The
loader
black
box
• Proposed
Scheme
• EvaluaHon
18. IntroducHon
• SFI
was
deployed
widely
to
secure
program
execuHon
• Standard
loader
exposes
secure
risk
to
escape
SFI
• This
paper
replaces
standard
loader
by
secure
loader
out
of
sandbox
to
eliminate
a[ack
to
loader
19. Socware-‐based
Fault
IsolaHon
• Socware-‐based
fault
isolaHon(SFI)
has
been
proposed
to
secure
program
execuHon
• With
FFI
framework,
many
security
features
can
be
implement
– ASLR,
DEP,
stack
canaries
• Most
of
SFI
frameworks
employ
following
technique
– Binary
TranslaHon
– Policy-‐based
system
call
authorizaHon
21. Policy-‐based
System
Call
AuthorizaHon
• Policy-‐based
system
call
authorizaHon
– System
call
trace
from
sandbox
– Pre-‐defined
policy
– To
make
decision
if
the
system
call
can
be
executed
22. A[ack
Vector
to
Loader
• ExploiHng
the
standard
loader
• The
late
intercepHon
problem
• The
loader
black
box
23. ExploiHng
the
standard
loader
• Increasing
complexity
of
standard
loader
bring
in
security
risk
– Preload
alternate
libraries
– Replace
the
standard
search
path
– Escalate
privileges
24. The
Late
IntercepHon
Problem
• ApplicaHon,
BT
and
loader
share
the
same
memory
space
– Loader
may
leak
memory
layout
informaHon
– Break
integrity
of
the
BT
25. The
Loader
Black
Box
• In
previous
work,
loader
is
the
black
box
and
translated
as
applicaHon
– ApplicaHon
must
has
privileges
to
load
code
– Sandbox
has
no
informaHon
about
memory
layout
26. Safe
Loading
• A
lightweight
secure
loader
and
move
secure
loader
into
sandbox
27. Privilege
Separate
• Divide
applicaHon
into
two
domain
– Sandbox
domain
and
applicaHon
domain
• Sandbox
domain
(secure
loader
and
sandbox)
– Ensure
only
checked
code
loaded
• ApplicaHon
domain
– Indirect
control
flow
transfer
will
be
checked
by
sandbox
domain
28. SoluHon
to
Standard
Sandbox
• RestricHng
Privilege
EscalaHon
A[ack
– Secure
loader
only
need
to
relocate
code
and
thus
reduce
a[ack
vector
• ProtecHng
All
Executed
ApplicaHon
Code
• Opening
the
Loader
Black
Box
31. ReDeBug:
Finding
Unpatched
Code
Clones
in
EnHre
OS
DistribuHons
Jiyong
Jang,
Abeer
Agrawal,
and
David
Brumley
Carnegie
Mellon
University
32. IntroducHon
• Patch
is
the
standard
process
to
fix
and
update
buggy
code
• Code
clone
is
ocen
appear
in
OS
distribuHon
– Bad
programming
style
– Independent
of
sub-‐component
– It
is
hard
to
discover
code
clones
in
OS
• This
paper
propose
system
finding
unpatched
code
clones
in
OS-‐distribuHon
33. Example
of
Code
Clone
• CVE-‐2009-‐3720
is
exploit
discovered
and
fixed
in
2009
• But
the
same
code
clone
appear
386
Hmes
across
Debian,
Ubuntu
package
34. Related
Work
• Most
previous
work
like
MOSS,
CCFinde
– DetecHon
all
code
clone
in
system
– Not
scale
enough
to
OS
level
– Language-‐dependent
35. ReDeBug
• This
paper
propose
ReDeBug
system
to
find
code
clone
– Flexible
scalability
– Language
agnosHc
– Lower
false
detecHon
rate
• ReDeBug
find
code
clone
by
folowing
steps
– Pre-‐process
the
source
to
construct
source
database
– Check
for
unpatched
code
copies
– Post-‐process
to
find
exactly
matching
code
37. Pre-‐process
1. Performs
normalizaHon
and
tokenizaHon
2. Moves
an
n-‐length
window
over
the
token
stream.
For
each
window,
the
resulHng
n-‐
tokens
are
hashed
into
a
Bloom
filter
3. Stores
the
Bloom
filter
for
each
source
file
in
a
raw
data
format
38. NormalizaHon
• Each
line
as
a
basic
unit
– Remove
comments
– Non-‐ASCII
characters
– Redundant
whitespace
and
newline
– Convert
to
lower
case
39. TokenizaHon
• Slides
a
window
of
length
n
– Every
n
consecuHve
unit
will
use
to
compare
– Following
are
sample
where
n=2
1
2
3
4
5
1
2
2
3
3
4
4
5
41. Check for Unpatched Code Copies
1. Extracts
the
original
code
snippet
and
the
c
tokens
of
context
informaHon
from
the
pre-‐
patch
source
2. Normalizes
and
tokenizes
the
extracted
original
buggy
code
snippets
3. Hashes
the
n-‐token
window
into
a
set
of
hashes
4. Bloom
filter
set
membership
test
42. Post-‐process
1. Performs
an
exact-‐matching
test
2. Excludes
dead
code
3. reports
only
non-‐dead
code
to
the
user
