BUG: Handling of multiple syscall arguments incorrect (CVE-2017-18367) #22
Assignees
Labels
Comments
|
I'm working on a fix for this, and hope to have it in ASAP |
|
Fixed by 06e7a29 |
|
Distributions who package snapd but use distribution packaging for the current upstream golang-seccomp release (0.9.0) hit this issue (see https://bugs.launchpad.net/snapd/+bug/1825052). I suggest producing a new release with this fix (eg 0.9.1) so downstreams can more easily pull in the patch. Since golang-seccomp is meant to be a golang package to facilitate reducing the syscall surface for applications and this bug produces incorrect BPF to achieve that when specifying more that 2 syscall arguments, this probably deserves a CVE assignment so distributions will see the issue and incorporate the fix into their stable releases. I have requested a CVE from MITRE for this issue. |
|
I think a 0.9.1 is appropriate to cut, both because of this and the handling for the 2.4.x library series' new features. |
|
Thanks! And yeah, 2.4.1 is much better with arg filtering :) |
|
@jdstrand thanks! @mheon if/when a CVE is assigned for this, please make sure this issue is update with the CVE information. I would suggest adding the CVE number to the issue title and adding a link in the comments. See seccomp/libseccomp#139 as an example. |
|
@pcmoore Ack, SGTM |
|
This is CVE-2017-18367. Reference: https://www.openwall.com/lists/oss-security/2019/04/24/3 |
pcmoore
changed the title
jdstrand
pushed a commit
to jdstrand/snapd
that referenced
this issue
Apr 25, 2019
Due to seccomp/libseccomp-golang#22, golang-seccomp <= 0.9.0 cannot create correct BPFs for this feature. The package does not contain any version information, but we know that ActLog was implemented in the library after this issue was fixed, so base the decision on that. ActLog is first available in 0.9.1.
jdstrand
pushed a commit
to jdstrand/snapd
that referenced
this issue
Jul 15, 2019
….9.0 libseccomp < 2.4 generates unpredicatable BPFs where at runtime the policy enforcement for argument filtered rules is sometimes wrong. The BPF generation is known to be sensitive to rule order and while the PFC is correct, a disassembly of the BPF indicates problematic logic that is also sensitive to the runtime environment. Incorrect enforcement was observed with secondary architectures and differing kernel versions across different distros. libseccomp 2.4 includes a rewrite of the BPF to, in part, better handle argument filtering and it now generates predictable BPFs (as seen from the PFCs and BPF disassemblies) without the problematic logic that is sensitive to runtime environments. (As an aside, it also orders the syscalls based on priorities, which should yield performance gains for snaps with heavy syscall use). As such, require that the 'system-usernames' features be dependent on snap-seccomp being compiled against libseccomp >= 2.4. Likewise, due to seccomp/libseccomp-golang#22, golang-seccomp <= 0.9.0 cannot create correct BPFs for this feature. The package does not contain any version information, but we know that ActLog was implemented in the library after this issue was fixed, so base the decision on that. ActLog is first available in 0.9.1. References: canonical#6681
jdstrand
pushed a commit
to jdstrand/snapd
that referenced
this issue
Jul 15, 2019
….9.0 libseccomp < 2.4 generates unpredicatable BPFs where at runtime the policy enforcement for argument filtered rules is sometimes wrong. The BPF generation is known to be sensitive to rule order and while the PFC is correct, a disassembly of the BPF indicates problematic logic that is also sensitive to the runtime environment. Incorrect enforcement was observed with secondary architectures and differing kernel versions across different distros. libseccomp 2.4 includes a rewrite of the BPF to, in part, better handle argument filtering and it now generates predictable BPFs (as seen from the PFCs and BPF disassemblies) without the problematic logic that is sensitive to runtime environments. (As an aside, it also orders the syscalls based on priorities, which should yield performance gains for snaps with heavy syscall use). As such, require that the 'system-usernames' features be dependent on snap-seccomp being compiled against libseccomp >= 2.4. Likewise, due to seccomp/libseccomp-golang#22, golang-seccomp <= 0.9.0 cannot create correct BPFs for this feature. The package does not contain any version information, but we know that ActLog was implemented in the library after this issue was fixed, so base the decision on that. ActLog is first available in 0.9.1. References: canonical#6681
jdstrand
pushed a commit
to jdstrand/snapd
that referenced
this issue
Jul 18, 2019
….9.0 libseccomp < 2.4 generates unpredicatable BPFs where at runtime the policy enforcement for argument filtered rules is sometimes wrong. The BPF generation is known to be sensitive to rule order and while the PFC is correct, a disassembly of the BPF indicates problematic logic that is also sensitive to the runtime environment. Incorrect enforcement was observed with secondary architectures and differing kernel versions across different distros. libseccomp 2.4 includes a rewrite of the BPF to, in part, better handle argument filtering and it now generates predictable BPFs (as seen from the PFCs and BPF disassemblies) without the problematic logic that is sensitive to runtime environments. (As an aside, it also orders the syscalls based on priorities, which should yield performance gains for snaps with heavy syscall use). As such, require that the 'system-usernames' features be dependent on snap-seccomp being compiled against libseccomp >= 2.4. Likewise, due to seccomp/libseccomp-golang#22, golang-seccomp <= 0.9.0 cannot create correct BPFs for this feature. The package does not contain any version information, but we know that ActLog was implemented in the library after this issue was fixed, so base the decision on that. ActLog is first available in 0.9.1. References: canonical#6681
jdstrand
pushed a commit
to jdstrand/snapd
that referenced
this issue
Jul 18, 2019
….9.0 libseccomp < 2.4 generates unpredicatable BPFs where at runtime the policy enforcement for argument filtered rules is sometimes wrong. The BPF generation is known to be sensitive to rule order and while the PFC is correct, a disassembly of the BPF indicates problematic logic that is also sensitive to the runtime environment. Incorrect enforcement was observed with secondary architectures and differing kernel versions across different distros. libseccomp 2.4 includes a rewrite of the BPF to, in part, better handle argument filtering and it now generates predictable BPFs (as seen from the PFCs and BPF disassemblies) without the problematic logic that is sensitive to runtime environments. (As an aside, it also orders the syscalls based on priorities, which should yield performance gains for snaps with heavy syscall use). As such, require that the 'system-usernames' features be dependent on snap-seccomp being compiled against libseccomp >= 2.4. Likewise, due to seccomp/libseccomp-golang#22, golang-seccomp <= 0.9.0 cannot create correct BPFs for this feature. The package does not contain any version information, but we know that ActLog was implemented in the library after this issue was fixed, so base the decision on that. ActLog is first available in 0.9.1. References: canonical#6681
jdstrand
pushed a commit
to jdstrand/snapd
that referenced
this issue
Jul 22, 2019
….9.0 libseccomp < 2.4 generates unpredicatable BPFs where at runtime the policy enforcement for argument filtered rules is sometimes wrong. The BPF generation is known to be sensitive to rule order and while the PFC is correct, a disassembly of the BPF indicates problematic logic that is also sensitive to the runtime environment. Incorrect enforcement was observed with secondary architectures and differing kernel versions across different distros. libseccomp 2.4 includes a rewrite of the BPF to, in part, better handle argument filtering and it now generates predictable BPFs (as seen from the PFCs and BPF disassemblies) without the problematic logic that is sensitive to runtime environments. (As an aside, it also orders the syscalls based on priorities, which should yield performance gains for snaps with heavy syscall use). As such, require that the 'system-usernames' features be dependent on snap-seccomp being compiled against libseccomp >= 2.4. Likewise, due to seccomp/libseccomp-golang#22, golang-seccomp <= 0.9.0 cannot create correct BPFs for this feature. The package does not contain any version information, but we know that ActLog was implemented in the library after this issue was fixed, so base the decision on that. ActLog is first available in 0.9.1. References: canonical#6681
jdstrand
pushed a commit
to jdstrand/snapd
that referenced
this issue
Jul 22, 2019
….9.0 libseccomp < 2.4 generates unpredicatable BPFs where at runtime the policy enforcement for argument filtered rules is sometimes wrong. The BPF generation is known to be sensitive to rule order and while the PFC is correct, a disassembly of the BPF indicates problematic logic that is also sensitive to the runtime environment. Incorrect enforcement was observed with secondary architectures and differing kernel versions across different distros. libseccomp 2.4 includes a rewrite of the BPF to, in part, better handle argument filtering and it now generates predictable BPFs (as seen from the PFCs and BPF disassemblies) without the problematic logic that is sensitive to runtime environments. (As an aside, it also orders the syscalls based on priorities, which should yield performance gains for snaps with heavy syscall use). As such, require that the 'system-usernames' features be dependent on snap-seccomp being compiled against libseccomp >= 2.4. Likewise, due to seccomp/libseccomp-golang#22, golang-seccomp <= 0.9.0 cannot create correct BPFs for this feature. The package does not contain any version information, but we know that ActLog was implemented in the library after this issue was fixed, so base the decision on that. ActLog is first available in 0.9.1. References: canonical#6681
jdstrand
pushed a commit
to jdstrand/snapd
that referenced
this issue
Jul 22, 2019
….9.0 libseccomp < 2.4 generates unpredicatable BPFs where at runtime the policy enforcement for argument filtered rules is sometimes wrong. The BPF generation is known to be sensitive to rule order and while the PFC is correct, a disassembly of the BPF indicates problematic logic that is also sensitive to the runtime environment. Incorrect enforcement was observed with secondary architectures and differing kernel versions across different distros. libseccomp 2.4 includes a rewrite of the BPF to, in part, better handle argument filtering and it now generates predictable BPFs (as seen from the PFCs and BPF disassemblies) without the problematic logic that is sensitive to runtime environments. (As an aside, it also orders the syscalls based on priorities, which should yield performance gains for snaps with heavy syscall use). As such, require that the 'system-usernames' features be dependent on snap-seccomp being compiled against libseccomp >= 2.4. Likewise, due to seccomp/libseccomp-golang#22, golang-seccomp <= 0.9.0 cannot create correct BPFs for this feature. The package does not contain any version information, but we know that ActLog was implemented in the library after this issue was fixed, so base the decision on that. ActLog is first available in 0.9.1. References: canonical#6681
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue originally identified at moby/moby#32714
Presently, when adding a rule with multiple syscall arguments, we add each argument separately with a separate call to
seccomp_rule_add_arrayand a single syscall specified. This produces an OR relationship between the arguments - IE, we will match if any of the arguments match.However, using
libseccompdirectly, adding multiple rules at the same time with a single API call will result in an AND relationship - the rule will only match if all of the arguments match.Matching the behavior of the library is important, and at present use cases requiring ANDing syscall rules are not supported.
The text was updated successfully, but these errors were encountered: