[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM=PXV60JrnGErsv1OHSdO_y46eTPVWV=miFVW7UYhhiHX7XzA@mail.gmail.com>
Date: Fri, 8 May 2026 11:50:01 -0600
From: Greg Dahlman <dahlman@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Re: Dirty Frag: Universal Linux LPE
So that people can at least add auditing:
While ideally you would have these set up for all of the PF/AF
families you don't expect, The following are probably low noise and
should be added to your audit logs so that your EDR and other security
tools can find them.
```
auditctl -a always,exit -F arch=b64 -S socket -F a0=33 -k pf_rxrpc
auditctl -a always,exit -F arch=b64 -S socket -F a0=38 -k pf_alg
```
The gnu bits/socket.h file is probably the easiest way to find most of
the numeric mappings, e.g.:
/usr/include/x86_64-linux-gnu/bits/socket.h
PF/AF 1,2,10,16,17 are the ones that most people would use, with
AF_VSOCK(40) as an exception that may be too noisy to log, along with
bluetooth on desktops etc...
IMHO, longer term, a bounding set in a text file in /etc of PF/AF
families that can be used on a system is the more maintainable and
robust solution in the end. socket() is just too tempting of an
interface, with no real security boundaries unless it is device/file
mediated. It should be blockable at the system level by PF/AF no
matter if it is loading a module or is compiled in at the system level
IMHO.
On Fri, May 8, 2026 at 10:12 AM Kalin KOZHUHAROV <kalin@...nrope.net> wrote:
>
> On Fri, May 8, 2026 at 6:39 AM Daniel Tang
> <danielzgtg.opensource@...il.com> wrote:
> >
> > > no patches [...] exist
> >
> Well patches will eventually come, but mitigation across the board hit
> a few snags already, so from my lessons learned I baked a script to
> apply the mitigation.
> Actually renaming the modules, not relying on modprobe config, since
> there are some distros that don't have that by default.
>
> After some initial testing and with GNU parallel as (often) last
> resort mass deployment tool, I just released it on
> https://github.com/thinrope/cf-df in the hope that I may save some
> minutes or hours of someones' job. The script itself is useful on its
> own, to be deployed via any configuration management system, or run by
> hand.
>
> Any feedback/issues/PR are welcome.
>
> Here is the README (reformatted to plaintext for clarity):
> ===================================================================
> https://github.com/thinrope/cf-df
> === copy.fail + Dirty Frag patching-on-the-fly ===
>
> Patch copy.fail[1] and Dirty frag[2] related CVEs
>
> == Why? ==
>
> I suddenly needed to patch a multitude of linux hosts in various
> platforms with minimal impact. I don't trust the suggested method of
> disabling module loading, I'd rather have the file renamed (or even
> deleted at some point).
>
> == How? ==
>
> Execute the cf+df_patching.sh script as root on any host. Use and
> configuration management system you have in place. Alternatively, for
> those odd mass cases, use the wonderful GNU parallel[5] from a central
> host via ssh (run as root, ssh as root[3,4]):
>
> git clone https://github.com/thinrope/cf-df.git
> cd cf-df
> $EDITOR target.list
> parallel --tag --nonall --slf target.list --workdir ... --transferfile
> cf+df_patching.sh --cleanup 'bash cf+df_patching.sh'
>
> == References ==
>
> [1] copy.fail: https://copy.fail/
> [2] Dirty frag: https://github.com/V4bel/dirtyfrag
> [3] If you cannot login via ssh directly as root, use sudo properly
> [4] ... or abuse these CVEs before you patch to obtain root :-D
> [5] GNU parallel: https://www.gnu.org/software/parallel/
> ===================================================================
>
>
> Regards,
> Kalin.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
