Playing in the sandbox - GStreamer security (GStreamer Conference 2012)


Published on

By Guillaume Emont.

GStreamer is a big and successful project that implements complex formats. We use it to read media streams that sometimes come from untrusted sources.

The size and complexity of GStreamer and all the format implementations it brings means that the presence of security bugs in a media playback pipeline is not totally unlikely. An attacker could forge a stream that would exploit such a bug so that he can execute code of his making in the context where the exploited code was running.

A common way to alleviate this kind of issue is to run the software handling untrusted data in a context where its privileges are very limited, so that a successful exploit of a bug in the software would only grant the attacker execution rights in that limited context. We call such a context a sandbox.

I have run some experiments[1] with setuid-sandbox[2], a stand-alone version of the sandboxing system used by chrome on GNU/Linux, that shows the feasibility of running at least part of a pipeline in a sandbox. In this talk, I will explain this work[3], its limitations and discuss what can be done to improve on it.

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Playing in the sandbox - GStreamer security (GStreamer Conference 2012)

  1. 1. Playing in the sandbox Guillaume Emont - Igalia
  2. 2. I. What do we want to solve?
  3. 3. Internets = cute videos of [insert favourite animal]
  4. 4. Trustworthy?
  5. 5. Complex software written by human beings can have bugs.
  6. 6. Ophiocordyceps unilateralis
  7. 7. The piece of software that handles untrusted video: • is not evil in itself • should be considered evil when it starts to handle untrusted data
  8. 8. 1. Take resources 2. Drop privileges 3. Handle dodgy data
  9. 9. II. Experimentations
  10. 10. sandboxeddecodebin
  11. 11. 1. Take resources => ->READY 2. Drop privileges 3. Handle dodgy data => ->PAUSED->PLAYING
  12. 12. Issues: • resources acquired when going to PAUSED • clean up
  13. 13. Potential solutions: • • • • finer grained sandbox modify elements to acquire everything at ->READY? add an all-resources-acquired signal? have a controlling process do the clean up
  14. 14. Other big limitations: • no upstream communication => no seeking • overhead: 720p ogg/theora on my i5: 20-30% -> 30-40% cpu
  15. 15. III. Usable sandbox implementations on Linux
  16. 16. Setuid-sandbox (CLONE_NEWPID + separate uid/gid + chroot) • • • • prevents access to data outside of chroot in kernel since 2.6.24 ideally needs a pool of UIDs/GIDs not very granular
  17. 17. Seccomp • only read(), write(), exit(), sigreturn() • applied to a thread • in kernel since 2.6.10
  18. 18. Seccomp + BPF • filters on syscalls and their arguments • libseccomp to make it easier • in kernel since 3.5
  19. 19. SELinux • • • • by process quite fine grained rules set by administrator/distribution, developers not standard
  20. 20. IV. Going Forward
  21. 21. Better IPC: GstPadProxy, GstElementProxy & friends => control over a remote pipeline
  22. 22. Put the whole pipeline process in the sandbox => shouldn't be complicated with a granular sandbox
  23. 23. Architecture that is agnostic to the sandboxing system used
  24. 24. Performances: profile, optimise
  25. 25. Thank You Image Credits: Sandbox: Public Domain by Hyena beer: CC BY-NC-SA 2.0 Martin Ibert zombie ant: CC BY 2.5 bug: CC BY 2.0 by ThreeHeadedMonkey