Dirty Frag: a zero-day universal Linux LPE

> Because the embargo has currently been broken, no patch or CVE exists. After consultation with the
> maintainers on linux-distros@vs.openwall.org and at their request, this Dirty Frag document is being
> published. For the disclosure timeline, refer to the technical details.

In other words, the publication of this information was done in consultation with, and at the request of, the kernel and distro security groups - not something that deserves to be called "stupidity". Particularly given there's a pretty simple mitigation (blacklisting and removing the vulnerable modules).

They ought to have held their feet still until patches are available.

Even if someone else “broke embargo”, just publish mitigations (block kernel modules X, Y and Z or W) until then.

If you can reasonable assume that an exploit is unknown to others, it can make sense to keep it secret until patches deployed. However, if there is only a slight realistic chance that an exploit is known to other, less benevolent actors, it becomes paramount to thoroughly inform the users. You should give them all the information and tools so they can apply mitigations, do some risk analysis and tests for their specific setup, or even just identify and take vulnerable systems offline.

Intentionally not informing your users if your product puts them in danger is objectively malevolent behavior – up to the point that in other contexts that can even lead to legal consequences (rightfully so).

* people that find issues, report it responsibly and organise a coordinated release
* people that watch the stream of committed patches and publish exploits on any bugs fixed

These groups are always going to interfere with each-other, basically water and fire. I suspect these two groups already have a wildly different idea of the value of embargos and coordinated releases and so don't communicate. I expect the result will be the victory of the second group over the first.

You can have a look at git clone https://android.googlesource.com/platform/system/sepolicy, in particular private/app_neverallows.te.

# Restrict socket ioctls. Either 1. disallow privileged ioctls, 2. disallow the
# ioctl permission, or 3. disallow the socket class.
neverallowxperm all_untrusted_apps domain:{ icmp_socket rawip_socket tcp_socket udp_socket } ioctl priv_sock_ioctls;
neverallow all_untrusted_apps *:{ netlink_route_socket netlink_selinux_socket } ioctl;
neverallow all_untrusted_apps *:{
socket netlink_socket packet_socket key_socket appletalk_socket
netlink_tcpdiag_socket netlink_nflog_socket
netlink_xfrm_socket netlink_audit_socket
netlink_dnrt_socket netlink_kobject_uevent_socket tun_socket
netlink_iscsi_socket netlink_fib_lookup_socket netlink_connector_socket
netlink_netfilter_socket netlink_generic_socket netlink_scsitransport_socket
netlink_rdma_socket netlink_crypto_socket sctp_socket
ax25_socket ipx_socket netrom_socket atmpvc_socket x25_socket rose_socket decnet_socket
atmsvc_socket rds_socket irda_socket pppox_socket llc_socket can_socket tipc_socket
bluetooth_socket iucv_socket rxrpc_socket isdn_socket phonet_socket ieee802154_socket caif_socket
alg_socket nfc_socket kcm_socket qipcrtr_socket smc_socket xdp_socket
} *;

Note that those "neverallow" rules are a fail-safe: Even if some other rules allows one of those things, they will still be denied.