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

371–380 of 545 posts

Re: Copy Fail

#371

Post by staticassertion »

ramon156 wrote: post #347
jeffwass wrote: post #336

This submission is currently the main HN submission. As of now the submission title is simply “Copy Fail”. Given the severity of the exploit, can we edit the Title to add some context that it’s a major Linux vulnerability? Eg the other submissions say this : “Copy Fail: 732 Bytes to Root on Every Major Linux Distribution.”

I dont really get why you'd - buy a domain - vibe code a page/artifact/whatever (which, given the quality of LLM wordings, only makes an argument less strong) - post it on HN with no further explanation in the title Why not write a detailed report? Even a tweet makes much more sense in my head than this. Even a logo?? Sorry if this comes over as salty, I guess I'm just not getting the thought process.

Where would you have them write a detailed report if not a website?

Re: Copy Fail

#372

Post by staticassertion »

acdha wrote: post #289
staticassertion wrote: post #245

Earlier quoted context omitted.

https://duckduckgo.com/?q=LPE+security&ia=web wow

Sure, nobody’s saying it’s an inscrutable mystery but if your goal is to inform a wide audience it’s considered good form to expand all but the most common acronyms. It’ll even get you more internet points than petty smugness.

I think sysadmins should learn the term LPE tbh

Re: Copy Fail

#374

Post by skywhopper »

mihaaly wrote: post #364
buckle8017 wrote: post #276

Earlier quoted context omitted.

You should take note that this is written by the person that wrote the bad patch. So grain of salt.

But is it true or not? Whoever wrote it. (for objective truth the subjects are unimportant)

When you can’t know the objective truth or when there isn’t one (as is the case in making decisions about security tradeoffs in software design), knowing the source of the argument is vital to interpreting its validity.

Re: Copy Fail

#375

Post by angry_octet »

eqvinox wrote: post #304
angry_octet wrote: post #301

Earlier quoted context omitted.

Most of the Linux kernel crypto is not touching the TPM. If there is a TPM task, only that code should be in kernel, and it should be accessed from user space by a process with the appropriate token.

Yes, AF_ALG is exposing too many things, like authencesn, which has zero reason for being userspace accessible. It's a crypto mode specific to IPsec. However, > it should be accessed from user space by a process with the appropriate token. That is AF_ALG. The operations it offers are what you need for full coverage. The issues with it are two: - usage specific crypto in the kernel implements the same interfaces, and…

All the uses of vmsplice etc are a bit tricky, and that points to the need for a better interface. But given you're using splice, why not do the crypto in user space? A belief that it is better to be fast and buggy than safe and slower?

Re: Copy Fail

#376

Post by XorNot »

400thecat wrote: post #354
l1k wrote: post #300

Earlier quoted context omitted.

It does enable address space separation of secret keys from user space, which some people love: https://blog.cloudflare.com/the-linux-kernel-key-retention-s... https://www.youtube.com/watch?v=7djRRjxaCKk https://www.youtube.com/watch?v=lvZaDE578yc So it's not as simple as "should not exist". I agree though that there doesn't seem to be a valid need to expose authencesn to user space. Disclosure: I'm co-maintaining cr…

can you please give me a real-life example of an application, on a typical linux laptop or typical linux server, which userspace application would use this CRYPTO_USER_API ? None that I looked at seem to use it: openssl, pgp, sha256sum

Isn't the better argument to ask whether there'd be benefit if all those things did?

A lack of adoption isn't apriori a good argument against an interface, and serious bugs can happen anywhere.

My personal opinion for a while has been that crypto operations should be in the kernel so we can end the madness that is every application shipping it's own crypto and trust system which has only gotten worse since containers were invented.

Re: Copy Fail

#377

Post by XorNot »

dwedge wrote: post #366
CGamesPlay wrote: post #338

Earlier quoted context omitted.

> if your model is that linux is just about single-user desktops, this local exploit isn't too bad. For example, if you have passwordless sudo, you've already got a widely known LPE vulnerability lurking on your system.

Only for your user, and it means a keylogger on the system if it gets rooted can't pull your password to try on other machines. Personally I always either login as root or use passwordless sudo.

Yubikeys are also surprisingly annoying when setup for the as well. A working developer just needs sudo a lot.

Realistically a "sudo button" would be handy, on the keyboard, with a display to show a confirmation pin for the request (probably also needs a deny button so you can try and identify weird ones).

Re: Copy Fail

#379

Post by adrian_b »

TheDong wrote: post #319
dnnddidiej wrote: post #308

Earlier quoted context omitted.

I wonder can the kernel just remove it and distros put on a compatiability layer.

It's already a configurable option in the kernel which can be fully disabled by distros if they wanted to provide their own compatibility layer, or just not ship any software that has a hard dependency on it.

I always use only custom compiled kernels on my computers, where I enable only the configuration options that I really need.

So the options related to AF_ALG have always been disabled, because I have not encountered an application that needs them, among those that I use.

Unfortunately the Linux distributions must enable in their default configuration most options, because they cannot predict what their users will need.

Re: Copy Fail

#380

Post by RandomGerm4n »

That is why we should get rid of setuid binaries. GrapheneOS does not use them and was therefore not affected. On the desktop there is also a project called Secureblue based on Fedora Atomic that is moving in a similar direction and has already eliminated a large number though not all setuid binaries. As an alternative to sudo, su, and pkexec there is for example run0, which is available in distributions using systemd. Since systemd 259 there is now also the --empower parameter which like sudo elevates the privileges of the regular user. Essentially any distribution could start removing sudo and create an alias so that users don’t have to adjust immediately.
Post reply on HN