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

381–390 of 545 posts

Re: Copy Fail

#381

Post by Sophira »

archon810 wrote: post #348
nh2 wrote: post #115

If you want to use the suggested mitigation (disabling kernel module `algif_aead` with a modprobe config), and you do not want to run that whole obfuscated shell code to get an actual root shell, but only check if the module can be loaded, here is a readable version of its first few lines: python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cb…

modprobe algif_aead modprobe: FATAL: Module algif_aead not found in directory /lib/modules/6.14.3-x86_64-linode168 Yet this kernel is vulnerable.

That would suggest that CRYPTO_USER_API_AEAD=y in your kernel config. You can disable it in that case by setting that to "n", recompiling your kernel, and putting the new kernel in place.

Re: Copy Fail

#382

Post by martin- »

TazeTSchnitzel wrote: post #339
angry_octet wrote: post #280

Earlier quoted context omitted.

People are confusing the presentation layer with the content, just a surface layer analysis. Basically people are feeling so burnt by reading AI fluff that they make a rushed judgement.

Writing something by hand requires effort and signals seriousness. It's not unreasonable to take things less seriously when they come wrapped in low-effort packaging.

Sometimes that effort is better spent on other things.

Re: Copy Fail

#383

Post by dev_l1x_be »

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…

Why is this available in the kernel on a box that does not use ipsec? should this be compile time enabled module instead than a generic solution?

Re: Copy Fail

#384

Post by Sophira »

stackghost wrote: post #113
not_your_vase wrote: post #2

Is there a readable version of the exploit readily available by any chance? Gotta admit that I failed binary-zip-interpretation-with-naked-eye class twice

The call to zlib basically overwrites a minimal ELF into a portion of the `su` binary, which exceve's /bin/sh.

To be specific, the zlib'd binary basically does this (except that it directly uses Linux syscalls to do so rather then C wrappers):

    setuid(0);
    execve("/bin/sh", NULL, NULL);
    exit(0);

Re: Copy Fail

#385

Post by ButlerianJihad »

dev_l1x_be wrote: post #383
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…

Why is this available in the kernel on a box that does not use ipsec? should this be compile time enabled module instead than a generic solution?

The design philosophy of mainstream Linux distros is not like OpenBSD.

Linux distros go to market as maximally capable, maximally interoperable, and maximally available for whatever the users want to do. So there is a lot of "shovelware" that is unnecessarily installed with your base system. A lot of services are enabled that you don't need. A lot of kernel modules are loaded or ready to spring into action as soon as you connect hardware that the kernel recognizes.

All this maximizing also increases the system's attack surface, whether local or over the network. Your resources, time and effort increase, to update the system and maintain all those packages. The TCO is high.

With OpenBSD, the base system is hardened and the code is audited with security in mind. They only install or enable essential functions. So it's up to the user to dig in, customize it, and add in features that are needed.

The good news is that you can do some after-market hardening. Uninstall software that you're not using, and disable non-essential services. Tune your kernel for special-purpose, or general-purpose, but not every-purpose.

There are now special distros for containers and VMs with minimal system builds. They are designed to be as small and lightweight as possible. That is a good start in the right direction.

Re: Copy Fail

#386

Post by ryukoposting »

still_grokking wrote: post #253
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…

As I did not know what AF_ALG is in the first place I've searched for it and found this here: https://www.chronox.de/libkcapi/html/ch01s02.html It states the following: > There are several reasons for AF_ALG: > * The first and most important item is the access to hardware accelerators and hardware devices whose technical interface can only be accessed from the kernel mode / supervisor state of the processor. Such sup…

Hi, embedded firmware engineer here. I give it a B-

There's a weird area between the workloads that fit on a microcontroller, and the stuff that demands a full-blown CPU. Think softcore processors on FPGAs, super tiny MIPS and RISC-V cores on an ASIC, etc. Typically you run something like Yocto on a core like that. Maybe MontaVista or QNX if you've got the right nerd running the show.

So you have serious compute needs, and security concerns that justify virtual memory. But you don't have infinite space to work with, so hardware acceleration is important. Having a standard API built into the kernel seems like a decent idea I guess.

And yet, I've never heard of AF_ALG. I've never seen it used. The thing is, if you have some bizzaro softcore, there's a good chance you also have a bizzaro crypto engine with no upstream kernel driver. If you're going to the trouble of rolling your own kernel with drivers for special crypto engines, why would you bother hooking it into this thing? Roll your own API that fits your needs and doesn't have a gigantic attack surface.

Re: Copy Fail

#387

Post by throwaway5465 »

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.

The domain is canonical.

Then it's syndicate everywhere.

But all roads lead back to the domain.

Re: Copy Fail

#388

Post by eqvinox »

angry_octet wrote: post #375
eqvinox wrote: post #304

Earlier quoted context omitted.

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?

If neither a hardware component nor kernel key management is involved, crypto should be done in userspace, end of sentence.

The more I think about it, the more I think it should be behind CAP_SYS_ADMIN, or a new CAP_KCRYPT (better name TBD. CAP_CRYPT_OFFLOAD?)

Re: Copy Fail

#390

Post by huflungdung »

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.

[dead]
Post reply on HN