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

501–510 of 545 posts

Re: Copy Fail

#501

Post by ebiggers »

WhyNotHugo wrote: post #412
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…

iwd requires CONFIG_CRYPTO_USER_API_AEAD, so disabling this would break Wi-Fi for a lot of people.

Indeed, iwd is the main reason why general-purpose Linux distros can't disable AF_ALG yet. But many Linux systems are more specialized and don't have wireless connectivity, or they use another wireless daemon such as wpa_supplicant which doesn't have this issue.

I'm hoping we can get iwd fixed to use a userspace crypto library, as well. This is something that people could help with.

iwd also runs as root, so it would be okay with a CAP_SYS_ADMIN permission check if one were introduced, I think.

Re: Copy Fail

#502

Post by ebiggers »

derefr wrote: post #499
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…

It'd make a lot of sense to sandbox AF_ALG, then, wouldn't it? At least for userspace-driven invocations. Let the kernel keep its current code-path for kernel-driven invocations, but have the same code unit files also build some other sandboxed form, to be invoked by the crypto-accelerating syscalls. If these syscalls are used by userspace as rarely as you say, the performance impact of this kind of sandboxing wouldn…

I don't see those eBPF or microkernel ideas as being particularly realistic! But there are some simple ways AF_ALG's attack surface could be reduced (as an intermediate step to disabling it entirely), like requiring CAP_SYS_ADMIN and/or limiting the algorithms to a specific list.

Re: Copy Fail

#503

Post by TZubiri »

danparsonson wrote: post #458
TZubiri wrote: post #451

Earlier quoted context omitted.

Everything MAY be a criminal offense. Whether it has any merit is another matter. If I were accused of anything criminal for running this in a host, my defense would be that I was checking the safety of a service I was being offered. If the service was vulnerable, I would counterclaim, if you are on the defense you are already losing.

You understand there's a difference between how the law is, and how you think it should be, right? Only one of those things will actually help you in court.

It probably depends more on the facts than the law.

Whether local access to a system was lawfully granted, whether the af alg module was probed, whether page cache in memory was corrupted, whether su binary on disk was modified, whether other users could access su after the intervention, what the terms of services were. Whether information from other users was accessed, whether the server is private or government related, whether the vuln was actually present, what actions were taken in notifying the server owner if the vuln was present etc..

To claim that X is illegal without regard for any of these variable facts is unlikely to hold generally.

Additionally, as a plaintiff I would be looking at a civil claim, so that would be my concern when evaluating defendant liabilities as well.

Re: Copy Fail

#504

Post by x4132 »

yrro wrote: post #357
x4132 wrote: post #236

Earlier quoted context omitted.

i mean, it doesn't work on any SELinux, but it's still quite severe anyhow

Have you got any info about this. 'seinfo -c' shows there is an alg_socket class. I presume this permission is required to be able to create an AF_ALG socket: $ sesearch -A -c alg_socket -p createallow bluetooth_t bluetooth_t:alg_socket { accept append bind connect create getattr getopt ioctl listen lock read setattr setopt shutdown write }; allow container_device_plugin_init_t container_device_plugin_init_t:alg_sock…

sorry yeah, I saw not exploitable on Android and thought most SELinux would be ok. Not super sure on this case what the surface is

Re: Copy Fail

#505

Post by bombcar »

zepearl wrote: post #486
bombcar wrote: post #202

Earlier quoted context omitted.

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). - Ma…

Yeah in theory genkernel should handle zfs but since I’m zfs_on_root because I like living dangerously I have a one liner that genkernels and then re-emerges zfs and then rebuilds the initramfs.

Re: Copy Fail

#506

Post by senectus1 »

nh2 wrote: post #92
embedding-shape wrote: post #15

For mitigation, the page currently basically just says: > Update your distribution's kernel package to one that includes mainline commit a664bf3d603d But it isn't very clear to me what Kernel version you can expect that to be in. For Arch/CachyOS, the patch seems to be included in 6.18.22+, 6.19.12+ and 7.0+. If you're on any of the lower versions in the same upstream stable series, you're likely vulnerable right now…

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

Just curious.. do they list all those kernel version because there is regression in versions after 6.18.22 ?

ie does v 6.19.0 have the flaw in it?

Re: Copy Fail

#507

Post by eqvinox »

angry_octet wrote: post #409
eqvinox wrote: post #388

Earlier quoted context omitted.

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

I'm also wondering if it couldn't be rewritten to use io_uring interfaces.

That's really orthogonal (and you can already do io_uring with AF_ALG, at the end of the day AF_ALG is just recvmsg() and sendmsg(), which work just fine in io_uring...)

Re: Copy Fail

#508

Post by MarsIronPI »

XorNot wrote: post #376
400thecat wrote: post #354

Earlier quoted context omitted.

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…

If Linux does that, I really hope it can be done in a standardized way that doesn't make porting to *BSD more difficult than it already might be. Standards are a good thing.

Re: Copy Fail

#509

Post by MarsIronPI »

TZubiri wrote: post #444
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 unaffect…

I think the issue here is not "Don't Repeat Yourself", but "Don't Reinvent the Wheel". If your wheel is just a circle of wood, you're better off building it yourself than hiring a skilled (or sometimes not so skilled) laborer. Too much overhead and risk.

Re: Copy Fail

#510

Post by psifertex »

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.

They did not, in fact, botch anything. They notified the responsible party and followed a practice that is pretty much the accepted norm (and for good reason).

How recursive should their notifications be? Just the tip three distros? The top dozen? Every embedded Linux router company? How about every hosting provider?

They did what they're supposed to without being paid for it. The only other good source of funding for security research besides marketing budgets for security companies will NOT result in a disclosure timeline you'd be happier with. ;-)

Post reply on HN