"Hmm, we don't really test or fuzz LibIPC, let's see if I can find something weird with it."

…

Oh no.

// attack.cpp

#include <LibCore/EventLoop.h>
#include <LibCore/LocalSocket.h>
#include <unistd.h>
int main()
{
    Core::EventLoop loop;
    auto socket = Core::LocalSocket::construct();
    socket->set_blocking(true);
    socket->connect(Core::SocketAddress::local("/tmp/portal/window"));
    u8* buf = (u8*)malloc(MiB);
    memset(buf, 0xff, MiB);
    socket->write(buf, MiB);
    return 1;
}

There are several issues, probably not all exposed by the above attacker:

1. Something in the Kernel really doesn't like what's going on, and now consumes 90% of CPU, even after the above program finishes!
2. LibIPC fails to detect that the connection has closed, and still tries to parse the messages on every single event pump. This slows down message parsing.
3. LibIPC has no upper limit on message sizes. It will attempt to read and buffer 4 GiB of data, because the first four bytes are 0xffffffff.
   • Related: Some of our messages are arbitrarily big, especially Dicts can end up being huge; but in practice, they never are.
4. While there are pending packets, a LibIPC server does not accept any new connections. Even outside of malicious contexts, this is a bad idea, as it probably slows down system boot (lots of traffic and programs that are blocked by their outgoing connection).
5. The m_unprocessed_messages queue is effectively unbounded. This isn't really a problem yet, as they will usually be processed (and thus removed) very quickly. However, wait_for_specific_endpoint_message allows for receiving and storing arbitrarily many messages. In clients, this isn't a problem, and servers usually send async messages, so they don't call it. With two big exceptions:
   • WindowServer's fast_greet mechanism ironically allows the greeting to be delayed arbitrarily, as it calls wait_for_specific_message<Messages::WindowClient::FastGreet>().
   • WebContent does some sync calls into its client. If we assume that the client has been possibly compromised (and that's why we do process isolation), a malicious client only needs to send arbitrary messages to overwhelm and crash the browser itself. (DoS, not RCE, but still bad.)
6. ConnectionBase::wait_for_specific_endpoint_message_impl might also accidentally quadratic: We keep re-checking all messages again and again on each wakeup, even though I don't think any messages are being processed. I might be wrong about the latter point though, since WindowServer clearly still works while waiting for a specific message.

So I guess the following fixes are a good idea:

• Teach LibIPC that if the remaining bytes can't be parsed, the Kernel has no more bytes, and the connection is closed, then the remaining bytes should be dropped and the connection killed.
• Teach LibIPC how to accept new connections while packets are pending.
• Enforce an upper bound on message sizes (how about 3 MiB? I intend to write a IPC-sniffer eventually, hence my ptrace improvements. If I ever finish it, we might get some stats on message sizes in practice.)
• Make wait_for_specific_endpoint_message able to give up. In particular, ConnectionBase::wait_for_specific_endpoint_message_impl contains an infinite loop. If more than X (maybe 10?) messages arrive, I think the peer probably won't send one, and can be considered malicious.
• Also, it should remember "where" in m_unprocessed_messages we are, and only start checking messages from there. Afterall, messages are not processed while this method is ongoing.