Yes, but Go is not a scripting language and the playground is sandboxed for a good reason. Go was not designed as javascript to be safely run even with untrusted sources. Go assumes source code is safe and trusted like most languages do.
-
-
The scripting doesn't need to be in the Go code to accomplish the same thing, and as I said, that sounds a lot like many commonly deployed environments.
1 reply 0 retweets 1 like -
i.e. it can be JavaScript or Lua scripting closely tied to Go code, such as a web browser, custom map / mod scripting for a game engine, etc. There are a lot of cases where an attacker has scripting capabilities. Remote access to a service can also provide similar capabilities.
2 replies 0 retweets 0 likes -
It's definitely way harder to do an exploit like this without either direct remote connections to a service or even better local scripting. Still, I'm not really surprised anymore when people exploit something like a 1 byte null overflow without scripting or an active connection.
1 reply 0 retweets 0 likes -
Replying to @DanielMicay @pcwalton
This specific exploit still requires the race detector to be disabled, and the other ones we saw require arbitrary *go* to be compiled in the executable.
1 reply 0 retweets 0 likes -
Replying to @empijei @DanielMicay
The issue here is that the language could have been designed to avoid such problems. Interfaces could have been double-boxed and slices could have been (ptr, start, end) with start/end untrusted by the implementation.
1 reply 0 retweets 0 likes -
Replying to @pcwalton @DanielMicay
How much more complicated and slow would the language need to be to address the threat model of untrusted code being compiled inside a trusted unit? Also, why do you mention slices? Go has slices implemented as {ptr, len, cap} and performs boundary checks.
1 reply 0 retweets 0 likes -
Replying to @empijei @DanielMicay
It doesn’t need to be complicated and slow at all. Java and C# designed interfaces without those problems (much earlier than Go did). The problem with slices is that Go trusts the length. So a race could overwrite ptr to point to a smaller alloc, allowing for OOB R/W.
2 replies 0 retweets 0 likes -
Specifically: Thread A: slice = bigArray[0:100] slice = smallArray[0:10] Thread B: slice[20] = 12345 A: slice.ptr = &smallArray B: Read slice.ptr B: Read slice.len B: Bounds check, 20 < 100 so OK B: Write 12345 /* OOB */ A: Write 10 to slice.len
1 reply 0 retweets 0 likes -
Replying to @pcwalton @DanielMicay
I understand this, but I don't see much value in addressing it.
1 reply 0 retweets 0 likes
After that CTF showed that arbitrary code execution is possible I would not be confident. We’ll see :)
-
-
Replying to @pcwalton @DanielMicay
That has been known to be exploitable at least since 2015. I still think I'd prefer the Go team focusing on other things than addressing this issue, but that is my personal opinion.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.