Open BenWiederhake opened 1 year ago
LibWeb currently uses IPC messages to send JS console logs across to the browser, which can be arbitrarily large depending on the objects and their properties logged. Arguably that should use a different channel.
A better solution would be to handle errors and call did_misbehave
if the message is not allocatable.
One of the problems is that it does handle the situation without problems for way too long, until a random part of the overall OS is killed through OOM. In my experiments, it was usually a different process that died first.
How about calling did_misbehave()
when a packet size larger than 5 MiB is seen? That would catch the problem long before we run into any OOM trouble, and give us sufficient room to breathe with huge IPC messages. (We really shouldn't be sending so large messages anyway.)
Sending gigabytes of
0xFF
bytes to any LibIPC server will cause them to OOM.Specifically,
Connection::try_parse_messages
inLibraries/LibIPC/Connection.h:135
will happy accept anyu32
as valid value ofmessage_size
, and read until the the internal buffer has that size. If the first four bytes are0xFFFFFFFF
, then it will try to read 4 GiB, which in default configuration causes an OOM:Since we already do the "heavy lifting" through shared bitmaps or anonymous files, I don't see a reason to allow arbitrarily large messages. I tried out most programs (including browsing through every bookmarked webpage), and the largest message I saw was 15 KiB. Except for HackStudio, apparently we regularly send large messages to the LanguageServer, where messages with 68067 bytes are "normal". Hmm, maybe we should change that. For
LibWeb/CSS/Parser/Parser.cpp
(329379 bytes), it sends 224468 bytes. For the ultra-heavy fileBuild/x86_64/Userland/Libraries/LibLocale/LocaleData.cpp
(15076548 bytes) it OOMs immediately, but I'm going to assume it sends linearly much more than that.I think we should introduce an upper limit on message sizes; something like 5 MiB sounds good. What do you think?
Note that it is fundamentally impossible to fully prevent this from happening. After all, an actively malicious user could simply for a bunch of times, and send "limit-as-defined-above minus one" bytes.
Code and screenshots
``` /* * Copyright (c) 2023, Ben Wiederhake