lophttpd fucks the POODLE

Not just because they are ugly but also because lophttpd
never was affected by POODLE, since SSLv3 was
disabled for a reason in favor of TLSv1. I think about dropping
TLSv1 too and just allowing TLSv1.1+ in future.

To my knowledge lophttpd is also the first webserver
utilizing Linux seccomp sandbox.

I also added SO_REUSEPORT support today, since Google
told us that when handling c10k, their processes
are un-evenly distributed across the cores (what the hell
are they doing there?)
lophttpd wins again, since even without SO_REUSEPORT,
such problem never existed for you:

which shows running it on 4 cores, handling c10k. Could
there be a smaller footprint?


Update:

After carefully reading the commit for the Linux kernel
that introduced SO_REUSEPORT, I came to the conclusion that
for Linux there was an entirely different reason to introduce
it than there was for 4.4BSD at the time. According to the
git commit message, uneven distribution among the cores
only happen when the "number of listener sockets bound to a
port changes (new ones are added, or old ones closed)".
So its clear that it never affected lophttpd and it "leaks"
interesting info about the architecture of the google
webserver, why it had such problems before the patch
and which kernel they are using. OSINT for the win.
(Such architecture where new listeners are created or removed
do not make much sense to me anyway, so there are some
questions left.)

So in theory, I could remove SO_REUSEPORT again but I will
leave it as is for now, in case more webserver instances
are started later. Note that it doesn't make sense to have
more lophttpds running than there are cores on
your machine. I do not support hyperthreading yet, so
-n 0 is what you want, if you have such heavy load at all.

sshttp btw also uses the same multi/single-thread architecture
without SO_REUSEPORT (yet).

trusted bootloader RCE trickery

So you are safe, because you updated your bash, run your policy in enforcing mode, enabled NX and ASLR and boot using a cryptographically signed shim bootloader.

Well, you actually failed by the first step.

Here is why:

Even if thats hard to believe, but there might be
remotely exploitable buffer overflows in your secure
bootloader. The 90's party of today just happen
downstairs. Bootloaders make use of UEFI network stacks
to implement PXE and PXEv6 and sometimes fail to do so:

The issue however is not so severe because a lot of UEFI
firmwares fail to verify what they get via PXEv6 anyway,so
delivering an overflow payload is overkill. :)
Thats actually why you see 'schlimm' debug output in
secure mode in the PoC demo screenshot at all.

There were some twists necesarry to actually achieve *ptr = value
as seen above, mainly due to protocol specifics. If you are interested, we can discuss this privately.