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

171–180 of 545 posts

Re: Copy Fail

#171

Post by alufers »

alufers wrote: post #129
rany_ wrote: post #21

Could this be used to root Android devices? Does Android ship with algif_aead?

I rewrote it quickly to C [1] (and changed the embedded binary to be aarch64). Unfortunately it fails on calling bind() on my device, so probalby Android doesn't ship with that kenrel module by default :(. So no freedom for my $40 phone. Putting it out here, maybe somebody else will have better luck. [1] https://gist.github.com/alufers/921cd6c4b606c5014d6cc61eefb0...

Update: Checking the kernel config indeed confirms this.

   adb shell zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API
   # CONFIG_CRYPTO_USER_API_HASH is not set
   # CONFIG_CRYPTO_USER_API_SKCIPHER is not set
   # CONFIG_CRYPTO_USER_API_RNG is not set
   # CONFIG_CRYPTO_USER_API_AEAD is not set

Re: Copy Fail

#172

Post by rkeene2 »

hashstring wrote: post #167
rkeene2 wrote: post #111

Earlier quoted context omitted.

A workaround might be to make all setuid/setgid files non-world-readable because then they cannot be opened at all, and thus there is no setuid file to replace the contents of.

Eh, if you can pollute page caches this won’t safe you. Think modifying shared libraries, ld preload, cron, I guess on some systems /etc/passwd even. There are a lot of files readable that should definitely not be writable.

Fair enough -- a simpler change might be to poison /etc/passwd and call `su` to a user that has uid 0, since that requires no shell code nor a readable binary, and this seems to have worked in a slightly modified POC:

  f=g.open("/etc/passwd",0);
  e="rkeene:x:0:0:System administrator:/root:/run/current-system/sw/bin/bash\n".encode()
  ...
  g.system("/run/wrappers/bin/su - rkeene")

Re: Copy Fail

#173

Post by daveoc64 »

MarleTangible wrote: post #89
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…

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.

Ubuntu seems to have updated the page to say that it's a high priority now.

Re: Copy Fail

#174

Post by amarant »

oskarkk wrote: post #95
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.

Strange that it's not classified as "high", which specifically includes "local root privilege escalations". > High: A significant problem, typically exploitable for nearly all users in a default installation of Ubuntu. Includes serious remote denial of service, local root privilege escalations, local data theft, and data loss.

It is high now, someone at canonical is paying attention it seems

Re: Copy Fail

#175

Post by jjordan »

hackernudes wrote: post #149

LPE = local privilege escalation Too many darn acronyms. This one wasn't too hard to figure out from context but I wish people would define acronyms before using them!

Good writing for a broad audience requires it. Unfortunately the LLMs don't tend to adopt this guideline.

Re: Copy Fail

#176

Post by justinclift »

tylerni7 wrote: post #114
jzb wrote: post #24

This is amazing. Page says it works on RHEL 14.3, which doesn’t exist. Current RHEL is 10.x, this must’ve been done in a TARDIS.

ugh sorry should be fixed. There was some scrambling to get more info together to explain the issue (and yes, obviously marketing), so there are some minor mistakes. Thanks for pointing it out!

> obviously marketing

Why marketing though?

Re: Copy Fail

#178

Post by eaf7e281 »

I'm impressed that such a serious problem popped up out of nowhere.

In my opinion, this mostly affects countries that are still using outdated systems, especially critical systems.

This gives bad actors a direct route to the root. Having an easily accessible root is not funny.

Re: Copy Fail

#179

Post by wangman »

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…

RedHat has also changed it to "Important severity" and "Affected" now.

Re: Copy Fail

#180

Post by asdfaoeu »

john_strinlai wrote: post #134
StableAlkyne wrote: post #126

Earlier quoted context omitted.

It's just sloppy. Readers are human, and little mistakes like this take away from the article. Then you add a nonexistent RHEL version, and it just isn't a good look. Which is a shame, because it's otherwise a very interesting vuln. Maybe you didn't care, but the length of this comment chain clearly shows that it matters. Effective communication is just as important as the engineering.

agreed regarding the RHEL version! i just dont understand huffing and puffing over "os as g" in a 10-line poc script, and saying "well i would never approve this" . its not enterprise code. its not code that will ever be used anywhere else, for anything. its sole purpose is to prove that the exploit is real, which it does! the rest of the information is in the actual vulnerability report. the poc is a courtesy to the…

I don't anyone is saying it's not "enterprise" it's just that they clearly went out of their way to make it less readable. By all means advertise the golf'd line count but just have the non minified script.
Post reply on HN