Bug 231479 (CVE-2021-42762) - [WPE][GTK] Limited sandbox escape via VFS syscalls
Summary: [WPE][GTK] Limited sandbox escape via VFS syscalls
Status: RESOLVED FIXED
Alias: CVE-2021-42762
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-10-09 11:39 PDT by Michael Catanzaro
Modified: 2021-10-20 15:32 PDT (History)
10 users (show)

See Also:


Attachments
Patch (15.91 KB, patch)
2021-10-11 10:27 PDT, Michael Catanzaro
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 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.
Comment 1 Radar WebKit Bug Importer 2021-10-09 11:39:24 PDT
<rdar://problem/84064163>
Comment 2 Michael Catanzaro 2021-10-11 10:27:16 PDT
Created attachment 440804 [details]
Patch
Comment 3 Patrick Griffis 2021-10-11 12:25:42 PDT
Where and how is Syscalls.h used? Maybe I missed it.
Comment 4 Michael Catanzaro 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)
Comment 5 Michael Catanzaro 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.
Comment 6 Michael Catanzaro 2021-10-15 08:09:25 PDT
Ping reviewers
Comment 7 Adrian Perez 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 🤷‍♂️️
Comment 8 EWS 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].
Comment 9 Michael Catanzaro 2021-10-19 08:04:34 PDT
I've requested a CVE.
Comment 10 Michael Catanzaro 2021-10-20 12:48:37 PDT
We received CVE-2021-42762.