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

191–200 of 545 posts

Re: Copy Fail

#191

Post by tremon »

comfydragon wrote: post #164
oskarkk wrote: post #81

Earlier quoted context omitted.

In TFA: https://copy.fail/#mitigation > Before you can patch: disable the algif_aead module. > echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf > rmmod algif_aead 2>/dev/null || true Edit: and I can confirm that on my system with kernel 6.19.8 the above fixes the exploit.

Weirdly, the mitigation does not seem to work under WSL2 (at least in Ubuntu 24.04). Linux wsl2 6.6.87.2-microsoft-standard-WSL2 ... `modprobe algif_aead` errors out, but if I run the POC, it succeeds. Outside of WSL2, the mitigation does appear to work though.

It's possible that the WSL kernel has that code compiled-in rather than as a loadable module. If they ship the kernel config somewhere, you could verify with

  zgrep CRYPTO_USER_API_AEAD /proc/config.gz /boot/config-*
It should show =m if it's a loadable module, and =y if it's compiled in.

Re: Copy Fail

#192

Post by 2001zhaozhao »

phreack wrote: post #40

The page itself seems vibecoded and a bit of an advertisement, but it does look like the vulnerability is real and high risk. It does explain the big security update I just got, guess I'll prioritize updating today.

This is pretty obviously an advertisement but it's a pretty good advertisement imo, it pairs a meaningful contribution to the OSS ecosystem (discovering and patching a real bug) with selling your cybersecurity tool at the same time.

Re: Copy Fail

#193

Post by Sohcahtoa82 »

layer8 wrote: post #34

Debian page: https://security-tracker.debian.org/tracker/CVE-2026-31431

Oddly, the POC doesn't work on my Debian 12 (Bookworm) EC2 instance. Everything that should indicate it's vulnerable is there, including the ability to socket(38,5,0).bind("aead", "authencesn(hmac(sha256),cbc(aes))")

Re: Copy Fail

#194

Post by tremon »

stackghost wrote: post #116
bananamogul wrote: post #62

Earlier quoted context omitted.

"Debian Stable ("Trixie", though I hate codenames)" You can also call it Debian 13.

I choose not to call it Debian 13 because that carries less context than Stable/Testing/sid. I'd rather not require the user to maintain that extra metnal mapping. Anyone who knows anything about this subject immediately understands what is connoted by "Debian Stable". I run Trixie on most of my personal boxes and I had no idea what version number it is, nor do I particularly care.

> I run Trixie on most of my personal boxes and I had no idea what version number it is

It's not that hard to find though:

  $ cat /etc/debian_version 
  13.4

Re: Copy Fail

#197

Post by comfydragon »

tremon wrote: post #191
comfydragon wrote: post #164

Earlier quoted context omitted.

Weirdly, the mitigation does not seem to work under WSL2 (at least in Ubuntu 24.04). Linux wsl2 6.6.87.2-microsoft-standard-WSL2 ... `modprobe algif_aead` errors out, but if I run the POC, it succeeds. Outside of WSL2, the mitigation does appear to work though.

It's possible that the WSL kernel has that code compiled-in rather than as a loadable module. If they ship the kernel config somewhere, you could verify with zgrep CRYPTO_USER_API_AEAD /proc/config.gz /boot/config-* It should show =m if it's a loadable module, and =y if it's compiled in.

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.cache
    [openat] pid=3688 file=/lib/liblzma.so.5
    [openat] pid=3688 file=/lib/libz.so.1
    [openat] pid=3688 file=/lib/libgcc_s.so.1
    [openat] pid=3688 file=/lib/libc.so.6
    [openat] pid=3688 file=/etc/modprobe.d
    [openat] pid=3688 file=/lib/modprobe.d
    [openat] pid=3688 file=/lib/modprobe.d/dist-blacklist.conf
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.softdep
    [openat] pid=3688 file=/lib/modprobe.d/systemd.conf
    [openat] pid=3688 file=/etc/modprobe.d/usb.conf
    [openat] pid=3688 file=/proc/cmdline
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.dep.bin
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.alias.bin..
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.symbols.b..
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.builtin.a..
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.builtin.b..
    [openat] pid=3688 file=/sys/module/algif_aead/initstate
    [openat] pid=3688 file=/sys/module/af_alg/initstate
    [openat] pid=3688 file=/sys/module/algif_aead/initstate
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/kernel/crypto/alg..
    [finit_module] pid=3688 comm=modprobe fd=0 flags=0
    [module_load] pid=3688 comm=modprobe name=algif_aead
Restart WSL2, run the bpftrace, and try `sudo modprobe algif-aead`, and that shows it looking at (or I guess opening) other files in /etc/modprobe.d, including the new one.

The mystery is why.

Re: Copy Fail

#198

Post by IgorPartola »

Sohcahtoa82 wrote: post #187
justinclift wrote: post #176

Earlier quoted context omitted.

> obviously marketing Why marketing though?

Resume-driven development

I would rather people who find this kind of stuff pad their resumes and get coolness points on HN than sell this exploit on the black market. But your priorities may be different and you might prefer they do the latter.

Re: Copy Fail

#199

Post by layer8 »

debo_ wrote: post #188
layer8 wrote: post #121

Earlier quoted context omitted.

> I think of it as a proxy measure for how complicated or uncomplicated the exploit might be. From a Busy Beaver, 256-bytes compo, or Dwitter perspective, 732 bytes isn’t really that meaningful. And the sample exploit is even optimizing the byte size by using zlib compression, which doesn’t make much sense for the purpose. It just emphasizes the byte count fetishization.

Again, I think the point is that compressed size is a reasonable measure of the inherent complexity of a program. I'm a crap mathematician, but I believe that is a fundamental concept in information theory.

But it isn’t compressed size, the compressed part is only 180 bytes of the 732.

Re: Copy Fail

#200

Post by fragmede »

int0x29 wrote: post #71
notpushkin wrote: post #63

Earlier quoted context omitted.

Try /system/bin/ping

Now the socket is blocked. Also probably should have realized the socket is defined earlier than its called Traceback (most recent call last): File "/data/data/com.termux/files/home/exploit.py", line 9, in while i 64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A" 4+c],[(h,3,i 4),(h,2,b'\x10'+i 19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o) ^^^^^^^^^^^^^^…

PoC is also x86_64 only and not arm.
Post reply on HN