You are not logged in.

#1 2017-08-24 19:20:34

valoq
Member
Registered: 2017-08-24
Posts: 5

Mupdf-seccomp : A sandboxed PDF viewer

Hi everyone,

during a recent project I created a sandboxed version of the Mupdf PDF viewer that uses seccomp filter to reduce the number of allowed systemcalls by 90% and tries to restrict what the process can do to only the minimum necessary actions.

After reading somewhat into the PDF specifications, I noticed that this file format includes a ridicules amount of different complex media types that any PDF viewer needs to parse. Since this document format is used to exchange files with untrusted sources, it presents a huge attack vector and the number of exploits  that target PDF applications on Windows systems are a good example of this.

Mupdf-seccomp tries to reduce the risk of successful exploitation of parsing vulnerabilities in Mupdf.
For example: before the application parses a target PDF file, the syscall needed to open (network) sockets is blacklisted, therefore any access to the network is prevented.

AUR Package: https://aur.archlinux.org/packages/mupdf-seccomp/

I would appreciate any comments and suggestions for improvements.


Disclaimer: I am not the author of Mupdf. All credit for the core application goes to http://artifex.com

Last edited by valoq (2017-08-24 19:27:24)

Offline

#2 2017-08-24 20:02:46

cesura
Package Maintainer (PM)
From: Tallinn, Estonia
Registered: 2010-01-23
Posts: 1,867

Re: Mupdf-seccomp : A sandboxed PDF viewer

This is a pretty cool idea, and I'd like to see seccomp filtering incorporated into more and more pieces of software.

Did you have to alter any major functionalities of mupdf to get this working?

Offline

#3 2017-08-24 21:14:48

valoq
Member
Registered: 2017-08-24
Posts: 5

Re: Mupdf-seccomp : A sandboxed PDF viewer

itsbrad212 wrote:

Did you have to alter any major functionalities of mupdf to get this working?

No I did not. However there are some new limitations like opening external links not working any longer with networking disabled.

Also I have only tested support for PDF files. Since Mupdf can handle a lot more file formats, there is still a lot of room for improvements.


In regards to seccomp being incorporated into more and more software: Seccomp is not easy to handle and I think this will keep many from implementing it. With every change of a used library, the used syscalls can change.
I am still hoping for pledge to come to linux so we have something that is easier to implement and maintain. For more information on this topic look here: https://learnbchs.org/pledge.html

Offline

#4 2017-08-25 21:28:08

Uriel_Bernhard48
Member
Registered: 2017-08-08
Posts: 29

Re: Mupdf-seccomp : A sandboxed PDF viewer

You can do seccomp filtering within firejail.

Here's profile for mupdf:
https://github.com/netblue30/firejail/b … df.profile

For now it only uses common blacklist but example whitelist is also provided:
# seccomp.keep access,arch_prctl,brk,clone,close,connect,execve,exit_group,fchmod,fchown,fcntl,fstat,futex,getcwd,getpeername,getrlimit,getsockname,getsockopt,lseek,lstat,mlock,mmap,mprotect,mremap,munmap,nanosleep,open,poll,prctl,read,recvfrom,recvmsg,restart_syscall,rt_sigaction,rt_sigprocmask,select,sendmsg,set_robust_list,set_tid_address,setresgid,setresuid,shmat,shmctl,shmget,shutdown,socket,stat,sysinfo,uname,unshare,wait4,write,writev

Offline

#5 2017-08-27 13:42:22

valoq
Member
Registered: 2017-08-24
Posts: 5

Re: Mupdf-seccomp : A sandboxed PDF viewer

Uriel_Bernhard48 wrote:

You can do seccomp filtering within firejail.

Here's profile for mupdf:
https://github.com/netblue30/firejail/b … df.profile

For now it only uses common blacklist but example whitelist is also provided:
# seccomp.keep access,arch_prctl,brk,clone,close,connect,execve,exit_group,fchmod,fchown,fcntl,fstat,futex,getcwd,getpeername,getrlimit,getsockname,getsockopt,lseek,lstat,mlock,mmap,mprotect,mremap,munmap,nanosleep,open,poll,prctl,read,recvfrom,recvmsg,restart_syscall,rt_sigaction,rt_sigprocmask,select,sendmsg,set_robust_list,set_tid_address,setresgid,setresuid,shmat,shmctl,shmget,shutdown,socket,stat,sysinfo,uname,unshare,wait4,write,writev

Yes you can use firejail (I actually commited parts of the profile you mentioned)
However firejail is a large program with quite some security issues (e.g. local privilege escalation) in the past https://www.cvedetails.com/vulnerabilit … ejail.html
I believe firejail needs an overhaul of the way privileges are gained, e.g. like bubblewrap does. This change in firejail has already been planned for quite some time and it might get better in the future, but at the moment I am not sure if it actually decreases the risk.

Also, by implementing the seccomp filter into the application itself you can restrict the used syscalls right before the parsing happens. This makes it possible to restrict even more syscalls and enhance security.

Last edited by valoq (2017-08-27 13:43:25)

Offline

#6 2017-08-27 16:42:09

Uriel_Bernhard48
Member
Registered: 2017-08-08
Posts: 29

Re: Mupdf-seccomp : A sandboxed PDF viewer

Yeah, implementing seccomp into individual apps is great but it's a lot of work which nobody does (except you big_smile ). With firejail you can harden hundreds of apps. It has support for apparmor and x11 out of the box. Firejail vulnerabilities (now fixed) were mostly about abusing it to gain local root, not sandbox escapes especially with most hardened profiles.

If you take into account scalability and development pace there is nothing comparably to firejail I think.

BTW: did you proposed your changes to mupdf upstream?

Last edited by Uriel_Bernhard48 (2017-08-27 16:50:46)

Offline

#7 2017-08-27 19:45:04

valoq
Member
Registered: 2017-08-24
Posts: 5

Re: Mupdf-seccomp : A sandboxed PDF viewer

Uriel_Bernhard48 wrote:

Yeah, implementing seccomp into individual apps is great but it's a lot of work which nobody does (except you big_smile ). With firejail you can harden hundreds of apps. It has support for apparmor and x11 out of the box. Firejail vulnerabilities (now fixed) were mostly about abusing it to gain local root, not sandbox escapes especially with most hardened profiles.

If you take into account scalability and development pace there is nothing comparably to firejail I think.

I'm not saying its a bad project. I have contributed a lot of time to the project after all and I think it has at least brought some attention on the issue of linux desktop security.
However local root exploits are no joke either and running with suid (firejail never drops privileges for good) is still questionable (hopefully this can be fixed in the future).

Uriel_Bernhard48 wrote:

BTW: did you proposed your changes to mupdf upstream?

Yes, however there was no response from the developers. Considering that seccomp takes a lot of work and testing they probably want to focus on other features.

Last edited by valoq (2017-08-27 19:55:15)

Offline

Board footer

Powered by FluxBB