Use of kernel crypto lib

Use of kernel crypto lib

[Alexander Monakov]

[-- Attachment #1: Type: text/plain, Size: 1523 bytes --]

Hi,

I raised the topic of inappropriate use of kernel crypto lib for
certchain validation in IWD and was told it was discussed previously. I
do not see such threads in the archives (but at the moment archives
before September 2019 are not available).

To me this design looks poorly justified. IWD seems to basically use the
kernel crypto API as a normal crypto library, just running with kernel
privileges. The kernel code is evidently imperfect, and IWD is basically
short-cutting any defense-in-depth measures that could have been in
place by feeding certificates presented by random APs to the kernel.

I don't want to get a kernel oops (or worse) by simply walking past by
an "evil" access point.

If history tells us that ASN.1 parsing code usually has mistakes, then
applying also the principle of least privilege I expect certificate
validation to run in a seccomp'ed child subprocess of IWD, not the
kernel.

I don't buy the comparison against signed modules offered on IRC. A random
webpage I visit cannot trivially elevate itself to root to attempt to
load a module with crafted signature. IWD's use strikes me as reckless
to put it mildly.

(there's also the "patch-the-kernel-to-use-IWD" angle, which is less
important, but still: whenever kernel crypto lib doesn't cut it, the
user has to upgrade the kernel or ditch IWD; in my adjacent thread it
happened due to leaf cert not following RFC, but it could plausibly
happen with completely valid certificates as well)

Alexander

Re: Use of kernel crypto lib

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 2582 bytes --]

Hi Alexander,

> I raised the topic of inappropriate use of kernel crypto lib for
> certchain validation in IWD and was told it was discussed previously. I
> do not see such threads in the archives (but at the moment archives
> before September 2019 are not available).
> 
> To me this design looks poorly justified. IWD seems to basically use the
> kernel crypto API as a normal crypto library, just running with kernel
> privileges. The kernel code is evidently imperfect, and IWD is basically
> short-cutting any defense-in-depth measures that could have been in
> place by feeding certificates presented by random APs to the kernel.
> 
> I don't want to get a kernel oops (or worse) by simply walking past by
> an "evil" access point.
> 
> If history tells us that ASN.1 parsing code usually has mistakes, then
> applying also the principle of least privilege I expect certificate
> validation to run in a seccomp'ed child subprocess of IWD, not the
> kernel.

every user has access to the Keys subsystem in the Linux kernel and can load whatever certificate they want. So I don’t buy this argument. Frankly any ANS.1 parsing that is vulnerable is an issue here since by definition a WiFi daemon has to run with pretty much root privileges. Even on a Linux with a recent systemd (where we take as much privileges away as possible), there is still a large risk for overtaking the daemon. That is also the reason why we generally limited our daemons to a single process (LimitNPROC=1) since if they can’t spawn any other process, they also don’t get into being a shell. And consistent usage of CLOEXEC will quickly trigger a watchdog killing the process.

Anyhow, no system is prefect and neither are any TLS libraries.

> I don't buy the comparison against signed modules offered on IRC. A random
> webpage I visit cannot trivially elevate itself to root to attempt to
> load a module with crafted signature. IWD's use strikes me as reckless
> to put it mildly.

No, not more reckless than any other daemon that has to run as root.

> (there's also the "patch-the-kernel-to-use-IWD" angle, which is less
> important, but still: whenever kernel crypto lib doesn't cut it, the
> user has to upgrade the kernel or ditch IWD; in my adjacent thread it
> happened due to leaf cert not following RFC, but it could plausibly
> happen with completely valid certificates as well)

I still have to see a TLS library that is any good and that seamlessly integrates with hardware crypto and TPMs. So please enlighten us here.

Regards

Marcel

Re: Use of kernel crypto lib

[Alexander Monakov]

[-- Attachment #1: Type: text/plain, Size: 2821 bytes --]

I was curious about IWD enough to try it, and it seems my investigation
helped to uncover a previously unknown compatibility issue. However, I'm not
happy with what I see, so probably I'm not going to use IWD on a regular
basis. I'll address individual points below:

On Sat, 1 May 2021, Marcel Holtmann wrote:

> every user has access to the Keys subsystem in the Linux kernel and can
> load whatever certificate they want. So I don’t buy this argument.

That is a strange reference to make. I am the only human user on my laptop,
and software I run (except IWD) is not going to load certificates obtained
from an untrusted network device to a keyring. For example, when I browse
the web, the browser is not giving websites sufficient access to do that.
And that is probably true for most users of IWD.

> Frankly any ANS.1 parsing that is vulnerable is an issue here since by
> definition a WiFi daemon has to run with pretty much root privileges.

As I said, with seccomp it's possible to confine risky computations to an
unprivileged subprocess.

> Even on a Linux with a recent systemd (where we take as much privileges
> away as possible), there is still a large risk for overtaking the daemon.
> That is also the reason why we generally limited our daemons to a single
> process (LimitNPROC=1) since if they can’t spawn any other process, they
> also don’t get into being a shell. And consistent usage of CLOEXEC will
> quickly trigger a watchdog killing the process.

Yes, as you say a properly sandboxed daemon will deal less damage: an
adversary might not possess enough exploits at the same time to break
through all the mitigations. That is why short-cutting through all such
counter-measures with in-kernel certificate validation is a big issue.

> Anyhow, no system is prefect and neither are any TLS libraries.

Agreed, and that is why I want to see risky processing of untrusted network
input in a minimally privileged userspace instead of kernelspace.

> > I don't buy the comparison against signed modules offered on IRC. A random
> > webpage I visit cannot trivially elevate itself to root to attempt to
> > load a module with crafted signature. IWD's use strikes me as reckless
> > to put it mildly.
> 
> No, not more reckless than any other daemon that has to run as root.

I don't see other daemons do in kernelspace what they could more safely
do in userspace.

> I still have to see a TLS library that is any good and that seamlessly
> integrates with hardware crypto and TPMs. So please enlighten us here.

I wouldn't mind the use of kernel crypto API when it's justified, but in
this case I see no benefit, and a few downsides like unnecessary risks and
highly complicated debugging, pushed by IWD on its users.

Thanks.
Alexander