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.

1. Playing in the sandbox
Guillaume Emont - Igalia
guijemont@igalia.com

2. I. What do we want to solve?

3. Internets = cute videos of [insert favourite animal]

4. Trustworthy?

5. Complex software written by
human beings can have bugs.

8. Ophiocordyceps unilateralis

9. The piece of software that
handles untrusted video:
• is not evil in itself
• should be considered evil when
it starts to handle untrusted data

10. 1. Take resources
2. Drop privileges
3. Handle dodgy data

11. II. Experimentations

12. sandboxeddecodebin

14. 1. Take resources => ->READY
2. Drop privileges
3. Handle dodgy data => ->PAUSED->PLAYING

15. Issues:
• resources acquired when going to PAUSED
• clean up

16. 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

17. Other big limitations:
• no upstream communication => no seeking
• overhead: 720p ogg/theora on my i5: 20-30% -> 30-40% cpu

18. III. Usable sandbox implementations on Linux

19. 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

20. Seccomp
• only read(), write(), exit(), sigreturn()
• applied to a thread
• in kernel since 2.6.10

21. Seccomp + BPF
• filters on syscalls and their arguments
• libseccomp to make it easier
• in kernel since 3.5

22. SELinux
•
•
•
•
by process
quite fine grained
rules set by administrator/distribution, developers
not standard

23. IV. Going Forward

24. Better IPC: GstPadProxy, GstElementProxy & friends
=> control over a remote pipeline

25. Put the whole pipeline process in the sandbox
=> shouldn't be complicated with a granular sandbox

26. Architecture that is agnostic
to the sandboxing system used

27. Performances: profile, optimise

28. Thank You
guijemont@igalia.com
http://guij.emont.org/blog/
https://github.com/guijemont/Sandboxed-Player
Image Credits:
Sandbox: Public Domain by Hyena http://en.wikipedia.org/wiki/File:Sandpit.jpg
beer: CC BY-NC-SA 2.0 Martin Ibert http://www.flickr.com/photos/mar_ibert/
zombie ant: CC BY 2.5 http://en.wikipedia.org/wiki/File:Ophiocordyceps_unilateralis.png
bug: CC BY 2.0 by ThreeHeadedMonkey http://www.flickr.com/photos/threeheadedmonkey/3856171871/