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

511–520 of 545 posts

Re: Copy Fail

#511

Post by zerocrates »

rkeene2 wrote: post #166
zerocrates wrote: post #146

Earlier quoted context omitted.

It being readable is the default configuration most places, after all the purpose is to call it from a non-privileged user. But I could see it being made non-readable since its use is discouraged nowadays... though then I'd expect sudo to be readable as an alternative.

My `sudo` is also not readable. Files/directories don't need to be readable to be executed. I can still use `su` and `sudo`.

Oh yeah, duh.

Still every machine I've looked at, and I've since looked at a couple more, has it r-x for world.

Re: Copy Fail

#512

Post by 14sea »

dezgeg wrote: post #285
comfydragon wrote: post #197

Earlier quoted context omitted.

It's a loadable module: CONFIG_CRYPTO_USER_API_AEAD=m Using bpftrace to watch calls to module_request, openat, etc., it looks like when the kernel calls modprobe, it doesn't even look at the disable-algif.conf file: [module_request] pid=3648 comm=python name=algif-aead [umh_setup] pid=3648 comm=python path=/sbin/modprobe argv0=/sbin/modprobe argv1=-q argv2=-- argv3=algif-aead argv4= [openat] pid=3688 file=/etc/ld.so.…

In wsl, each distro you have runs in a container (with lot of permissions), you'd need to apply the modprobe change inside wsl "hypervisor" rootfs

The only way to solve this issue in WSL is to rebuild your kernel:

~ uname -r

6.18.20.3-microsoft-standard-WSL2+

Re: Copy Fail

#513

Post by ozgrakkurt »

otherme123 wrote: post #484
bool3max wrote: post #470

Earlier quoted context omitted.

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…

You can make a simple and serious website pretty easily now. Don’t need the shiny part

Re: Copy Fail

#514

Post by plg94 »

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.

Understanding a term with the help of context is very different from guessing what the letters of an acronym might mean. The latter is more like a crosswords puzzle, and a totally unneccessary task for the reader.

Re: Copy Fail

#515

Post by plg94 »

staticassertion wrote: post #367
cynicalkane wrote: post #295

Earlier quoted context omitted.

I'll raise my hand here and risk downvotes from very smart people who are smarter than me, but I've heard of CVE but not LPE or RCE. I know what the latter two terms are but am not used to seeing them in acronyms. So what's missing is that keeping up-to-date with CVEs is important and some CVEs are Internet-nerd famous. Remember Heartbleed? Even some casual gamers I know had heard of it. And everyone who's mildly ser…

To be clear, I'm not suggesting that you if have heard of CVEs therefor you must have heard of LPE. I'm saying if you have read many of them you would have seen these terms. I obviously do not expect someone who has merely heard of various CVEs before to know anything about the contents of those CVEs. The other poster said they had "read many CVEs", which I took to mean they have read many CVE disclosures, where the…

some people just don't have a good memory for acronyms. It's one thing to learn the concept of a privilege escalation, but an entirely different thing to play mental memory with TLAs (three letter acronyms). Acronyms remove all the context from a term which makes them way harder to memorize. A bit like knowing your friends vs knowing their phone numbers.

Re: Copy Fail

#516

Post by xmcqdpt2 »

dwedge wrote: post #365
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.

Local access is a bit of a misnomer though, a vulnerable website can be tricked into running a script

True but that requires another vulnerability.

It's security in depth. You build your server in a way that it doesn't allow remote code execution, and then you run it with an unprivileged user so that if it does allow it, the consequences are limited. And if running arbitrary code is a feature (you are github or whatever) you use VMs.

Re: Copy Fail

#517

Post by Yokohiii »

AntiUSAbah wrote: post #411
xeeeeeeeeeeenu wrote: post #82

It seems there was some kind of confusion during the disclosure process, because the vendors aren't treating this vulnerability as serious and it remains unpatched in many distros. https://access.redhat.com/security/cve/cve-2026-31431 "Moderate severity", "Fix deferred" https://security-tracker.debian.org/tracker/CVE-2026-31431 https://ubuntu.com/security/CVE-2026-31431 https://www.suse.com/security/cve/CVE-2026-3143…

I'm schocked that ubuntu is aware of this and the prv lts is not patched yet :| wtf

upgraded today and they've put the kernel module install override in place. (wsl2/ubuntu)

Re: Copy Fail

#518

Post by forbiddenlake »

sltkr wrote: post #287
commandersaki wrote: post #252

Tried this on my arch VPS which has a few users that hasn't been rebooted for 122 days. Got: OSError: [Errno 97] Address family not supported by protocol I guess AF_ALG is not part of the Arch Linux LTS kernel? Edit: Looks like on Arch you have to go out of your way to have this enabled. $ zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API CONFIG_CRYPTO_USER_API=m CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_…

On my Arch boxes the official exploit works, both with the LTS kernel (6.18.21-1-lts) and the mainline release (6.19.6-arch1-1).

6.19.6 is nearly 2 months old, you should probably check your mirrors! 7.0.3 is in Arch already.

https://gitlab.archlinux.org/archlinux/packaging/packages/li...

Re: Copy Fail

#519

Post by fsflover »

kuhsaft wrote: post #481
fsflover wrote: post #456

Earlier quoted context omitted.

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

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

On the one hand, you are right, and I rather meant "not exploitable", since technically the vulnerability is still there. On the other hand, yes, any security does rely on you not doing something stupid like "curl | sudo bash".

> "In-VM attack only". That's disingenuous.

It's really not. Hardening of guest OSes is out of scope of Qubes. You are supposed to not combine trusted and untrusted actions in a single VM, so intra-VM security is really secondary. I really recommend you to read my link about organizing the workflows.

You have a good point concerning the integrity issues though.

Post reply on HN