Hacker News Reader

Comment by surteen | Hacker News Reader

The JFrog Security Research team gave this vulnerability a Medium severity rating for the following reasons:

A DoS attack that crashes a forked worker process is much less severe than a DoS that crashes an important daemon, but they will both receive a “High” Availability impact CVSS rating.

How is this even considered a DoS at all? You're forking a process and then immediately crashing it. You're only Denying Service to your own connection that you just made.

View on HN

I agree that this is pretty limited. I think that depends on how expensive it is to create a process: if you could open enough connections or hit something like the audit log frequently enough[1], it might be a decent traffic multiplier when you can't otherwise do something damaging (maybe in a scenario where you get something like a r/o deploy key?).

1. I'm not sure this is very useful but I was thinking that if someone follows one of the security hardening standards, their servers are configured to hang until the audit log buffer can be flushed but you could more easily hit that by failed login requests unless they have something like fail2ban installed.

As you pointed out it's a DOS in the sense that causing a process to fork/crash is much more expensive than a regular denied connection, so it would be easier for an attacker to overload the server using this technique than it would be if they were just making regular denied connections. Also consider that on many systems this would trigger a core dump which will cause a few MB to be written to disk (although you probably can't fill up the disk because in the default configuration most systems are configured to keep either just one core dump or N, where N is some small number like 10).

I think the audit log stuff is a red herring because regular denied connections are already written to the audit log.

Does anything have core dumps enabled by default any more? I thought about that but it’s been years (decades?) since I encountered it unintentionally.

You could just open the connections and let them sit without crashing the process. Then those processes and connections will actually be consuming resources instead of crashing and disappearing.

... up to MaxStartups. The most important resource they'd be consuming would be the startup slots.

How many resources does that use, however? I’m not sure anything but an embedded device would even notice any of these possibilities. The closest I could come is Ubuntu’s old crash reporter but I thought they hardened that a while back.

On many systems, processes that are rapidly restarting or crashing tend to be throttled; depending on whether cores are enabled you can flood the system with core i/o. In addition, forking servers are often deliberately written to limit the fork frequency (fork bomb prevention).

Reply on news.ycombinator.com