I don’t see any evidence that anyone wrote an RCE exploit for this, but I also don’t see any evidence of anyone even trying to rule it out.

tptacek 5 days ago | parent [-]

What about this particular bug do you think makes it likely to be exploitable? I'm not asking you to write an RCE POC, just to tell a story of the sequence of events involving this bug that results in attacker-controlled code. What does the attacker control here, and how do they use that control to divert execution?

▲

amluto 5 days ago | parent [-]

As a general heuristic, a corrupted data structure in a network server results in RCE. This is common in languages like C and C++.

On first glance, it looks like the bug can (at least) result in the server accessing a slice object where the various fields don’t all come from the same place. So the target server can end up accessing some object out of bounds (or as the wrong type or both), which can easily end up writing some data (possibly attacker controlled) to an inappropriate place. In standard attack, the attacker might try to modify the stack or a function pointer to set up a ROP chain or something similar, which is close enough to arbitrarily code to eventually either corrupt something to directly escalate privileges or to do appropriate syscalls to actually execute code.

▲

tptacek 5 days ago | parent | next [-]

No, that doesn't work. Lots of (maybe even most) corrupted data structures aren't exploitable (past DOS). Where does the attacker-controlled data come from. What path does it take to get to where the attacker wants it to go. You have to be able to answer those two questions.

	▲	amluto 5 days ago \| parent [-]
		The Internet is full of nice articles of people bragging about their RCE exploits that start with single-byte overruns or seemingly-weak type confusions, etc. > Where does the attacker-controlled data come from. The example I gave was an HTTP server. Attackers can shove in as much attacker-controlled data as they want. They can likely do something like a heap by using many requests or many headers. Unless the runtime zeroes freed memory (and frees it immediately, which GC languages like Go often don’t do), then lots of attacker controlled data will stick around. And, for all I know, the slice that gets mixed up in this bug is fully attacker controlled! In any event, I think this whole line of reasoning is backwards. Developers should assume that a memory safety error is game over unless there is a very strong reason to believe otherwise — assume full RCE, ability to read and write all in-process data, the ability to issue any syscall, and the ability to try to exploit side channels. Maybe very strong mitigations like hardware-assisted CFI will change this, and maybe not.

▲

ameliaquining 5 days ago | parent | prev [-]

I looked at the code, and unless I've misunderstood it, this bug can't corrupt the slice in the sense of allowing accesses outside the designated allocation or anything like that, because the slice variable is only written to once, when the writer is initialized, so there can't be racy accesses to it. The contents of the slice can potentially be corrupted, but that's just arbitrary bytes, so not a memory safety violation.

The line I'm not quite as sure about is https://go.googlesource.com/go/+/refs/tags/go1.13.1/src/bufi.... That assignment is to a variable of interface type, so in theory it could cause memory corruption if multiple goroutines executed it concurrently on the same receiver, which was possible until the bug was fixed. That said, I cannot immediately think of a way to exploit this; you can only write error values corresponding to errors that you can make occur while writing to the socket, and that's a much more constrained set of possible values than the arbitrary bytes that can occur in a buffer. And for that, you only get confusion among the types of those particular errors. It might be possible but it at least looks challenging.