Björn Persson <bjorn <at> xn--rombobjrn-67a.se> writes:
> JB wrote:
> > This does not help in this case. The attack's effect can happen at any
> > time and catch systemd with its pants down at any time in the
> > scenarios you described.
> > The attack is on socket buffer availability via kernel, it lasts until
> > no resource is available system-wide. At that point systemd or any
> > other socket-based communication is brought to a standstill.
> > The point is, systemd can not be stopped, or
> > restarted/reinitialized/reset as any other stand-alone service daemon
> > relying on sockets availability manually.
> > The process #1, the GOD of all processes, is incapacitated, for good.
>
> I searched for "attack" and "socket buffer availability" trying
to find
> out what kind of attack you're talking about. Duckduckgo had never heard
> about it.
> Google gave me three hits, and all three were your previous message in
> this list. It would help if you could explain how this attack works and
> how exactly it would cause SystemD to lock up.
The link is in one of my posts above, but here it is again:
http://www.securiteam.com/unixfocus/6U00P1PEVQ.html
It contains a detailed description and the original CVE link.
Once again, it is about DOS of a resource in question, that is a socket
buffer memory, with system-wide effect, obviously on any socket-based
process.
According to that description, the resource in question was physical memory.
Although the attack made use of sockets, it didn't consume any kind of socket-
specific resource, just plain old memory. If the attack was successful it would
cause a kernel panic. A kernel panic halts the entire system. All processes
stop running, regardless of whether they use sockets or not. That particular
attack is therefore irrelevant in a discussion about whether process 1 should
use sockets.
Björn Persson