WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
231479
CVE-2021-42762
[WPE][GTK] Limited sandbox escape via VFS syscalls
https://bugs.webkit.org/show_bug.cgi?id=231479
Summary
[WPE][GTK] Limited sandbox escape via VFS syscalls
Michael Catanzaro
Reported
2021-10-09 11:39:13 PDT
Flatpak just disclosed a nice zero day in our sandbox:
https://github.com/flatpak/flatpak/security/advisories/GHSA-67h7-w3jq-vh4q
There is a massive warning comment in flatpak-run.c to make sure anyone editing their seccomp filters knows they need to coordinate with other projects that share the same filters before disclosing vulnerabilities, but... well, it didn't happen. Oh well. To prevent this from happening again, we need to split the affected code out of flatpak so that it becomes more obvious that it is shared with multiple projects:
https://github.com/flatpak/flatpak/issues/4466
. Anyway, the problem is the web process can delete the .flatpak-info file that we create in the root of its filesystem namespace. That's not intended, and we do need to request a CVE (I'll do this next week), but it's probably not the end of the world either, as nobody seems to be able to immediately think of anything that could directly go wrong. Certainly it's not a normal full sandbox escape. The web process doesn't have direct D-Bus access, so it can't talk directly to desktop portals -- those look for .flatpak-info in the filesystem namespace of the xdg-dbus-proxy process, which is trusted -- so the badness seems to be limited to communication via Unix sockets that are mounted inside the sandbox, which hopefully do not trust their peers anyway. That said, we do need to address this by copying the recent changes to flatpak's sandbox filters into WebKit. We also need to stay tuned to future changes to the flatpak filters.
Attachments
Patch
(15.91 KB, patch)
2021-10-11 10:27 PDT
,
Michael Catanzaro
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2021-10-09 11:39:24 PDT
<
rdar://problem/84064163
>
Michael Catanzaro
Comment 2
2021-10-11 10:27:16 PDT
Created
attachment 440804
[details]
Patch
Patrick Griffis
Comment 3
2021-10-11 12:25:42 PDT
Where and how is Syscalls.h used? Maybe I missed it.
Michael Catanzaro
Comment 4
2021-10-11 12:44:07 PDT
Comment on
attachment 440804
[details]
Patch It's used by SCMP_SYS. I found its definition in seccomp.h: #define SCMP_SYS(x) (__SNR_##x)
Michael Catanzaro
Comment 5
2021-10-11 12:45:59 PDT
Comment on
attachment 440804
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=440804&action=review
> Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp:737 > + { SCMP_SYS(clone3), ENOSYS, nullptr },
E.g. this line here...
> Source/WebKit/UIProcess/Launcher/glib/Syscalls.h:114 > +#ifndef __SNR_clone3 > +# define __SNR_clone3 __NR_clone3 > +#endif
...might depend on this definition here.
Michael Catanzaro
Comment 6
2021-10-15 08:09:25 PDT
Ping reviewers
Adrian Perez
Comment 7
2021-10-18 15:48:52 PDT
Comment on
attachment 440804
[details]
Patch Seccomp is about the worst possible ever design for such a feature (for comparison, check pledge/unveil in OpenBSD and marvel!), but we have no other remedy than to live with it 🤷♂️️
EWS
Comment 8
2021-10-19 07:27:26 PDT
Committed
r284451
(
243211@main
): <
https://commits.webkit.org/243211@main
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 440804
[details]
.
Michael Catanzaro
Comment 9
2021-10-19 08:04:34 PDT
I've requested a CVE.
Michael Catanzaro
Comment 10
2021-10-20 12:48:37 PDT
We received CVE-2021-42762.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug