Thursday, October 30, 2014

Not just because they are ugly but also because lophttpdnever was affected by POODLE, since SSLv3 wasdisabled for a reason in favor of TLSv1. I think about droppingTLSv1 too and just allowing TLSv1.1+ in future.To my knowledge lophttpd is also the first webserverutilizing Linux seccomp sandbox.I also added SO_REUSEPORT support today, since Googletold us that when handling c10k, their processesare un-evenly distributed across the cores (what the hellare 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. Couldthere be a smaller footprint?Update:After carefully reading the commit for the Linux kernelthat introducedSO_REUSEPORT, I came to the conclusion thatfor Linux there was an entirely different reason to introduceit than there was for 4.4BSD at the time. According to thegit commit message, uneven distribution among the coresonly happen when the "number of listener sockets bound to aport 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 googlewebserver, why it had such problems before the patchand which kernel they are using. OSINT for the win.(Such architecture where new listeners are created or removeddo not make much sense to me anyway, so there are somequestions left.)So in theory, I could remove SO_REUSEPORT again but I willleave it as is for now, in case more webserver instancesare started later. Note that it doesn't make sense to havemore lophttpds running than there are cores onyour 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 architecturewithout SO_REUSEPORT (yet).

Monday, October 13, 2014

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 beremotely exploitable buffer overflows in your securebootloader. The 90's party of today just happendownstairs. Bootloaders make use of UEFI network stacksto implement PXE and PXEv6 and sometimes fail to do so:

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

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