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.
AI is happening.
I was promised that ai was just a stochastic parrot
You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)
141–150 of 152 posts
Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)
#142[flagged]
And you see a lot of other languages being used to create operating systems with complicated multiprocessor and locking semantics?
It's been almost half as long since the operating system under discussion as it has been since the creation of the language under the discussion, and there haven't really been any new mainstream operating systems created since then. I don't think it's nearly as obvious as you're implying that if there were a new operating system created today that C would be a good choice for it. If we're talking about non-mainstream OS's, then I'd argue there's already more than enough evidence that safer languages than C are more than capable of it[1]
Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)
#143Earlier quoted context omitted.
> "No way to prevent this", Says Only Language Where This Regularly Happens clang -fbounds-safety ... also see lib0xc etc.: https://news.ycombinator.com/item?id=47978834
NOTE: This is a design document and the feature is not available for users yet. https://clang.llvm.org/docs/BoundsSafety.html
It has been available in Apple's version[1] for several years, and it appears to be migrating into upstream as well.
On macOS you can try it with:
clang -Xclang -fbounds-safety program.c
Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)
#144Earlier quoted context omitted.
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?
We at work are currently going through the kernel modules available on Debian by default and deactivating things, yes. 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…
You're kind of making my point. Perhaps we will see a trend where support for many things are not available by default and need to be installed as needed. Linux doesn't need to come with support for this and that (like AX.25) when it can be installed in seconds if truly needed. Doesn't OpenBSD already take this approach?
Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)
#145high 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.
I am pretty sure that Flatpak does 'not' do a good job when it comes to sandboxing, maybe one day.
does it not? I know dbus is a problem that they can't really do much about except disabling it and wayland solved display based escalation.
Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)
#146Earlier quoted context omitted.
Right. `CAP_SYS_ADMIN` is for all intents and purposes equivalent to root.
No, not since namespacing came around.
No, that depends on the kind of privilege check.
Some codepaths do ns_capable() (must have capability in owning namespace, reachable via unprivileged user namespaces), some do capable() (must have capability in host user namespace, not reachable via user namespaces at all).
ZCRX can only be enabled by passing capable(CAP_NET_ADMIN), so you need to be privileged on the host.
Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)
#147CAP_NET/SYS_ADMIN is required for this. So this would be "not as bad" as the others.
It is a minimal improvement due to the introduction of user namespaces and the fallout from local team convenience for Docker and thus OCI. 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/d…
1. The privilege check in question here is capable(CAP_NET_ADMIN), so it doesn't work in user namespaces.
2. Most sandboxes (including Docker and Podman) disable creating unprivileged user namespaces inside them via seccomp. In this mode, you end up with a more secure setup than requiring a privileged process to spawn containers (for one, it massively reduces the risk of confused deputy attacks against container runtimes). You can also restrict it with ucounts (as rough of a system as that is).
3. The kernel provides this facility and the feature was added back in early 2013 (before Docker existed and long before they added user namespace support, let alone rooless containers), so I don't understand why you think this is somehow the fault of OCI? We're just making something useful out of existing kernel infrastructure. Folks have asked the kernel to provide a knob to disable unprivileged user namespaces but the maintainer has refused to do so for years (the best you get is ucounts and seccomp). I would also prefer to have such a knob (or even adding a separate ucount with configurable per-user limits) but it's not up to me.
(Disclaimer: I implemented rootless containers for runc back in the day and work on OCI, so I do have some bias here.)
Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)
#148Earlier quoted context omitted.
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…
I forgot who it was, but someone on YouTube said LLMs already work hooked up to gidra. If true it's only a matter of time once they find similar things in e.g. Windows. I'll wait half a year to a year (think of embargo) and if there still isn't such work for Windows I'll conclude that LLMs have a problem disassembling binaries.
If I was NSA I'd heavily use this feature on my farm in Utah :^)
Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)
#149Earlier quoted context omitted.
Anyone care to share which models and which prompts actually lead to finding these kinds of vulnerabilities? Or the narrowing-down workflow that can get an LLM to discover them? Surely just telling claude "Find all vulnerabilities in this project LOL" isn't enough? I hope?
The Anthropic researchers have said their flow is as simple as: 1. Pick a file to seed as a starting place. 2. Ask the LLM (in an agent harness) to find a vulnerability by starting there. 3. If it claims to have found something, ask another one to create an exploit/verify it/prove it or whatever. 4. If both conclude there is a vuln, then with the latest models you almost certainly found something real. Just run it ag…
What kind of money are we talking about with regards to the tokens?
Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)
#150Earlier quoted context omitted.
I forgot who it was, but someone on YouTube said LLMs already work hooked up to gidra. If true it's only a matter of time once they find similar things in e.g. Windows. I'll wait half a year to a year (think of embargo) and if there still isn't such work for Windows I'll conclude that LLMs have a problem disassembling binaries.
If I was NSA I'd heavily use this feature on my farm in Utah :^)
We should assume that multiple state actors already are using it.