Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

specconv: do not permit null bytes in mount fields #3287

Merged
merged 1 commit into from
Nov 19, 2021
Merged

specconv: do not permit null bytes in mount fields #3287

merged 1 commit into from
Nov 19, 2021

Conversation

cyphar
Copy link
Member

@cyphar cyphar commented Nov 18, 2021

Using null bytes as control characters for sending strings via netlink
opens us up to a user explicitly putting a null byte in a mount string
(which JSON will happily let you do) and then causing us to open a mount
path different to the one expected.

In practice this is more of an issue in an environment such as
Kubernetes where you may have path-based access control policies (which
are more susceptible to these kinds of flaws).

Found by Google Project Zero.

Fixes: 9c44407 ("Open bind mount sources from the host userns")
Reported-by: Felix Wilhelm [email protected]
Signed-off-by: Aleksa Sarai [email protected]

@cyphar cyphar added this to the 1.1.0 milestone Nov 18, 2021
kolyshkin
kolyshkin previously approved these changes Nov 18, 2021
Copy link
Contributor

@kolyshkin kolyshkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

thaJeztah
thaJeztah previously approved these changes Nov 18, 2021
Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

one suggestion, but probably ok to take this as-is (feel free to merge if we're fine with the current implementation)

strings.Contains(mnt.Source, "\x00") ||
strings.Contains(mnt.Device, "\x00") ||
strings.Contains(mnt.Data, "\x00") {
return nil, errors.New("mount field contains null byte")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it be useful to include which field (for users to debug what's wrong)?

In we think it's useful, we could do a loop over the fields, and check each one

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That said; it would still return the first error (unless we always check all of them), so usefulness may be limited

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is more of a security measure, and less a mechanism to tell the user to correct something. If there's a null byte in there, something is very wrong.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah the main reason for doing this in specconv is to make sure we always reject such configurations, rather than only rejecting them when we hit the actually attack-prevention check in bootstrapData.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it was mostly a nit; I don't think "security measure" and "informative/detailed" error is mutually exclusive, but this situation should be a corner-case, so not really worth spending too much time on to make it "nice".

@kolyshkin kolyshkin added backport/1.0-todo A PR in main branch which needs to be backported to release-1.0 and removed backport/1.0-todo A PR in main branch which needs to be backported to release-1.0 labels Nov 18, 2021
Using null bytes as control characters for sending strings via netlink
opens us up to a user explicitly putting a null byte in a mount string
(which JSON will happily let you do) and then causing us to open a mount
path different to the one expected.

In practice this is more of an issue in an environment such as
Kubernetes where you may have path-based access control policies (which
are more susceptible to these kinds of flaws).

Found by Google Project Zero.

Fixes: 9c44407 ("Open bind mount sources from the host userns")
Reported-by: Felix Wilhelm <[email protected]>
Signed-off-by: Aleksa Sarai <[email protected]>
@cyphar cyphar dismissed stale reviews from thaJeztah and kolyshkin via dde509d November 19, 2021 00:41
Copy link
Contributor

@kolyshkin kolyshkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@AkihiroSuda AkihiroSuda merged commit eba6097 into opencontainers:master Nov 19, 2021
@cyphar cyphar deleted the netlink-embedded-nulls branch November 19, 2021 06:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants