Live data from Hacker News

Canonical/Ubuntu have been under DDoS

status.canonical.com

41–50 of 76 posts

Re: Canonical/Ubuntu have been under DDoS

#41

Earlier quoted context omitted.

I thought copy.fail is a privelage escalation exploit, become root from a regular user? Am I missing something? How would "node architecture" make people vulnerable to this? You have to have shell access to a victim first right? Or am I missing something?

Yeah you need native code execution, and if you have AF_ALG access there is clearly no sandboxing in place. At that point it's game over on Linux, there are too many bugs. Even if you fix all the known ones in the current kernel, by the time the version with those fixes is qualified and released (not to mention, the machine must reboot), new LPEs have been discovered.

To convince me Linux is full of kernel LPE bugs, can you share some of the bugs?

Re: Canonical/Ubuntu have been under DDoS

#42

Earlier quoted context omitted.

Yeah you need native code execution, and if you have AF_ALG access there is clearly no sandboxing in place. At that point it's game over on Linux, there are too many bugs. Even if you fix all the known ones in the current kernel, by the time the version with those fixes is qualified and released (not to mention, the machine must reboot), new LPEs have been discovered.

To convince me Linux is full of kernel LPE bugs, can you share some of the bugs?

https://gtfobins.org

Re: Canonical/Ubuntu have been under DDoS

#43
post #17

Earlier quoted context omitted.

In what way is it "not a special bug"? It's a publicly known root access from RCE exploit. Those cannot be a dime a dozen. I'm sure it's especially interesting for any shared hosting services which might be affected, and could be delayed. I could find any places running containered services and exfiltrate secrets parallel services, no? What constitutes "special" for you, out of curiosity? Something chaining with a hy…

It's not RCE it's an LPE in an obscure corner of the kernel attack surface that no sensible application depends on. They are absolutely a dime a dozen. Even just in AF_ALG there have been several such vulns fixed in 2026 already. Kernel wide probably hundreds. It's true that most of them will be harder to exploit than this one but that just means you need to prompt your AI a bit harder to get an exploit. (To be fair,…

The cope of some people is insane. Why even have UID:GID? All you need is 0:0. I always tell people to run everything as root because there is literally no point.

Re: Canonical/Ubuntu have been under DDoS

#44
post #38

Maybe they could use this DDoS attack as their 17th round technical interview. Any candidate who successfully mitigates the attack would then make it to the 18th round. Win win!

Do they finally meet a human being with an explanation on the position on the 18th round?

Depends on their high school GPA.

Re: Canonical/Ubuntu have been under DDoS

#45
post #17

Earlier quoted context omitted.

If you can access AF_ALG on a server you don't need to do shenanigans like that. It's much easier to just find another bug and exploit that one instead. The copy.fail website is very silly, it is not a special bug. If anyone gets compromised by that vuln their node architecture was broken anyway, patching copy.fail doesn't help.

In what way is it "not a special bug"? It's a publicly known root access from RCE exploit. Those cannot be a dime a dozen. I'm sure it's especially interesting for any shared hosting services which might be affected, and could be delayed. I could find any places running containered services and exfiltrate secrets parallel services, no? What constitutes "special" for you, out of curiosity? Something chaining with a hy…

They're not dime a dozen exactly but LPE bugs in Linux (and common Linux distros) are easily common enough that nobody sane relies on user isolation as a serious security boundary.

Clouds use VMs as the security barrier, which is also not always 100% perfect, but is much better.

It could be useful as part of an exploit chain but generally once you've got to local code execution it's not going to be difficult to get further.

A "special" bug would be something that defeats a security barrier that people actually use, e.g. something that works remotely, or as you say - a hypervisor hack.

Re: Canonical/Ubuntu have been under DDoS

#48
post #11

Earlier quoted context omitted.

Frustrating because the Slack snap is broken so every day you have to downgrade it and I guess you can't without connectivity. This might be the incentive I need to finally purge snap.

Just move to flatpak, much nicer to deal with

Both fail hard for so many things. If you need any sort of hardware acceleration, just use an rpm/deb.

Re: Canonical/Ubuntu have been under DDoS

#49
post #19
post #11

Earlier quoted context omitted.

Just move to flatpak, much nicer to deal with

In my testing I find the exact reverse. I much prefer snap to flatpak.

Snap is mostly limited to Ubuntu and has to run as a daemon.

Flatpak gives me cross-platform/cross-distro software directly/certified by the project or company that has additional security sandboxing and doesn't open up potential security issues.

I don't have to wait for a distro package, and yet there are no system integration concerns.

It also works great for atomic distros (SilverBlue, etc)

Re: Canonical/Ubuntu have been under DDoS

#50
post #16

Though this outage may be more related to the copy.fail upgrade cycle, it reminds me of a thought I've had recently in respect of agents. In the UK they have this issue called "TV pickup" ( https://en.wikipedia.org/wiki/TV_pickup ). TV pickup is where everyone in the UK watching a popular TV show gets up to boil a high-powered tea kettle at the same time on an ad break. This causes a temporary surge in electricity de…

It appears to be a pro-Islamic Republic of Iran DDoS crew

https://news.ycombinator.com/item?id=47975729

Post reply on HN