Notices by David Chisnall (david_chisnall@infosec.exchange), page 2

It astonishes me that people expected LLMs to be good at creating summaries. LLMs are good at transforms that have the same shape as ones that appear in their training data. They're fairly good, for example, at generating comments from code because code follows common structures and naming conventions that are mirrored in the comments (with totally different shapes of text).

In contrast, summarisation is tightly coupled to meaning. Summarisation is not just about making text shorter, it's about discarding things that don't contribute to the overall point and combining related things. This is a problem that requires understanding the material, because it's all about making value judgements.

So, it's totally unsurprising that the Australian study showed that it's useless. It's no surprise that both Microsoft and Apple's email summarisation tools discard the obvious phishing markers and summarise phishing scams as '{important thing happened}, click on this link' because they don't actually understand anything in the text that they're discarding, they just mark it as low entropy and discard it.

@cr1901 @ewenmcneill @mxshift

It’s not a stupid question. You absolutely can lie about the source address for a packet. On a local network segment (with no VLANs), it will probably arrive just fine. If it needs routing, it may go through something that says ‘hmm, packets from this subnet aren’t allowed to come from over here’ and drops it on the floor.

The important question is: and then what?

The main use for the source address is to allow the destination to reply. If you send a packet with a faked source address, any reply will go to the faked source address and not to you. Sometimes that’s useful. Some NAT tunnelling things used to rely on this doing terrifying things with intermediaries taking part of a TCP handshake.

In general, most connection-oriented things (TCP, QUIC) require some handshake and so you’ll end up failing to establish the connection if you fake the source. As an attacker, you need to compromise the target network stack with the first packet (which is sometimes possible) to get anything useful from stateful protocols. You may (if you can guess the sequence number) be able to inject a packet into the middle of a TCP stream, but generally that will just show up as a decryption failure in TLS (you are using TOS for everything, right?).

The more fun attacks rely on reflection. DNS, for example, is designed to be low latency and so is (ignoring newer protocol variants) a single UDP packet request and a single UDP packet response. With things like DNSSEC signatures (or entries with a lot of round-robin IPs), the response can be much bigger than the request and so you can send a request to a DNS server with a small request and a spoofed source, and the DNS server will reply with a big packet to your victim. DNS servers and other parts of network infrastructure have mitigations for this, but it’s easy to accidentally make a new protocol that provides this kind of amplification. QUIC has a rule that the first packet must be at least as big as its response (so sometimes requires padding) to establish a connection precisely to avoid this kind of issue.

If you think that’s scary, remember that networks are everywhere. Most busses are now actuallly networks. PCIe is a network and PCIe source addresses are used by the IOMMU to determine which devices can access which bit of the host memory. Where does the PCIe source address come from? The device puts it in the PCIe packet. It’s trivial for a PCIe device (including an external one connected via Thunderbolt) to spoof the ID of a valid one and initiate DMA to and from regions exposed to the other device. IDE and TDISP should mitigate these problems when they’re actually deployed (I don’t know of any shipping hardware that implements them yet. I think IDE is sufficient but it’s been a while and I don’t remember what things are in which spec).

@cr1901 IOMMUs in most systems are designed to allow devices to be attached to VMs. The threat model is that you have attached a device to a VM and want to protect against that device initiating DMAs to or from a physical address that the VM cannot access. They are somewhat useful without virtualisation (and, increasingly for kernel-bypass things with userspace), but the threat model almost always assumes that devices are trustworthy. The PCIe spec even includes a feature called ATS that allows the device to bypass the IOMMU if it implements its own (fortunately, it’s possible to turn this off).

@cr1901 @ewenmcneill @mxshift

Re: sending a big packet to a victim, at worst won't that cause excess network traffic that'll be ignored (b/c the victim won't be listening, the kernel will discard it)?

Sure, the kernel will discard it at the far end, but the network connection to the victim Is finite. If you fill it with big packets, it doesn’t matter that the kernel discards them, it will never get to see other things. If you have a 10 Mbit connection and so does your victim, and you can get DNS servers to amplify your attack with a 10:1 ratio (response is 1000 bytes for a 100-byte request), you can deliver 100 Mb/s to the victim, which will cause a load of the packets that they want to be dropped, which will cause TCP connections to get slower, which will make their proportion of the total drop, which will make them slower, and so on.

Also I thought the whole purpose of IOMMU was "the kernel decides the memory addresses a device can write to/read from, for each xaction". Won't not knowing valid addrs guard against spoofing?

The kernel decides a mapping between device physical addresses and host physical addresses. A malicious device can choose to use a different mapping. For most of these things, this is fine in the threat model. They assume trusted devices and untrusted VMs.

@cr1901 The threat model for most IOMMUs relates to VMs. The earliest ones (at least, outside of mainframes) were actually nothing to do with security, they were there to allow cheap 32-bit NICs to DMA everywhere in a workstation with 8 GiB of RAM, but the Intel, AMD, and Arm designs are all built around virtualisation.

If you do not use virtualisation, you can still use an IOMMU to restrict which regions of the physical address space a device can write to. Regions that no device can write to are safe. Regions that a device can write to cannot be protected from a different device writing to them if the device is malicious.

If devices are not actively malicious, this is not a problem. If a kernel decides to set up different IOMMU regions for each device, a bug in a driver that sends the wrong address for DMA will be mitigated. If a system does device pass-through to a malicious VM and the VM tries to initiate DMA somewhere outside of its pseudophysical (sometimes called Guest Virtual) address space, the IOMMU will stop it.

@matt Low level things (wrapping pdfork, sockets, and so on) in Rust, most of the logic (e.g. systemd-compatible socket activation) in Lua.

@winterschon @matt An increasing number of things depend on the systemd socket activation protocol. It’s going to become important fairly soon that we have support for it in the service management system.

@doerk @winterschon @matt I don’t think anyone is suggesting importing systemd into FreeBSD, but I don’t know who would complain about services consuming no RAM when not in use.

Any #Rust folks giving up on Linux:

#FreeBSD has no current plan for Rust, but we want one! We want experienced Rust people to tell us how it should work. We’re interested in being able to add Rust in both userspace and the kernel, but we need a way of using Rust that works with multi-year support cycles (we need to be able to easily merge security fixes in trunk back to a branch that was originally made four years ago).

Personally, I’d love to see a new service management framework for FreeBSD written in Rust + Lua.

@ryanc My reading of the AGPL is that you would not because it's a static site generator. Visitors of your blog are not interacting with the software and so the AGPL doesn't apply. They are interacting solely with the output of the software and, if I remember correctly, AGPLv3 inherits from GPLv3 an explicit statement that the output of the software is not covered by any restrictions (GCC has an additional piece of text because it can copy bits of itself into the output and it exempts these).

That said, I am not a lawyer and this is precisely the kind of question that you need a real lawyer to answer. My desire to not have to ask lawyers this kind of question is precisely why I avoid ever modifying AGPL'd code in any way (and, as a side effect, of why I never contribute to AGPL'd projects).

@ryanc That's what you get for not having your phone on do-no-disturb at 8:10.

@patrickcmiller

End-to-end encryption to protect all keystrokes and cursor movement in real time.

Is this satire? What is the remote 'end' to which keystrokes and cursor movements are being sent that needs encryption? And why are keystrokes and cursor movements being sent anywhere?

Do they just mean that they use TLS for their web apps (in which case, that's table stakes)?

For keystrokes and mouse movements encryption isn't sufficient, you need to add noise or traffic analysis can reconstruct them with high probability.

@ryanc @sindarina @rmi @NanoRaptor Only 99% of the time, which makes it extra confusing when it's something real.

@ryanc Now I really want to see them do this:

Nigel Farage, who identifies as a man of the people, but who is biologically a pound-shop fascist with no talent in any field except moving money from one column in a spreadsheet to another, said today...

@ryanc Or do, but do it for everyone.

@ryanc I suspect it’s more that they want to be able to upgrade those libraries when they without breaking third-party things. FreeBSD also ships a few shared libraries without headers (though we stick them in a separate directory with rpath linkage so you can’t accidentally link them) because we don’t want them to be treated as part of the stable ABI. I’m not sure how stable the libcrypto ABIs are, but the rest of OpenSSL has a habit of breaking even source compatibility across versions. Apple almost certainly doesn’t want to be in a situation of having to choose between deploying a security fix or not breaking a load of third-party apps.

@ryanc Or, more broadly: 'What will the behaviour be of a user that doesn't think about these things'.

The canonical example is of security dialogs where users are trained to click 'okay' without reading them, but there are a lot more things related to defaults, positions of icons, and so on.

Unfortunately, the problem is usually not caused by people failing to think of these things. The problem is that the people that do think about these things do not have the interests of their users in mind. They are trying to manufacture consent for things that have negative impacts on their users.

@ryanc @adamshostack @tess @sophieschmieg @Vrimj @singe

Conversely, to your point, nobody needs to care why someone would do an SQLi.

But that’s exactly what I do care about in a threat model. For example, if my database is using access control that restricts the queries that a client can run to the set of things that are exposed, what extra rights can an attacker gain by injecting SQL? If I have an API that allows the client to submit SQL, and another that allows them to run pre-generated queries, and the second is vulnerable to SQL injection because the attacker could just use the same endpoint. In contrast, if I’m using the set of SQL queries that are run in my trusted component to restrict what the user can do, then I care a lot about SQL injection.

The key difference between these two cases is what the attacker is trying to achieve. Whether it’s tampering with other customers data, extracting trade secrets, or trying to find location data on another user to spy on them, the motivation of the attacker is key.

This is particularly true in a compartmentalised system. For a lot of the #CHERIoT work, we have compartments where we assume an attacker can get arbitrary-code execution. To reason usefully about security we have to think about what they want to achieve. Do you want to compromise the control-system logic? Do you want to join a botnet mounting a DDoS attack on other devices (and not care at all what this device is, just that it has a network connection)? This factors into high-level system decide and lets you reason about what classes of attack are in scope and where we care about vulnerabilities.

@ryanc I'd include that under the heading of security. It's closely related to the 'can an attacker leak information from my smart device that tells them when my house is unoccupied' threat.

I'm still waiting for an organised crime syndicate to provide a service that aggregates a load of data from Facebook and similar to tell petty criminals which houses near them are unoccupied.

@ryanc Are there developers that don’t do this already? I suppose that explains the poor security of a lot of products.