Mastodawn

RE: https://infosec.exchange/@grsecurity/116575045401792453

We've just published a Knowledge Base article with more information about the vulnerability, current published/unpublished exploits, and current mitigations. We still recommend patching ASAP.

Show thread

grsecurity May 14

Multiple suid binary targets, please do not rely on individual ones you see posted as effective mitigations. Current exploits are only gaining read access to [/]etc[/]shadow, but can't guarantee read/write to something useful isn't possible.

grsecurity May 14

RE: https://infosec.exchange/@grsecurity/116574872357950375

Exploits are now appearing targeting pidfd, which is forced into all Linux kernels since 5.10 (2020), no module or initcall to blacklist this time, must patch ASAP!

Show thread

grsecurity May 14

@fossplant AFAIK we only linked it to someone in 2020 who had the problem it aims to solve: https://x.com/grsecurity/status/1223627189465362433 after having read about it recently at the time. We haven't used it ourselves. I'm sure it's a fine tool that does the job and I don't mean anything mean by this, just want to be clear on the recommendation wording.

grsecurity (@grsecurity) on X

@Darkarnium https://t.co/lG7yfD6gK5

X (formerly Twitter)

grsecurity May 14

RE: https://infosec.exchange/@grsecurity/116574524156524104

We've just sent a mail to all customers notifying them of this issue, with split-out fixes available for 5.15, 6.6, and 6.18. We'll share more information on our Knowledge Base as it becomes available.

Show thread

grsecurity May 14

The commit message makes no mention of it, but we believe the goal of exploiting the vulnerability would be to target a suid root binary that drops its privileges while retaining privileged access to a file on exit that via the vuln an unprivileged user could gain access to.

grsecurity May 14

We've uploaded new patches for 5.15, 6.6, and 6.18 to address an obfuscated upstream Linux logic vulnerability that should exist in all kernel versions: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=31e62c2ebbfdc3fe3dbdf5e02c92a9dc67087a3a

ptrace: slightly saner 'get_dumpable()' logic - kernel/git/torvalds/linux.git - Linux kernel source tree

grsecurity May 8

We've published a detailed KB article for customers on the two vulnerabilities involved in Dirty Frag and the associated public exploits, feel free to reach out with any questions.

Show thread

grsecurity May 1

@idkrn Usually prefer to mention things that are enabled by default and don't require configuration. In this RBAC case for instance, the policy is flexible and for backward compatibility reasons, subjects without connect/bind rules don't have socket family restrictions. A policy generated from full system learning shouldn't have this, but a later manual policy edit mistake could allow it.

Show thread

grsecurity May 1

@idkrn Sure, RBAC too, subjects with connect/bind rules automatically apply restrictions on socket families (limited to AF_UNIX/AF_INET). Any use of other socket families above that requires explicit sock_allow_family rules, so would block the AF_ALG use.