3 ms·
Can you do a security exploit with a concurrency bug although in golang? You may corrupt data, but can you cause remote code execution with it?
by novok 5y ago
Can you do a security exploit with a concurrency bug although in golang? You may corrupt data, but can you cause remote code execution with it?
- kortilla 5y agoRCE in that process maybe not, but security exploit absolutely. Things like that are how can be the difference between admin and non admin privileges or an “authenticated/not-authenticated” scenario.
- mattgreenrocks 5y agoCorrupt data may break invariants, which widen the attack surface.
- yellow_lead 5y agoYes, not all RCEs are caused by memory bugs.
- staunch 5y agoCan you point to some examples of RCEs caused by Go concurrency bugs?
- yellow_lead 5y agoI don't have a real world example. I was just stating it's possible.
- staticassertion 5y agoTo be clear, yes. The issue is with how Go's "interface{}"s (and some other types - like slices, etc) work - it's two pointers that can't be written to atomically, which means you can get into a situation where your objects are invalid. https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... Here you can find a POC. You could argue that this is contrived, but it's also not going to be fixed. This is in contrast to Rust, where there may be implementation flaws leading to unsafety in safe code, but the language retains the right to fix those, even if it breaks code. Still, I think there's really no question that Go is a major step up over C and C++.