Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Copy Fail

copy.fail

Post reply on HN
Print view View original

481–490 of 545 posts

Re: Copy Fail

#481

Post by kuhsaft »

fsflover wrote: post #456
kuhsaft wrote: post #445

Earlier quoted context omitted.

You know that Xen is just a hypervisor right? Dom0 (the admin Qube) is running the Linux kernel and is vulnerable like any other Linux system. DomU (App Qubes) also run the Linux kernel and are just as vulnerable. You can check your DomU kernels using this guide: https://doc.qubes-os.org/en/latest/user/advanced-topics/mana... If your Dom0 or DomU is running kernel https://github.com/QubesOS/qubes-linux-kernel/pull/12…

> Dom0 (the admin Qube) is running the Linux kernel and is vulnerable Yes, it is vulnerable, except there is no attack vector, as you don't run any software there: https://doc.qubes-os.org/en/r4.3/user/downloading-installing... > DomU (App Qubes) also run the Linux kernel and are just as vulnerable. I think you misinterpret the Qubes approach to security. If you do everything in one VM, you get no protection from the…

So, not being vulnerable is dependent on not doing something that can make you vulnerable? That doesn't seem right. If you can do something to make yourself vulnerable, you are vulnerable.

> https://www.qubes-os.org/news/2026/04/28/xsas-released-on-20...

Looking at just that small list, they mark some vulnerabilities as not vulnerable because it's "In-VM attack only". That's disingenuous.

> There is no way to use the discussed vulnerability, if one uses Qubes according to docs

It's like saying you're not vulnerable to cutting yourself with a knife, as long as you use it correctly.

You can say your risk is low, but you can't say you're not vulnerable.

---

> Moreover, there is no sudo password by design

The POC uses `/usr/bin/su`, but that's besides the point.

The vulnerability itself can affect other things. The POC just used root-privilege escalation as an example.

https://access.redhat.com/security/cve/cve-2026-31431

RedHat states "This could lead to data integrity issues or unexpected behavior during cryptographic operations, impacting the reliability of encrypted communications for local users." as the impact.

Re: Copy Fail

#482

Post by 1vuio0pswjnm7 »

The "default exploit" would not work for me as there is no python nor /usr/bin/su on the computer I'm using

Failed to meet the assumptions I guess

NB. I'm only referring to the "default exploit" not the vulnerability itself

Re: Copy Fail

#483

Post by krunck »

1vuio0pswjnm7 wrote: post #482

The "default exploit" would not work for me as there is no python nor /usr/bin/su on the computer I'm using Failed to meet the assumptions I guess NB. I'm only referring to the "default exploit" not the vulnerability itself

Any Setuid binary will work: passwd, chsh, chfn, mount, sudo, pkexec.

Re: Copy Fail

#484

Post by otherme123 »

bool3max wrote: post #470
martin- wrote: post #382

Earlier quoted context omitted.

Sometimes that effort is better spent on other things.

It's not the effort or the lack thereof here that's the issue, but rather the message you're sending by using slop tools to create the design of the advertisement of your research. It looks cheap. I'm sure that, at first glance, many more people would take this much more seriously had the authors gone with a style-less HTML page or something, and that'd require _less_ effort, not more.

I have heard this logic before, defending over-engineering the looks to hide a brittle backed. Both sides look very entrenched on their position, I lean more towards having a solid backend and see the polished frontend as a waste of effort, but I understand your logic of seeing it as professionalism. My point is that you are not sending only one message by using a cheap slop static html: some will see lazy and cheap people, some will see people focusing on the real thing with no time or willingness to make shiny sites.

Re: Copy Fail

#485

Post by stefanor »

baggy_trough wrote: post #471
stefanor wrote: post #466

Earlier quoted context omitted.

As far as we can tell, nobody disclosed it to the distributions, only to the kernel security team (who did not reach out to distributions). So the distributions are all scrambling now. Good lesson in how not to do disclosure.

Why wouldn't the kernel security team reach out to distributions?

The Linux project's view is that almost all kernel bugs are security vulnerabilities. They don't treat something like this as anything special.

I can understand that PoV, but it doesn't fit with distributions' approach to security. So, in practice, one has to reach out to distributions individually, or use distros lists on openwall.org to coordinate with all distros.

Re: Copy Fail

#486

Post by zepearl »

bombcar wrote: post #202
nh2 wrote: post #92

Earlier quoted context omitted.

On a git repo that has as remotes https://github.com/torvalds/linux.git https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git as remotes: running a search for commit a664bf3d603d's commit message: git log --all --grep 'crypto: algif_aead - Revert to operating out-of-place' '--format=%H' | xargs -I '{}' git tag --contains '{}' | sort -u outputs these tags as having the fix: v6.18.22 v6.18.23 v6.18.24 v6.18.…

Here's the diff if you wanna play in your source (Gentoo, looking at you): https://github.com/torvalds/linux/commit/a664bf3d603d 6.18.25-gentoo-x86_64 has the patch for Gentoo.

Thanks a lot!!!

I was running in Gentoo "6.18.18" (amd64) and the exploit worked (and all other shells which I PREVIOUSLY opened could then just execute "su -" without password to become "root") -> doing temporarily a "modprobe -r algif_aead" on-the-fly did not fix it as I was still able to swap to "root" from the unprivileged user by executing just "su -".

"6.18.25" fixed it (module "algif_aead" still running).

- Maybe older Kernel versions that don't contain the fix should be blacklisted?

- FYI in Gentoo I had to recompile "sys-fs/zfs-kmod" after the minor kernel upgrade (I initially skipped it, but after rebooting with the new kernel I could not mount my raidz1) -> the same might be needed for other external modules.

Re: Copy Fail

#487

Post by SoftTalker »

a96 wrote: post #399
globular-toast wrote: post #351

Earlier quoted context omitted.

Sure, but the target audience of copy.fail is surely not the security community but regular sysadmins who probably don't otherwise follow as closely.

I would absolutely expect a sysadmin in particular to know and understand the term and acronym.

It's still just courteous to define acronyms on first use, it doesn't take any real effort to do that.

Re: Copy Fail

#488

Post by john_strinlai »

akdev1l wrote: post #441
john_strinlai wrote: post #231

Earlier quoted context omitted.

> I need to know what the code does before I run it. its literally code meant to exploit your system. you should be running it in an environment built for that already . you dont test exploit pocs on your daily driver.

> you dont test exploit pocs on your daily driver. Do you just like making fake points and pretending other people said them?

go ahead and explain your point, rather than be cryptic, if you you want to have an actual conversation about it.

you said "I need to know what the code does before I run it.".

you know its an LPE. the mechanisms of the exploit are fully explained. what more do you need to know? please imagine yourself in the position of the kernel security team who would have received this poc in the first place when you answer, because that is the intended context of the poc.

if you think the kernel security team is going to get tripped up over "os as g", you have a crazy low view of the team.

Re: Copy Fail

#489

Post by pixel_popping »

Orygin wrote: post #403
otherme123 wrote: post #398

Earlier quoted context omitted.

I hope they sell a lot of Xint Code licenses, so they don't have to sell their findings.

Considering they kinda botched the disclosure to Linux distros, I guess they wanted something most sensational to sell more licenses.

strategically botched ;)

Re: Copy Fail

#490

Post by pixel_popping »

chromacity wrote: post #230
jesse_dot_id wrote: post #190

Good thing nobody is silly enough to let fully autonomous AI agents run as regular users on these affected operating systems. That could be disastrous given a zero day prompt injection technique.

I don't see what the issue is, my agent is already running as root.

As it should for full yolo_O
Post reply on HN