131–140 of 152 posts
What is happening? I see multiple outages and CVEs is being reported on HN's front page. I've never seen these many security/incident related posts on HN's front page.
io-uring is a security nightmare. Constant privescs and a powerful primitive for syscall smuggling. Worth considering disabling it outright (already the case for most containers afaik).
Earlier quoted context omitted.
That's significantly more challenging for an LLM (and a human)
I would caution against thinking it's difficult for an LLM. I've used them in raw data file analysis and they are frequently shockingly good at pulling structures and meaning out of seemingly random data. Disassembled binaries already are structured, so pulling code flow out of that is easier. Mixing that with existing disassembly and inspection tooling and an LLM has what is needed to fast track this kind of vulnera…
Earlier quoted context omitted.
Right. `CAP_SYS_ADMIN` is for all intents and purposes equivalent to root.
No, not since namespacing came around.
If a kernel feature is gated on cap_sys_admin only, it doesn't matter at all what namespace it is in. Namespace support or additional constraints are not implicit and have to be added to each need.
People misunderstanding this is partially why we have this latest crop of vulnerabilities.
high privilege access required (CAP/NET admin), containers / sandboxing wins once again. Can we make sandboxing the new default now? Flatpak does a good job, but we're still pretty far away for apt/yum/pacman installed packages. AppArmor was a decent step forward, but clearly not enough.
io-uring is a security nightmare. Constant privescs and a powerful primitive for syscall smuggling. Worth considering disabling it outright (already the case for most containers afaik).
I was reading similar comments about AF_ALG which lead to the copy-fail exploit. Could we see a trend of moving away from less used tools/modules that expand the vulnerability footprint?
And sorry, but I am ... frustrated by this. Why do my Debian 11 servers (currently upgrading, yes) have support for phone infrastructure from the 90s (ATM), or really obscure file systems like "Andrews File System" or support to run IP across amateur radios (AX.25) by default? We recently joked that we should start a pot you add a euro to whenever you find ancient discontinued tech you never heard about our systems support so we can have some nice dinner after this.
I do understand that going full Gentoo or Arch as a generally available distro is not feasible. I am also personally intimidated by compiling my own kernel with just what we need. But the amount of strange ancient things supported by default is also quite ridiculous.
io-uring is a security nightmare. Constant privescs and a powerful primitive for syscall smuggling. Worth considering disabling it outright (already the case for most containers afaik).
I was reading similar comments about AF_ALG which lead to the copy-fail exploit. Could we see a trend of moving away from less used tools/modules that expand the vulnerability footprint?
That said, putting stuff in a docker container is kinda a light lift that cuts a bunch of attack surface.
Let's see... That's 4 Linux LPEs in the last 10 days? Copy Fail [1] Copy Fail 2: Electric Boogaloo [2] Dirty Frag [3] And now this... [1]: https://copy.fail [2]: https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boo... [3]: https://github.com/V4bel/dirtyfrag
This one is a level less severe.
> Affected: Linux 6.15 – 6.19 [...] Fix: commit 770594e (not yet in any stable branch at time of writing). Is it considered good pactice to publish a vulnerability not yet patched in any stable branch?
CAP_NET/SYS_ADMIN is required for this. So this would be "not as bad" as the others.
It is very important that you realize that any capability is a slice of superuser privileges, and there are no implicit protections, only explicit additional constraints that restrict it in reference to root.
Look at the bounding set for a normal user on a fresh install of rhel/debian based systems:
$ grep ^Cap /proc/$$/status
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
$ podman unshare
# grep ^Cap /proc/$$/status
CapInh: 0000000000000000
CapPrm: 000001ffffffffff
CapEff: 000001ffffffffff
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
# capsh --decode=000001ffffffffff
0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore
But capabilities are just a thread local segmentation, which grants superuser or root rights in a vertical segmented fashion.
True, if a mechanism chooses to do additional tests based on credentials(7)[1], you can run with those elevated privileges in a lower bound, but that requires implicit coding.
Add in that LSMs are suffering from both resources and upstream teams that won't provide guidance or are challenging to work with, and there are literally a hundred commands to either abuse or just ld_preload to get unrestricted userns, allowing you to get around basic controls on clone()/unshare() that may be implemented.
$ grep -ir "userns," /etc/apparmor.d/ | wc -l
100
If you run `busybox` on a debian system, note how it has nsenter and unshare, so you can't mask those and yet busybox itself is unconstrained with elevated privlages.
The TL;DR point being, don't assume that any capability() is in itself a gate, as there are so many ways even for the user nobody to gain them.
[0] https://man7.org/linux/man-pages/man7/capabilities.7.html [1] https://man7.org/linux/man-pages/man7/credentials.7.html