HTTP/2 Denial of Service Advisory
> Netflix has discovered several resource exhaustion vectors affecting a variety of third-party HTTP/2 implementations. These attack vectors can be used to launch DoS attacks against servers that support HTTP/2 communication.
Son of Slowloris returns!
> While this added complexity enables some exciting new features, it also raises implementation questions.
Here comes trouble...
> The Security Considerations section of RFC 7540 (see Section 10.5) addresses some of this in a general way. However, unlike the expected “normal” behavior—which is well-documented and which implementations seem to follow very closely—the algorithms and mechanisms for detecting and mitigating “abnormal” behavior are significantly more vague and left as an exercise for the implementer. From a review of various software packages, it appears that this has led to a variety of implementations with a variety of good ideas, but also some weaknesses.
Spying on HTTPS
> While most users probably would have no idea what to make of this, I happened to know what it means– Chrome is warning me that the system configuration has instructed it to leak the secret keys it uses to encrypt and decrypt HTTPS traffic to a stream on the local computer.
Beginner Problems With TCP & The socket Module in Python
> Your operating system will deceive you and re-assemble the string you sock.recv(n) differently from the ones you sock.send(data). But here is the deceptive part. It will work sometimes, but not always. These bugs will be difficult to chase. If you have two programs communicating over TCP via the loopback device in your operating system (the virtual network device with IP 127.0.0.1), then the data does not leave your RAM, and packets are never fragmented to fit into the maximum size of an Ethernet frame or 802.11 WLAN transmission. The data arrives immediately because it’s already there, and the other side gets to read via sock.recv(n) exactly the bytestring you sent over sock.send(data). If you connect to localhost via IPv6, the maximum packet size is 64 kB, and all the packets are already there to be reassembled into a bytestream immediately! But when you try to run the same code over the real Internet, with lag and packet loss, or when you are unlucky with the multitasking/scheduling of your OS, you will either get more data than you expected, leftover data from the last sock.send(data), or incomplete data.
Not strictly a python problem, either.
One core problem with DNSSEC
> One fundamental problem of DNSSEC today is that it suffers from the false positive problem, the same one that security alerts suffer from. In practice today, for almost all people almost all of the time, a DNSSEC failure is not a genuine attack; it is a configuration mistake, and the configuration mistake is almost never on the side making the DNS query. This means that almost all of the time, DNSSEC acts by stopping you from doing something safe that you want to do and further, you can’t fix the DNSSEC problem except by turning off DNSSEC, because it’s someone else’s mistake (in configuration, in operation, or in whatever).
HTTP Desync Attacks: Request Smuggling Reborn
> HTTP requests are traditionally viewed as isolated, standalone entities. In this paper, I’ll explore forgotten techniques for remote, unauthenticated attackers to smash through this isolation and splice their requests into others, through which I was able to play puppeteer with the web infrastructure of numerous commercial and military systems, rain exploits on their visitors, and harvest over $70k in bug bounties.
> The protocol is extremely simple - HTTP requests are simply placed back to back, and the server parses headers to work out where each one ends and the next one starts. This is often confused with HTTP pipelining, which is a rarer subtype that’s not required for the attacks described in this paper. By itself, this is harmless. However, modern websites are composed of chains of systems, all talking over HTTP. This multi-tiered architecture takes HTTP requests from multiple different users and routes them over a single TCP/TLS connection:
The Fully Remote Attack Surface of the iPhone
> We investigated the remote attack surface of the iPhone, and reviewed SMS, MMS, VVM, Email and iMessage. Several tools which can be used to further test these attack surfaces were released. We reported a total of 10 vulnerabilities, all of which have since been fixed. The majority of vulnerabilities occurred in iMessage due to its broad and difficult to enumerate attack surface. Most of this attack surface is not part of normal use, and does not have any benefit to users. Visual Voicemail also had a large and unintuitive attack surface that likely led to a single serious vulnerability being reported in it. Overall, the number and severity of the remote vulnerabilities we found was substantial. Reducing the remote attack surface of the iPhone would likely improve its security.
Better Encrypted Group Chat
> End-to-end encrypted group messaging is also a hard problem to solve. Existing solutions such as Signal, WhatsApp, and iMessage have inherent problems with scaling, which I’ll discuss in detail, that make it infeasible to conduct group chats of more than a few hundred people. The Message Layer Security (MLS) protocol aims to make end-to-end encrypted group chat more efficient while still providing security guarantees like forward secrecy and post-compromise security.
> The primary contribution of molasses has been in detecting errors in the specification and other implementations through unit and interoperability testing. Molasses implements most of MLS draft 6. Why not all of draft 6? There was an error in the spec that made it impossible for members to be added to any group. This broke all the unit tests that create non-trivial groups. Errors like this are hard to catch just by reading the spec; they require some amount of automated digging. Once they are found, the necessary revisions tend to be pretty obvious, and they are swiftly incorporated into the subsequent draft.
Nice work and a very nice explanation of the protocol.
Why file and directory operations are synchronous in NFS
> One simple answer is that the Unix API provides no way to report delayed errors for file and directory operations. If you write() data, it is an accepted part of the Unix API that errors stemming from that write may not be reported until much later, such as when you close() the file. This includes not just ‘IO error’ type errors, but also problems such as ‘out of space’ or ‘disk quota exceeded’; they may only appear and become definite when the system forces the data to be written out. However, there’s no equivalent of close() for things like removing files or renaming them, or making directories; the Unix API assumes that these either succeed or fail on the spot.
Some items from my "reliability list"
> I’ll list some of them here and some of the thinking behind them. Just about everything here has happened at some point in time, and probably has happened more than once... way more than once.
I like a lot of this. Very much.
> On the other hand, if you only need 53 bits of your 64 bit numbers, and enjoy blowing CPU on ridiculously inefficient marshaling and unmarshaling steps, hey, it’s your funeral.
Browers can't feasibly stop web pages from talking to private (local) IP addresses
> This is a tempting and natural viewpoint, but unfortunately this can’t be done in practice without breaking things. To understand this, I’ll outline a series of approaches and then explain why they fail or cause problems.
Adventures in reverse engineering Broadcom NIC firmware
> The reverse engineering project, Project Ortega, began in December 2017 and involved reverse engineering proprietary firmware to determine what any open source replacement would need to do. Mainly this involved producing a reverse engineered C codebase from the disassembly of proprietary firmware, then producing a natural-language specification for others to reimplement; the actual reversed code itself is not published. In other words, this is a clean-room reverse engineering workflow.
Why was Windows for Workgroups pejoratively nicknamed Windows for Warehouses?
> Windows for Workgroups came with a network card, instructions for installing it, and even a screwdriver to assist with the installation. Now, there were two network cable standards at the time: BNC and 10Base-T. The network card that came with Windows for Workgroups 3.10 used BNC, which turned out to be the loser in the standards battle.
Linux and FreeBSD Kernel: Multiple TCP-based remote denial of service issues
> Netflix has identified several TCP networking vulnerabilities in FreeBSD and Linux kernels. The vulnerabilities specifically relate to the minimum segment size (MSS) and TCP Selective Acknowledgement (SACK) capabilities. The most serious, dubbed “SACK Panic,” allows a remotely-triggered kernel panic on recent Linux kernels.
Teaching a cheap ethernet switch new tricks
> The operating system part for open switches (and participating non open design switches) is dealt with by a system called ONIE (Open Network Install Environment) ONIE provides a mostly standardised boot environment that can be used to install other boot environments.
g2k19 Hackathon Report: Stefan Sperling on Access Points and Ghosts
> This AP was promptly attacked! But with OpenBSD on both AP and client, I now had a full view of the battle field and made our hackroom’s wifi immune to de-auth attacks. I don’t have enough brain juice to come up with a good heuristic for this, so users need to manually cast a de-auth attack immunity spell by setting the new ‘stayauth’ nwflag with ifconfig(8). Note that this flag needs to be set on clients as well as the AP, because a de-auth army will target them separately.
Building Facebook’s service encryption infrastructure
> In this post, we’ll talk about how we migrated our encryption infrastructure in data centers from the Kerberos authentication protocol to TLS. Optimizing for operability and performance, while still satisfying the right security model for each service, required navigating difficult trade-offs. By sharing our experiences, we hope to show how we think about our encryption infrastructure and help others as they think through their own implementation.
DNS-OARC 30: Bad news for DANE
> DNS-OARC held its 30th meeting in Bangkok from 12 to 13 May. Here’s what attracted my interest from two full days of DNS presentations and conversations, together with a summary of the other material that was presented at this workshop.
My new favorite tool for looking at TLS things is certigo
> For a long time I’ve used the OpenSSL command line tools to do things like looking at certificates and chasing certificate chains (although OpenSSL is no longer what you want to use to make self-signed certificates). This works, and is in many ways the canonical and most complete way to do this sort of stuff, but if you’ve ever used the openssl command and its many sub-options you know that it’s kind of a pain in the rear. As a result of this, for some years now I’ve been using Square’s certigo command instead.
WireGuard on OpenBSD
> Earlier this week I imported a port for WireGuard into the OpenBSD ports tree. At the moment we have the userland daemon and the tools available. The in-kernel implementation is only available for Linux. At the time of writing there are packages available for -current.
> Networks rule our world. From the chemical reaction pathways inside a cell, to the web of relationships in an ecosystem, to the trade and political networks that shape the course of history. Or consider this very post you’re reading. You probably found it on a social network, downloaded it from a computer network, and are currently deciphering it with your neural network. But as much as I’ve thought about networks over the years, I didn’t appreciate (until very recently) the importance of simple diffusion. This is our topic for today: the way things move and spread, somewhat chaotically, across a network.