On Fri, Jul 15, 2016 at 9:21 PM, <demioben...@gmail.com> wrote: > I know that in Go a data race is undefined behavior. > > How likely is the undefined behavior likely to result in an exploitable > security bug, where "exploitable" means more than just denial-of-service? I > am looking for qualitative estimates here. Is it the kind of bug that would > be almost impossible to exploit, or could a reliable exploit be crafted? > > If the former, then Go is a good choice for security-critical applications; > if the latter, then I should probably choose a language which provides a > compile-time guarantee that data races will not happen (safe Rust/@safe D) > or at least guarantees that they will not result in memory corruption (.NET > Core/Haskell)
That is a hard question to answer. Let's assume the perhaps more typical case of an attacker that is not running processes on the local machine, but only attacking via network connections. Even assuming a vulnerable program, it's fairly hard for an attacker using multiple network connections to generate any sort of controllable race at all. It's vastly harder to turn such a race into any sort of exploit. Using network connections the only plausible race would be racing on assignments to a global variable. Racing on assignments to a map could easily cause a crash but I don't see how it could cause an exploit. Racing on assignments to a global slice (not to elements of the slice, but to the slice itself) could in some cases cause an exploit. It requires a somewhat implausible program, but I suppose anything is possible. I don't see how races on any other types could cause an exploit. But I am no expert, and there may well be exploitable holes I am not seeing. All that said, any race that is potentially exploitable over the network would be immediately detected by the race detector. I don't think there is any realistic possibility of a race that is exploitable over the network that is not seen by the race detector during trivial testing. And, you can avoid all exploitable race conditions by setting GOMAXPROCS=1, though of course by doing so you would not get the best performance in a network server. Although Go's crypto packages were primarily written by an expert in the field, they have not, as far as I know, been subject to serious detailed security review by people looking for exploits. Frankly I would worry less about race conditions and more about whether there is some exploitable mistake in those packages. I don't know the status of the security packages used in Rust or D. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
