Live data from Hacker News

Canonical/Ubuntu have been under DDoS

status.canonical.com

61–70 of 76 posts

Re: Canonical/Ubuntu have been under DDoS

#61
post #49
post #19

Earlier quoted context omitted.

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)

snaps work on anything that has systemd so I don't quite know where you got the idea is that it is mostly limited to ubuntu.

Re: Canonical/Ubuntu have been under DDoS

#62
post #52

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.

My mind immediately went to chaining this with another recent vulnerability in the Ninja Forms - File Upload plugin [0] > This makes it possible for unauthenticated attackers to upload arbitrary files on the affected site's server which may make remote code execution possible. So, upload and execute a script that loads Copy Fail and even if you're only executing as www-data or another restricted user that "can't" sud…

Yes but what I'm saying is that copy.fail is a minor detail in this scenario.

If you are running Ninja Forums you need to run it in its own VM so that if it gets compromised _you don't care if it has uid=0_.

You need to do that regardless of copy.fail. Now that you've patched copy.fail, there are loads and loads of other vulns that can be used the same way.

Re: Canonical/Ubuntu have been under DDoS

#63

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?

Look at kCTF results.

Look at the CVE database. Most of those UAFs are LPE. Many of the OOBs and many of the race conditions too. These are fixed in Linus' master but you are running an old kernel.

Then look at the KASAN reports on the syzkaller dashboard. Many of them are LPE. Many of the WARNs and crashes are revealing and underlying bugs that is also an LPE. Most of these never get fixed.

Then try pointing your LLM at the codebase and saying "find an LPE". It will find as many as you want (you will exhaust your tokens long before it stops finding bugs). 99.99% of them will be bogus so you need a way to evaluate them at scale, currently this is the weakest approach but we'll get better at it.

I can't actually point you to a list of confirmed LPEs coz the only way they get confirmed is when someone exploits them, but there aren't enough exploit authors to do this for all of them. If inference gets really cheap and someone builds a really good agent harness we might start to see it get automated at some point.

Re: Canonical/Ubuntu have been under DDoS

#64
post #35
post #22

Earlier quoted context omitted.

Well, that and the rush to upgrade for copy.fail. Has Ubuntu published patches yet?

Patch published to disable the affected module. No patch for the module itself yet.

That let me think: I think I have never compiled af_alg in any of my linux kernels.

Now, I worry about the linux user mount namespace code... because I run the steam client which valve forces people to have in their kernel because they don't want/know how to craft "correct" ELF64 binaries, namely "-static-libgcc -static-libstdc++" compiling/linking options, maximizing static linking refactoring a bit source code with the pre-processor to avoid symbol collisions.

Re: Canonical/Ubuntu have been under DDoS

#65
post #60

While the timing with the copy.fail patches mentioned by a few comments here seems suspicious indeed, I have seen this repeating over the last few weeks: packages.ubuntu.com was hardly reachable on some days, causing apt-get to take forever to update the system. They have been struggling hard recently, it seems. Best of luck to the people having to deal with this mess on a holiday!

The point of coincidental timing with copy.fail patches is that by DDoSing an upgrade mechanism for one of most popular distributions, you extend the time window certain systems remain vulnerable in order to exploit them.

The point is that these apparent DDoSes have been going on for weeks, they are not necessarily related to copy.fail.

Re: Canonical/Ubuntu have been under DDoS

#66

Earlier quoted context omitted.

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.

Well, there's still value in users and namespaces! Just, it's not a strong security boundary.

Also even if it's not strong, it doesn't mean it's entirely worthless. You can't rely on it, but it's usually free and it still buys you time / increases attack cost.

Like, if you leave 100k cash in a car on the street in SF, that's dumb. If you really need to do that for some strange reason, you should hire a security guard to watch your car, because cars a not a good security boundary. BUT, that doesn't mean you would leave the car unlocked just coz someone's watching it!

Re: Canonical/Ubuntu have been under DDoS

#67

Earlier quoted context omitted.

They told me my grandpa was too dumb at round 47. I felt like I was close.

I got all the way to round 53, but it turned out that one of my semiaquatic tetrapod ancestors from the Carboniferous Period didn't perform on land as well as they would have liked, so that was it for me.

5 internet points to you sir.

Re: Canonical/Ubuntu have been under DDoS

#68
post #61
post #49

Earlier quoted context omitted.

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)

snaps work on anything that has systemd so I don't quite know where you got the idea is that it is mostly limited to ubuntu.

IDK just using Linux for like 30 years.

They're the only main distro I know of that uses it at all by default.

Red Hat, Fedora, Debian, Ubuntu, Arch, etc. Ubuntu is the only one.

Re: Canonical/Ubuntu have been under DDoS

#69
post #60

Earlier quoted context omitted.

The point of coincidental timing with copy.fail patches is that by DDoSing an upgrade mechanism for one of most popular distributions, you extend the time window certain systems remain vulnerable in order to exploit them.

The point is that these apparent DDoSes have been going on for weeks, they are not necessarily related to copy.fail.

Makes you wonder if certain parties were tipped off early
Post reply on HN