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

441–450 of 545 posts

Re: Copy Fail

#441

Post by akdev1l »

john_strinlai wrote: post #231
akdev1l wrote: post #215

Earlier quoted context omitted.

what the blog says and what the code does are two different things. For all I know the blog itself is a honey pot. I need to know what the code does before I run it.

> 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?

Re: Copy Fail

#442

Post by parliament32 »

j16sdiz wrote: post #434
parliament32 wrote: post #426

Note that in kubernetes, setting `allowPrivilegeEscalation` to false (which you should be doing already, it's in the Pod Security Standards Restricted profile) mitigates this.

according to this reddit post https://www.reddit.com/r/kubernetes/comments/1szn6p1/comment... ? > the primary mitigation is still patching the node kernel; user namespaces are blast-radius reduction, not a complete mitigation for this path

allowPrivilegeEscalation is unrelated to user namespaces. Many vendors do not yet have kernel patches available, but yes that'll eventually be the proper fix.

Re: Copy Fail

#443

Post by edelbitter »

markhahn wrote: post #314
MarleTangible wrote: post #89

Earlier quoted context omitted.

Seems like distros consider it a medium risk because it doesn't involve remote code execution and requires local access. Though it allows local root privilege escalation which is considered high priority. https://ubuntu.com/security/cves/about#priority > Medium: A significant problem, typically exploitable for many users. Includes network daemon denial of service, cross-site scripting, and gaining user privileges.

if your model is that linux is just about single-user desktops, this local exploit isn't too bad. or if your model is nothing but DB servers or the like. mystifying to me that shared, multi-user machines are not thought of. for instance, I administer a system with 27k users - people who can login. even if only 1/10,000 of them are curious/malicious/compromised, we (Canadian national research HPC systems) are at risk.…

Ubuntu is not really targeting multi-user any more. Security update installation is deliberately delayed for all users, until at some point all unprivileged users ended all processes launched from the vulnerable snap image. (Firefox RPC breaks when you replace the binary, so having to reopen your browser to keep opening tabs simple because security upgrades were applied in the background would be inconvenient)

Re: Copy Fail

#444

Post by TZubiri »

ebiggers wrote: post #232

As someone who works on the Linux kernel's cryptography code, the regularly occurring AF_ALG exploits are really frustrating. AF_ALG, which was added to the kernel many years ago without sufficient review, should not exist. It's very complex, and it exposes a massive attack surface to unprivileged userspace programs. And it's almost completely unnecessary, as userspace already has its own cryptography code to use. Th…

YAGNI stocks are rising, Gentoo devs that compile their own kernel probably yeeted this module. Alpine, and MUSL deviants are probably immune to this downswing.

DRY looking very bearish, do repeat yourself, do build your own, do use userspace tools even if the kernel has its own version. Not as big a hit on the DRY philosophy as those pip and npm supply chain attacks last couple of weeks though.

KISS remains unaffected for the time being.

Re: Copy Fail

#445

Post by kuhsaft »

fsflover wrote: post #341

As usual, Qubes is not vulnerable, since by its design, any untrusted software runs in dedicated VMs with hardware virtualization. Meanwhile, recent Xen CVEs also do not affect Qubes, as usual, https://www.qubes-os.org/news/2026/04/28/xsas-released-on-20...

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/1272 commit fafe0fa2995a of the kernel mirror

Currently stable version of QubeOS does not have the patched kernels. https://yum.qubes-os.org/r4.3/current/dom0/fc41/rpm/

Re: Copy Fail

#446

Post by dataflow »

1970-01-01 wrote: post #427
arcfour wrote: post #233

Earlier quoted context omitted.

LPE is a very well-known acronym within the security community, it's not purely academic or obscure or anything. I agree that it would be a good idea to define it explicitly when writing for a broader audience, but I don't think it's particularly egregious that they didn't. It's certainly something I could see myself forgetting. Then again, the whole writeup appears to be AI-generated, so...

It is nowhere near this. There are very few acronyms in the IT world that are actually well-known outside of it. LPE is less well-known than LVAD or MCU. https://www.acronymfinder.com/Information-Technology/MCU.htm... https://www.acronymfinder.com/LVAD.html https://www.acronymfinder.com/Information-Technology/LPE.htm...

> LPE is less well-known than LVAD or MCU.

I knew what LPE stands for but not the others. (I've seen MCU mentioned and kinda had a vague feeling for what it is. Never even seen LVAD.)

Re: Copy Fail

#448

Post by TZubiri »

parliament32 wrote: post #426

Note that in kubernetes, setting `allowPrivilegeEscalation` to false (which you should be doing already, it's in the Pod Security Standards Restricted profile) mitigates this.

They have a setting for that?

That's crazy, feels like prompting "make no mistakes" to the llm.

If it works, when would you want it turned on? Why isn't false the default

Re: Copy Fail

#449

Post by busterarm »

staticassertion wrote: post #274
smaudet wrote: post #273

Earlier quoted context omitted.

You should re-evaluate your probabilities, I too have heard frequently of CVEs, but never of an LPE.

I'm sure lots of people have heard of CVEs, but have you actually read many? LPE is an extremely common term. It's like not knowing RCE. These are the terms used.

I'm as stunned as you are. I have to read CVEs on a weekly cadence (like contractually required to) and LPE/RCE are kind of the main keywords we look for in them. Also increasingly TOCTOU. If anyone who actually has to respond to CVEs told me they had never seen these terms before I would judge them as being unserious.

Re: Copy Fail

#450

Post by dataflow »

staticassertion wrote: post #246
hackernudes wrote: post #226

Earlier quoted context omitted.

I've read many CVEs (somehow that acronym is ok... heh) but have never seen LPE despite being familiar with the concept.

That seems literally borderline impossible.

I think they've almost certainly seen it written out, just not as an acronym. I figured out what it stood for based on context and knowing the full phrase, but I don't recall actually seeing the LPE acronym in recent memory. Whereas with CVE it's the opposite: I almost never see it written out, and even now find it non-obvious what the E stands for, bizarrely enough.
Post reply on HN