On Fri, 2016-07-15 at 22:19 -0700, Ian Lance Taylor wrote: > 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 > That is what I was hoping for: simple testing should detect any realistically exploitable race condition, and any race condition would be very hard to exploit for remote code execution. Good to know!
So if a data race is detected in my program, that is a bug that needs to be fixed – but it is (probably) NOT a critical security vulnerability, unlike (say) a C buffer overflow or arbitrary SQL injection. One more question: is racing on a map likely to crash due to out-of- bounds reads, as opposed to out-of-bounds writes? Demi -- 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.
